|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: MAE-EAST Moving? from Tysons corner to reston VA.
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 <[email protected]> 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)
|