Re: yet another MTU discovery scheme

[mogul (Jeffrey Mogul)]

Steve's new alternate proposal (let's call it "using DF", since
at the IETF meeting we determined that the only other use anyone
knows for DF is Van's MTU-tracer) has one big advantage: since
it purports to guarantee no fragmentation, it should solve the
problem of the bogus PC implementations that cannot reassemble.

Actually, Steve's scheme could allow fragmentation if there are
sub-576 MTU hops, but this is already the case so it doesn't
break anything in a new way.

The other advantage I see is that it should be possible to make
FDDI-to-Ether bridges fit in, if they end up doing IP fragmentation
(which I sincerely hope they don't).  Since one would assume that
they obey the DF bit, in the worst case they would cause an MTU of 576;
if they sent new-style ICMP Can't Fragment messages, they would get
the Path-MTU set right.

    Possible problem: gateways that do not send ICMP Can't Fragment messages
    when they should.  Are there any such gateways?

Since Van already used the DF/Can't Fragment mechanism to trace MTUs,
he should be able to answer this pretty easily (we just need to enumerate
the several dozen or so gateway implementations, and try each one).

What would be more interesting is to get a picture of how many paths
would suffer from the "non-local double-shrink" problem: i.e., you
would find the MTU shrinking at more than one gateway not in your
local campus.  I could imagine this happening if certain backboney links
are built out of SLIP/PPP or ARPANet technology.  This could mean
wasting several RTTs while the correct MTU is being discovered.

-Jeff