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 <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)
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.
Well, that's pretty much what we have now. ICMP Destination Unreachable Code 4 says "fraq required but can't" which is about as precise as you can get and still preserve functionality. What would be the merit of an explicit "fragged" message in comparison? They would get generated much more often and in many of those cases the message would be unnecessary, useless noise. Do you really want to know that every NFS message you sent got fragmented? Or do you mean only for specific TCP sessions? Transport-layer flags only work when segments are received and responses can be sent by the receiving end-station, which isn't guaranteed at all (especially when excessive fragmentation causes increased loss due to reassembly problems). The current design works even when the segments are not received by the end-station, which is a very good thing. And then we get into the problems of defining a new flag. Are you going to reuse bits in the TCP header (I can assure the answer to that is "no"), or do you want a new option? How long would a new option take to be deployed by a significant number of implementations? 1 year? 5 years? more? ICMP DU Code 4 already has a tremendous head-start here given that it's a standard part of the protocol suite that is already implemented in most of the systems. And since PMUT-D works with the older messages or with newer enhancements to the old message, it will always have many more implementations than any replacement design you can come up with. It should be obvious that the solution used now is the right approach for the problem at hand, given the diversity of the networks and systems that make up the Internet. Moreover, new messages aren't necessarily going to make the protocol work any better; if anything they would cause more problems than they would solve. Most of the problems that result with Path MTU Discovery are more due to infrastructure devices being purposefully misconfigured than anything. Either people are filtering ICMP messages when they shouldn't, or they are using private addresses on public networks, or they are making some other administrative decision that breaks PMTU-D and other services and then complaining about how poorly the protocols react when the network is misconfigured. That's not really a legitimate complaint. The right complaints would be to the vendors and network designers who are breaking the protocols in the first place. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
participants (2)
-
Eric A. Hall -
Richard A. Steenbergen