Bugzilla – Bug 737
Backoff procedure is not invoked when transmission is deferred
Last modified: 2010-01-25 06:54:31 EDT
You need to log in before you can comment on or make changes to this bug.
In accordance with 9.2.8 of 802.11-2007 (Ack procedure) "If a PHY-RXSTART.indication does not occur during the ACKTimeout interval, the STA concludes that the transmission of the MPDU has failed, and this STA shall invoke its backoff procedure upon expiration of the ACKTimeout interval." The same situation is with CTS timeout. Current implementation starts a backoff procedure inside DCA-TXOP, but only DcfManager knows about CTS and ACK timeouts. So, the method like "StartBackoffProcedure" shall be added to DcaTxop and EdcaTxop, but in this case backoff procedure will be initiated from both DcaTxop and DcfManager. What about making DcfManager the only place to start backoff procedure for all queues?
I am sorry but I don't see what the problem is: I believe that we do the right thing with regard to the paragraph you quote from the standard. Maybe you could try to give a few more details about the failing testcase you have ?
I have found more clear explanation of what is wrong in DcfManager: Chapter 9.1.1 says: "After deferral, or prior to attempting to transmit again immediately after a successful transmission, the STA shall select a random backoff interval and shall decrement the backoff interval counter while the medium is idle." So DcfManager::IsBusy () must check, that AIFSn of a queue that requested access has passed after GetAccessGrantStart () (rather than checking if we are not receiving or transmitting, or NAV busy). I have observed it while looking at pcap traces in mesh: a station does not calculate a backoff when it retransmits a frame, because frame was retransmitted immediately after receiving, when the medium was idle (medium was idle inside a SIFS before ACK!). Am I right?
Also it seems to me that first version of patch in bug 555 solves this problem
Addition to previous commit: but in first patch in bug 555 IsBusy () is not needed
Created an attachment (id=689) [details] Proposed fix
(In reply to comment #2) > a station does not > calculate a backoff when it retransmits a frame, because frame was > retransmitted immediately after receiving, when the medium was idle (medium was > idle inside a SIFS before ACK!). I am sorry but I really do not understand this description of your testcase. Please, can you try to provide a more detailed description ?
I have made a short illustration about how DcfManager operates when a frame is retransmitted immediately after it was received. running mesh script with 1x3 grid and simple debugging print I have observed, that backoff procedure is not invoked even when station defers its transmission.
Created an attachment (id=717) [details] illustration of 1x3 grid scenario Illustration
Also the main problem of this bug is in broken dcf-manager-test, where each test fails. Mathieu, could, you please, review my previous comment?
Hi, Mathieu, I'd like to draw your attention to this bug, since it appears to be critical in multihop mesh/manet networks. The reason is that none of our models really account for processing delays and all re-transmissions (say forwarding RREQ in AODV) occur simultaneously. Large number of exactly simultaneous transmissions leads to significantly overestimated collision probability and even to wrong protocol operation. Recent example of this behavior was reported to me recently by Kuba Wierusz. Fixing bug 737 gives us simple workaround for this problem without the need of explicit accounting for processing delay. Indeed, now when wifi device is asked to retransmit a packet without any delay it will deffer this for DIFS. After proposed bugfix every deferred TX will start backoff -- exactly what is needed to avoid artificial collisions. What do you think? Regards, Pavel