
![]() |
![]() |
![]() |
![]() |
This page explains why MTUs used in 802.11 networks are too small to provide optimal performance. Many of the arguments are adaptations of the ideas presented at [1] and [5].
There are strong arguments that the 1500 byte MTU (Maximum Transmission Unit) is too small for modern communications networks [5, 7, 1]. Despite large speed increases, mandatory Ethernet packet sizes have remained static since 1982. Table 1 shows that as Ethernet speeds have increased, serialization delays have dramatically decreased and MTUs have remained stagnant.
Small MTUs are inefficient for a few reasons. The packet headers contribute to an unnecessarily high percentage of overhead. Furthermore, there is also evidence suggesting that many small frames cause more CPU interrupts and processing overhead [1]. Whether this is still true, given increased CPU speeds and perhaps the migration of functionally onto NIC's is unknown. The original argument against using larger packet sizes in wired networks was serialization delays. However, table 1 clearly shows that in modern Ethernet networks, this argument is no longer valid.
| Technology | Rate | Year | MTU | Serialization Delay |
| Ethernet | 10 Mb/s | 1982 | 1500 | 1200 µs |
| Fast Ethernet | 100 Mb/s | 1995 | 1500 | 120 µs |
| Gigabit Ethernet | 1000 Mb/s | 1998 | 1500 | 12 µs |
| 10-Gigabit Ethernet | 10000 Mb/s | 2002 | 1500 | 1.2 µs |
Wireless 802.11 networks have higher Mandatory MTU's than 802.3 Ethernet networks. Table 2 shows the MTUs for the different 802.11 physical layers. Note that the increased MTU size in 802.11n was likely made to accommodate A-MSDU. Similar to Ethernet networks, using modern wireless technologies, serialization delays are no longer a limiting factor. The maximum frame size of 7935 bytes in 802.11n is now serialized in about 7.5 times less than a 1500 byte frame in 802.11b.
| Technology | Rate | Year | MTU | Serialization Delay |
| 802.11b | 11 Mb/s | 1999 | 2272 | 1091 µs |
| 802.11g | 54 Mb/s | 2003 | 2272 | 222 µs |
| 802.11n | 432 Mb/s | 2009-2010 | 7935 | 28 µs |
Transmitting larger packets rather than aggregating 1500 byte packets has a number of benefits. The most obvious is the savings on, MAC headers, IP headers and TCP headers. Because fewer packets are required to send the same amount of data, fewer (MAC/IP/TCP) headers must be sent, lowering overheads. By the same merit increasing packet sizes also reduce the number of preambles, IFS, frame trailers and 802.11 acknowledgments.
There are a number of reasons why Internet MTUs have not scaled in the manner that would provide optimal performance. The traditional argument against larger packet sizes is that the larger serialization delays can cause high priority packets to be delayed. LAN switch vendors also found it unfavorable to do fragmentation between switches not capable of higher MTU's, requiring additional memory and processing. Perhaps another reason is because in most environments other than supercomputing environments, the performance benefits did not justify the additional complexity. The biggest reason is because the initial MTU Discovery defined in RFC 1191 [6] was flawed in many ways. The reasons for this failure are documented in RFC 2923 [2].
In the current day, many of these traditional arguments are invalid. Wired and wireless speeds have changed such that the 1500 byte MTU used since 1982, is a significant limitation. Finally, the problems that plagued previous path MTU discovery [6] were solved in 2007 with RFC 4281 [3]. Given that MTU problems have now been rectified, an analysis of the potential benefits to wireless networks is justified. The main arguments for larger packet sizes, namely the reduction in preambles, IFS, frame trailers and 802.11 acknowledgments are obvious and have already been mentioned. Other implications of MTU scaling are more complex and deserve detailed analysis.
Increasing packet sizes beyond 1500 bytes can have a significant effect on end-to-end throughput. In Mathis seminal paper [4], it is stated that end-to-end throughputs are bound by the equation below where, p is the loss probability:

If we assume, as a worst case, that packet losses do increase linearly with packet sizes, end-to-end bandwidths still increase. In fig 2, we show the effect of increasing MSS and packet loss rate over a range of delays. We have plotted the points starting with a 1500 byte packet with 2% packet loss and finishing with a 12,000 byte packet with 16% loss. While packet loss can increase with packet size, it has an inverse square effect on throughput, which means that MSS still dominates [1]. This graph shows that even if packet loss did scale linearly with packet sizes, end to end bandwidth would still benefit from increasing packet sizes. This equation only holds for flows that are BDP (Bandwidth Delay Product) limited.


We performed an experiment where we removed every fourth TCP ack (a loss rate of 25%) from a TCP transfer over 802.11. Given this very high loss rate we noticed no difference in the end to end transfer rate. The reason being that TCP acks are cumulative hence, if a TCP ack is lost, the arrival of the following TCP ack will acknowledge all of the previous data. Thus we propound that increasing the MTU may generate fewer TCP acks allowing more time for data transmission. Also, using MAC layer acknowledgments to provide reliability for TCP acks is unnecessary as our experimentation suggests that high loss rates make little difference to transfer speeds.
To conclude, we believe that there are equally as many compelling reasons for higher packet sizes in 802.11 networks as in wired networks. Many of the standard arguments that apply in wired networks such as lower overheads and higher BDP also apply, however, in addition, the shared half duplex medium of 802.11 means that there will be further benefits such as fewer 802.11 acks and potetially fewer TCP acks.
[1] P. Dykstra. Gigabit ethernet jumbo frames and why you should care. www.wareonearth.com/whitepapers/GigabitEthernetJumboFrames.pdf, December 1999.
[2] K. Lahey. Tcp problems with path mtu discovery, ietf rfc 2923. IETF RFC, 2000.
[3] M. Mathis and J Heffner. Packetization layer path mtu discovery, rfc 4821. IETF RFC, 2007.
[4] M. Mathis, J. Semke, and J. Mahdavi. The macroscopic behavior of the TCP congestion avoidance algorithm. 27(3)(3):67-82, 1997.
[5] M. Mathis. Raising the internet mtu. http://staff.psc.edu/mathis/MTU/, 2009.
[6] J. Mogul and S Deering. Path mtu discovery, rfc 1191. IETF RFC, 1990.
[7] W Rutherford, L Jorgenson, M Siegert, P Van Epp, and L Liu. 16 000-64 000 b pmtu experiments with simulation: The case for super jumbo frames. Supercomputing: Optical Switching and Networking Computer Communications Review, 4(2):121-130, 2005.