Bug 958 - WiFi uses wrong default values for MTU, FragmentationThreshold and RtsCtsThreshold
WiFi uses wrong default values for MTU, FragmentationThreshold and RtsCtsThre...
Product: ns-3
Classification: Unclassified
Component: wifi
All All
: P3 trivial
Assigned To: Nicola Baldo
Depends on:
  Show dependency treegraph
Reported: 2010-07-20 18:45 EDT by Hendrik vom Lehn
Modified: 2010-08-02 07:18 EDT (History)
1 user (show)

See Also:

Mercurial patch for abovementioned changes (2.64 KB, patch)
2010-07-20 18:45 EDT, Hendrik vom Lehn
Details | Diff
revisited fix patch for the MAX_MSDU_SIZE issue (1.28 KB, patch)
2010-07-21 07:47 EDT, Nicola Baldo
Details | Diff
updated fix addressing all issues (5.27 KB, patch)
2010-07-23 12:47 EDT, Nicola Baldo
Details | Diff
Revised patch dealing with all issues (5.89 KB, patch)
2010-07-26 07:13 EDT, Hendrik vom Lehn
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Hendrik vom Lehn 2010-07-20 18:45:23 EDT
Created attachment 940 [details]
Mercurial patch for abovementioned changes

The WiFi model as it is currently used in ns-3 uses default values for frame sizes which (according to my unterstanding) differ from those of real Wi-Fi network cards. The problem is that the LLC header which is added by WifiNetDevice::Send is not taken into account.

The maximum MSDU size of WifiNetDevice is currently set to 2304 bytes, which is the correct value according to the standard. However, this value is only used to determine the MTU of the device and should thus be 2296 since the LLC header has to fit into the 2304 bytes.

Similar applies to the the default RtcCtsThreshold and FragmentationThreshold of WifiRemoteStationManager, which are currently set to 1500 byte. This means that only 1492 byte can be sent through WifiNetDevice::Send without using fragmentation and RTS/CTS handshake. Real Wi-Fi devices, however, allow to send 1500 bytes without the LLC header. (Like Ethernet allows to send 1500 bytes without the Ethernet header)

I would therefore suggest to change these values as in the attached changeset.
A further change might be required in WifiInformationElementVector, which has a maximum size of 1500 byte, but I am not sure about that since I do not know the mesh implementation internals.
Comment 1 Nicola Baldo 2010-07-21 07:47:26 EDT
Created attachment 941 [details]
revisited fix patch for the MAX_MSDU_SIZE issue

I confirm the problem for the use of MAX_SDU_SIZE for the calculation of the MTU. To solve it, I actually propose a different patch (attached), so that we leave the definition of MAX_SDU_SIZE as per the standard. This makes sense since the standard defines an SDU as including the LLC header.

As for the fragmentation threshold and RTS/CTS threshold, there is actually a small bug in the code. The standard (IEEE Std. 802.11-2007, Section 9.1.5) says:

"When an individually addressed MSDU is received from the LLC or an individually addressed MMPDU is received from the MLME that would result in a length greater than dot11FragmentationThreshold when the MAC header and FCS are added, the MSDU or MMPDU shall be fragmented."

So the fragmentation threshold should include LLC + MAC + FCS. The current code uses LLC only. I wonder what real devices use, e.g., what is the interpretation of the value passed to iwconfig. Whatever we choose to implement, we should document it clearly.
Comment 2 Nicola Baldo 2010-07-21 08:22:25 EDT
also dot11RTSThreshold in the standard refers to an MPDU, which implies that it includes MAC header + FCS trailer + LLC
Comment 3 Hendrik vom Lehn 2010-07-22 11:19:06 EDT
Regarding the MSDU size:
Your proposed solution to only change the calculation when using MAX_MSDU_SIZE is indeed cleaner than to change the value itself. But I would propose to change the UIntegerChecker and SetMtu() as well, because it is otherwise possible to set too large MTUs afterwards.

Most wireless network card drivers (at least those of Linux) actually use 1500 as MTU (just like Ethernet cards). So it might be worth to consider to change the default value to 1500 as well. But larger values are also fine since the 802.11 standard actually allows to send larger frames.
Comment 4 Hendrik vom Lehn 2010-07-22 12:10:15 EDT
Regarding the fragmentation and RTS thresholds:

I found 2346 byte for the fragmentation threshold and 2347 byte for the RTS/CTS theshold in Linksys routers and some Linux drivers that support these parameters.

The 2346 byte are probably composed as follows: 2304 byte for the MSDU, 8 byte WEP (not included in MSDU), 30 byte MAC header and 4 byte FCS.

Since the fragmentation threshold in ns-3 is compared to the size of the packet itself (without MAC header), there are from my point of view two options: Use 2346 as fragmentation threshold and subtract the missing sizes when using this value. Or use a lower value and document this clearly.

Whatever option is used, the default value should be large enough to accommodate 1500 byte of data (without the LLC header). With the current default value already 1493 byte of data (which can be transported using Ethernet) are fragmented using WiFi.

Most Wi-Fi drivers for Linux btw. use 1500 byte as default MTU (or do not allow larger MTUs at all). Frames larger than that are then fragmented using IP, which is of course a different behavior than MAC fragmentation. Therefore I would propose to use the maximum values as default for the fragmentation threshold.
Comment 5 Nicola Baldo 2010-07-23 12:47:26 EDT
Created attachment 948 [details]
updated fix addressing all issues

Here is a revised patch that addresses all the issues.

The RTS/CTS and fragmentation thresholds are now used as per the standard, i.e., they are compared with the MPDU size (including MAC header + FCS trailer). I also updated the default values according to your recommendation.

If you confirm that the patch is satisfactory, I'll push it to ns-3-dev and close this bug.
Comment 6 Hendrik vom Lehn 2010-07-26 07:13:00 EDT
Created attachment 952 [details]
Revised patch dealing with all issues

All in all your patch looks good, but I would still suggest two modifications:

a1) Increase the default values for rts/cts and fragmentation threshold to at least 1542 (1500 byte data + 8 byte LLC + 30 byte header + 4 byte FCS). Otherwise 1500 byte Ethernet-frames will get fragmented when they are sent over a WiFi link.
a2) A reasonable alternative would be to increase them to 2346 byte, because this is the default value of many wireless network card and access point  implementations.

b) Change the UIntegerChecker and SetMtu() for the Mtu as well, so that it is not possible to set larger values than the default value.

Attached is a patch with a2+b.
Thanks for your help with this issue!
Comment 7 Nicola Baldo 2010-08-02 07:18:29 EDT
changeset:   6473:86a4a149eb0f