Home page logo
/

nanog logo nanog mailing list archives

Re: MAE-EAST Moving? from Tysons corner to reston VA.
From: "Eric A. Hall" <ehall () ehsco com>
Date: Sat, 17 Jun 2000 08:46:37 -0700



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/



  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]