|
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.
> 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/
|