From: Warren Kumari <warren@kumari.net> Date: Thu, 5 Feb 2004 15:04:00 -0500 Sender: owner-nanog@merit.edu

Ok, I know that this is getting away from the original thread, but I've always wondered this...

Why is the MTU on Ethernet 1500 bytes? I have looked through various docs (eg IEEE Std 802.x) and can find where maxUntaggedFrameSize is listed as 1518 octets, but there is no mention of why this was chosen. I know where the minimum frame size comes from (CSMA/CD and propagation times, etc), but the maximum frame size number sounds fairly arbitrary.

It is based on the original 10Base5 (yellow hose) Ethernet and was largely "picked out of the air" to meet several design criteria. One was the cost of buffering on the card. Back then, 2K of buffer was expensive and the designers wanted to allow for $500 NICs. This was in the late 1970s and this was no trivial feat. Early Ethernet cards were several K and taps were typically over $200. And that awful AUI cable that always came loose (the designer has publicly apologized for that) was usually at least $50. Another issue was how long a system with a packet ready to transmit might have to wait for a transmission to end so that it could have a shot at the wire. (Remember that in the 10Base5 days it was not uncommon to see 50 or 100 taps on a single cable.) At 10 Mb/s, long frames would have been prohibitively time consuming. Also, a large percentage of network traffic in these pre-web days was telnet with huge numbers of 64 byte frames and few over 1K. So 1518 seemed reasonable. When FastEthernet was developed by Grand Junction, the idea of expanding the frame size first came up. At 100 Mb/s, 1500 bytes no longer took very long. But that made for problems in bridging between 10Base5 and 100Base-T networks. There was no good way to break up a 4K frame into 1518 byte frames in a switch and, while many schemes were suggested none proved practical and the idea faded. Then came GigE and 1518 bytes was getting to look very silly. But the issues of bridging and fragmentation remained and, after LOTS of debate, the 1518 byte frame limit was left in place. But the idea did not die and many companies started producing equipment that could handle larger frame sizes. It worked pretty well because most GigE links were point-to-point between end systems switching to slower speed links less common. Finally we got to 10GigE and 1522 (extended for vLANs) was absolutely ridiculous, but at least one large vendor fought had to retain the size and, in the end, the 10GigE spec specified the same maximum frame size. The only reason now was cost. At 10GigE, buffers already had to be very big as a great many frames had to be stored just to handle "normal" traffic was congestion. Some vendors were selling relatively cheap switches with VERY limited buffering. To move from 1520 to 4K or 9K would have required a significant increase in buffer size and that would have made the switches much more expensive. So there we are. Want to bet on whether 40 GigE will still have the 1522 byte limit? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634