Bugzilla – Bug 2343
wifi: Setting Duration field for Ack frames
Last modified: 2016-06-29 14:29:48 UTC
Discussed in this thread: http://mailman.isi.edu/pipermail/ns-developers/2016-March/013484.html Specifically, the duration being set in the ack frame does not seem to be explicitly set to the expected ACK duration (802.11-2012, Section 8.2.5.1) but instead to a quantity calculated from the NAV of the data frame that solicited the ACK, and even so, it seems to subtract off the wrong quantities. So basically, the question is whether this type of patch would be more correct: - duration -= GetAckDuration (ackTxVector); - duration -= GetSifs (); - NS_ASSERT (duration >= MicroSeconds (0)); - ack.SetDuration (duration); + ack.SetDuration (GetAckDuration (ackTxVector));
Checking back the standard (section 7.2): ... the duration value is the value obtained from the Duration field of the immediately previous data or management frame, minus the time, in microseconds, required to transmit the ACK frame and its SIFS interval. If the calculated duration includes a fractional microsecond, that value is rounded up to the next higher integer. I thus think our code is following standard rules and the way we compute the duration should not be changed. If this assert is triggered, this means that something else is wrong beforehand. We would need a test case to reproduce it and try to fix what is going wrong.
I found this in the 802.11-2012 standard in section 8.3.1.4: "For ACK frames sent by non-QoS STAs, if the More Fragments bit was equal to 0 in the Frame Control field of the immediately previous individually addressed data or management frame, the duration value is set to 0. In other ACK frames sent by non-QoS STAs, the duration value is the value obtained from the Duration/ID field of the immediately previous data, management, PS-Poll, BlockAckReq, or BlockAck frame minus the time, in microseconds, required to transmit the ACK frame and its SIFS interval. If the calculated duration includes a fractional microsecond, that value is rounded up to the next higher integer." I will add some comment to the text to clarify this, and also change the NS_ASSERT to an NS_ASSERT_MSG asking people for a testcase if they hit this assert. I am going to mark as NEEDINFO for a few days to see if we obtain a breaking testcase, and if none posted, close this issue after ns-3.25 release.
(In reply to Tom Henderson from comment #2) > I will add some comment to the text to clarify this, and also change the > NS_ASSERT to an NS_ASSERT_MSG asking people for a testcase if they hit this > assert. pushed in changeset a995220916a8
Tom, Now that the release has passed, can this be closed?
I think this can be closed, right?
patch already pushed: closing bug