On Fri, 16 Jun 2000, Ted Schroeder wrote:
As one of the early evangelists for jumbo frames I can say with some amount of authority that the number we (Alteon WebSystems) were/are pushing for is 9000 bytes. There are other numbers bandied about, but 8940 was never one of them. 9216 was the other usual candidate as it matches up with ATM.
Come to think of it I can't see any good reason for 8940. FDDI is 4352, FDDI*2 is 8704. 9216 should behave nicely w/AAL5.
The IEEE will simply say, "only up to 1500 bytes". I've fought this battle with very little success. Rich's book will only talk about 1500 bytes. I've spoken to him about this a number of times and he's personally opposed to anything other than 1500 bytes.
I know there is a discussion of jumbo frames there, and its not terribly negative from what I can recall.
And, for those of you who think that things might get better in the future, let me be an omen for even worse times to come. For 10 Gb Ethernet, there are proposals on the table that will, for the first time, make frames larger than 1522 bytes physically impossible. These proposals have to do with speed matching between the WAN 10GE and the LAN 10GE and minimum buffer sizes used to accomplish this speed matching.
As one of the lone voices at the 802.3 meetings calling for longer frame support, I've pretty much given up on ever seeing a longer MTU officially supported by the IEEE. Perhaps if more people were going there that weren't hardware vendors with an "obvious interest in only pushing their products" the IEEE members would be more likely to listen. But I wouldn't necessarily bet on it. There was a push early on during PAR discussions of 10 GE to allow larger frames but it was clear that this was a losing battle, so the push ended.
Ugh, from an all around perspective I believe we need an MTU offically longer then 15??. Its better for applications, better for operating systems, better for anything that must be interrupted per frame/packet, better for anything which needs to work paged memory, and better for anything which needs to do routing per packet. 9000-range works well for server to server or backbone to backbone connections where you're aiming for NFS optimization or being able to support large packets without fragmentation across a NAP for example, but I would suggest you're aiming for trouble trying to take server-traffic past what is supported by FDDI/PoS, and 4k works well for many of the above problems. The standardization of a higher number is needed, or we are just going to see more of these problems as people seek to improve their networks in incompatible and confusion-introducing ways. PMTU-D has obvious problems. It would seem to me the cleanest course of action would be to put a fragmentation encountered flag somewhere along the line. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)