Bugzilla – Bug 1909
Wifi: If an ack timeout occurs in the middle of a receive operation, the station should delay timeout.
Last modified: 2020-04-12 08:33:01 UTC
Created attachment 1831 [details] Ack Timeout rescheduling diff According to the spec, if a MAC ack timeout fires after an RX begin receive primitive, we should reschedule the ack timeout till after we have completed the reception of the frame. If the frame is in fact received correctly, the ack timeout should be cancelled. I have a quick fix attached for review. Modifications are done to the AckTimeout methods in MacLow which check whether we are currently in receive. The patch has been done against ns-3.14, but I believe it can be applied to newer versions of ns3.
Hi Thank you for reporting the bug. I think someone used to mention something like this before. I think the best way to do is to use detect PHY-RXSTART? (Currently we do not support PHY-RXSTART.) What do you think? I will look at your patch too.
(In reply to Daniel L. from comment #1) > Hi > > Thank you for reporting the bug. I think someone used to mention something > like this before. I think the best way to do is to use detect PHY-RXSTART? > (Currently we do not support PHY-RXSTART.) What do you think? > > I will look at your patch too. I believe the yans-wifi-phy model does support PHY-RXSTART, it implements a method called StartReceivePacket. The current WifiPhy base class supports checking for IsStateRx, and allows you to find GetDelayUntilIdle time. In my patch, I've used both these methods to check whether we are in fact in receive upon firing an ack timeout, and then rescheduling the timeout at the time returned by GetDelayUntilIdle. I hope that sounds viable, let me know what you think.
Where is this mention in the standard? If it is true, is this also the case for Block ACK?
> Where is this mention in the standard? From "10.3.2.9 Acknowledgment procedure" (2016 edition): ... After transmitting an MPDU that requires an Ack or BlockAck frame as a response (see Annex G), the STA shall wait for an AckTimeout interval, with a value of aSIFSTime + aSlotTime + aRxPHYStartDelay, starting at the PHY-TXEND.confirm primitive. If a PHY-RXSTART.indication primitive 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. If a PHY-RXSTART.indication primitive does occur during the AckTimeout interval, the STA shall wait for the corresponding PHY-RXEND.indication primitive to determine whether the MPDU transmission was successful. If the STA recognizes a valid Ack frame addressed to the STA and corresponding to this PHY- RXEND.indication primitive, this recognition shall be interpreted as successful acknowledgment. If the STA does not recognize a valid Ack frame addressed to the STA, this condition shall be interpreted as failure of its MPDU transmission. ... > If it is true, is this also the case for Block ACK? It is.
Similar discussions at https://gitlab.com/nsnam/ns-3-dev/-/issues/41