|
Re: MTUs - Was: Strange public traceroutes return private RFC1918 addresses
Date: Thu Feb 5 15:38:17 2004
From: "Kevin Oberman"
To: Warren Kumari
CC: nanog@merit.edu
> From: Warren Kumari
> 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
|
|