Bug 889

Summary:	Minstrel implementation should be high latency
Product:	ns-3	Reporter:	Nicola Baldo <nicola>
Component:	wifi	Assignee:	Matías Richart <matis18>
Status:	RESOLVED INVALID
Severity:	enhancement	CC:	matis18, sebastien.deronne
Priority:	P5
Version:	ns-3-dev
Hardware:	All
OS:	All

Description Nicola Baldo 2010-04-21 10:48:12 UTC

(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.

Comment 1 Matías Richart 2016-04-01 06:32:42 UTC

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.

Comment 2 sebastien.deronne 2016-10-15 11:21:52 UTC

Matias, I assigned you to this bug, I let you further check whether this (old) bug should be rejected or not.

Comment 3 sebastien.deronne 2020-04-18 09:23:22 UTC

Incorrect according to Matias, so closing this bug