Bugzilla – Bug 2075
A-MPDU using RTS/CTS behaves wrongly when MaxSsrc is reached
Last modified: 2015-05-04 18:47:35 EDT
Created attachment 1985 [details] patch Once the maximum SSRC is reached when RTS/CTS is enabled for A-MPDU transmission, the current implementation simply discards the first packet which is part of the aggregate. This results in an issue where the receiver is still waiting for the discarded packet, since no BAR has been sent in order to flush the receiver. Even though we should have a further check in the standard, ongoing discussions show that it should send a BAR to flush the receiver and discard all MPDUs that are part of the aggregate for which RTS attempts reached the SSRC limit. I attached a patch which implements this solution. If anyone has a better view or a complement on this, feel free to give your points. Reviews on the patch are also welcome. Please note that you need to consider at least two transmitting stations (preferably in saturation conditions) that are fully hidden from each other in order to reproduce this issue.
Created attachment 1986 [details] patch add some tracing
Created attachment 1989 [details] patch v3 Some issues were observed while removing items from the queue. Instead, I propose a better way to solve this bug: EdcaTxopN::CompleteMpduTx is only called once the RTS/CTS exchange has succeeded, i.e. in MacLow::SendDataAfterCts.
Created attachment 1990 [details] patch v4 add flush to remove items from the temporary queues
(In reply to sebastien.deronne from comment #3) > Created attachment 1990 [details] > patch v4 > > add flush to remove items from the temporary queues Patch looks fine to me, but I wonder, did you encounter this in practice with any existing ns-3 wifi tests/examples? You mentioned: "to consider at least two transmitting stations (preferably in saturation conditions) that are fully hidden from each other in order to reproduce this issue." Do we have any such test cases presently?
> Patch looks fine to me, but I wonder, did you encounter this in practice > with any existing ns-3 wifi tests/examples? >You mentioned: "to consider at least two transmitting stations (preferably in >saturation conditions) that are fully hidden from each other in order to reproduce >this issue." Do we have any such test cases presently? No, I encountered this in a specific study I was doing. But I could indeed add an example to reproduce a hidden node scenario in example/wireless/. I guess the issue may be reproduced in unsaturated conditions, but it is more easily reproducible in saturated conditions (=> more collisions => higher probability to reach max SSRC).
Created attachment 2013 [details] example to reproduce A-MPDU in hidden nodes scenarios I attached an example to reproduce A-MPDU in hidden nodes scenarios. Feel also free to give comments on this example. I could later include it in /example/wireless based on your remarks.
Created attachment 2035 [details] refactored example
committed in changeset 11353:b03d1c0ada03