1500 MTU made sense when network was 10 megabit/s.
Now that we have gig and 10GE (and soon general availability of 100GE), I don't understand why 9000 makes people excited, if we're going to do a serious effort towards larger MTU, let's make it 150000 then (100x) or at least 64k.
the reason ieee has not allowed upping of the frame size is that the crc is at the prudent limits at 1500. yes, we do another check above the frame (uh, well, udp4 may not), but the ether spec can not count on that.
randy
The CRC loses its effectiveness at around 12K bytes so yeah, 64K bytes would probably require a change to detect all possible double-but errors. But 9K bytes is still within the effective range of the current CRC algorithm.
From Dykstra:
"'Jumbo frames' extends ethernet to 9000 bytes. Why 9000? First because ethernet uses a 32 bit CRC that loses its effectiveness above about 12000 bytes. And secondly, 9000 was large enough to carry an 8 KB application datagram (e.g. NFS) plus packet header overhead. Is 9000 bytes enough? It's a lot better than 1500, but for pure performance reasons there is little reason to stop there. At 64 KB we reach the limit of an IPv4 datagram, while IPv6 allows for packets up to 4 GB in size. For ethernet however, the 32 bit CRC limit is hard to change, so don't expect to see ethernet frame sizes above 9000 bytes anytime soon." But it actually washes because if you have a larger packet size, you have fewer packets so while you might have a higher "false pass" rate on the larger packets, since you have fewer packets involved, the actual false pass rate for a given amount of data is virtually unchanged. http://staff.psc.edu/mathis/MTU/arguments.html#crc