(In reply to sebastien.deronne from comment #0)
> In WifiMac, the ACK and CTS timeout durations are identically set for both
> 2.4 and 5 GHz channels, which I think is not correct. Furthermore, I do not
> see where come the chosen values!
> 
> What I propose is to delete those two lines in both configurations:
>   SetCtsTimeout (MicroSeconds (10 + 52 + 20 + GetDefaultMaxPropagationDelay
> ().GetMicroSeconds () * 2));
>   SetAckTimeout (MicroSeconds (10 + 52 + 20 + GetDefaultMaxPropagationDelay
> ().GetMicroSeconds () * 2));
> 
> As such, 802.11n 2.4 GHz transmissions will use 802.11g timeout values while
> 802.11n 5GHz transmissions will use 802.11a durations, so as to support
> backward compatibility.
> 
> May someone give his point about it?

(marking as patch pending since the patch is implicit above).

Ghada added these configurations in changeset 10139.

2007 standard says to set these values as:

"...CTSTimeout interval, with a value of aSIFSTime +
aSlotTime + aPHY-RX-START-Delay, starting at the PHY-TXEND.confirm"

"...ACKTimeout interval, with a value of aSIFSTime + aSlotTime + aPHY-RX-START-Delay, starting at the PHY-TXEND.confirm"

In ns3 these values are defined as aslottime+asifstime+ackTxTime+airtime*2 . The defaults Phy rate supported by 11a,11g and 11n are different so Acktxtime is different between the 3 standards. If we keep the 11g values the throughput for 11n is going to be lower when we have collisions because timeout will take too long. So I suggest to keep them as they are with the acktxtime for default 11n phy rates but change the 5GHz values to include aslottime and asifstime for 5GHz:

 SetCtsTimeout (MicroSeconds (16 + 52 + 9 + GetDefaultMaxPropagationDelay ().GetMicroSeconds () * 2));

Ghada, I agree with you.

But since we call Configure80211a before setting ACK and CTS timeout values, I propose to remove SetAckTimeout and SetCtsTimeout, as they will set the exactly same values as Configure80211a.

Note that even though the PHY bitrate is higher in .11n, the standard is backward compatible with .11a/b/g. So, this seems even more obvious to call Configure80211a and then set HT-related attributes (RIFS, BACK timeout, ...), without overwriting legacy attributes (ACK and CTS timeouts, ...).

Created attachment 2011 [details]
Removes SetCtsTimeout and SetAckTimeout in WifiMac::Configure80211n_2_4Ghz and in WifiMac::Configure80211n_5Ghz

Now I remember why I changed these values it is because of the preamble time. The values in 11a and 11g include legacy preamble which is 20microsec but the 11n MF preamble is 40microsec. Using this patch will make ack and cts timeout before they are received.
Having said that, I reviewed the standard and ack should be sent using non HT PPDU which is using legacy preamble not the MF preamble so mac-low.cc should be changed to reflect that (I already have this change in my 11ac implementation that I will publish later today). The conditions under which Ack is to be sent using HT PPDU are not included in ns3 yet (such as STBC, ...) so I think we can just send Ack using non-HT PPDU safely for now.
The same should be done for CTS but CTS can be sent using HT PPDU if it is in response to an RTS that is sent using HT PPDU. I didn't read yet under what conditions can an RTS be sent using HT PPDU to decide if we should keep it as is or change it as Ack

Ghada,
I agree with you, I had already sent around a question about my thoughts that ACK should be sent using the legacy rates (and it's how I do in my own version), but nobody could provide a clear response as you perfectly did.

I thus propose:
1/ open a new bug in tracker and try to provide a patch as soon as possible so that we are compliant with the standard for ACK. I propose that RTS/CTS are also sent using legacy rates, it seems safer than using HT rates. This could be enhanced later on.

2/ push this proposed patch concerning ACK timeout duration once (1) is solved.

Thanks once again for your clarifications.

To solve this issue we need 2 things
1- This patch that sets Ack timeout as 11a
2- MacLow modification to send Ack using preamble LONG

As for CTS I think the best is to check the standard and see what it says not just send it as Ack. If ns3 supports features that RTS/CTS can be sent using HT PPDU then we should add some logic (probably in mac-low.cc) to do this selection, if not then it can be sent like Ack in a non HT PPDU.
Note that if CTS can be sent using HT PPDU then we need to update CTSTimeout in configure11n since MF preamble is longer than legacy (11a and 11g)

That agrees with step 1 and 2 that you proposed.

Indeed, this seems the wisest way to do.

Another bug has been opened for ACK rates and preambles in 802.11n: https://www.nsnam.org/bugzilla/show_bug.cgi?id=2097

committed in changeset 11387:ad9b049b9b7a