Bugzilla – Bug 889
Minstrel implementation should be high latency
Last modified: 2020-04-18 09:23:22 EDT
(with reference to the definition of "low latency" and "high latency" given in this paper: "IEEE 802.11 Rate Adaptation: A Practical Approach", by M. Lacage, M.H. Manshaei, and T. Turletti) The original minstrel implementation in madwifi is high latency. However, the minstrel implementation in ns-3 is low latency: statistics are updated everytime DoReportDataOk and DoReportDataFailed are called, and these updated stats are then used for selecting the rate for the next transmission attempt.
Although it is true that in Minstrel "statistics are updated everytime DoReportDataOk and DoReportDataFailed are called", the ns3 implementation emulates the high-latency behaviour in the manager. Specifically, it implements the MRR-chain in the manager, and select the next rate from this chain until the frame is correctly received or dropped, without using the stats. It is done this way because ns3 does not implement the idea of MRR chain. Then, I think we can consider ns3 Minstrel as high-latency, although it does not use the ns3 API for high-latency algorithms. In my opinion the bug isn't completely correct and should be closed. Nevertheless, it is true that a clear implementation of Minstrel is possible, but this would need to change ns3 rx/tx path to implement the MRR chain idea.
Matias, I assigned you to this bug, I let you further check whether this (old) bug should be rejected or not.
Incorrect according to Matias, so closing this bug