RE: Broken PMTUD for . + TLD servers, was: Re: Smallest Transit MTU

["David Schwartz" <davids () webmaster com>]

> > ah i was meaning tcp, afaik it sets DF on at least win2k

> All OSes that I know of do this in order to do path MTU discovery. The
> PMTUD RFC encourages implementers to detect changes in the path MTU as
> fast as possible, which they took to mean "set the DF bit on ALL
> packets". Which is unfortunate, because in cases where PMTUD doesn't
> work, no communication is possible. Setting the DF bit on 50, 10, or 2
> % would accomplish PMTUD fine too, but it would also allow the session
> to survive brokennes.

        This is a bad idea. This would cause the case where every single packet is
fragmented to be indistinguishable from slight packet loss.

> > do any of those tiny resourced internet bootstrapping hosts exist?
> > perhaps we
> > can deprecate DF?!

> I've said I'd like to see this happen in the past. The trouble is
> without DF, current PMTUD doesn't work anymore, and router CPUs will be
> spending unnecessary CPU cycles on fragmentation. So some of the
> packets should trigger an ICMP too big, but others should just be
> fragmented. Figuring out the right mix probably requires some
> experimentation.

        Fragmenting packets that have the DF bit set is just wrong. The problem
should be fixed at the end hosts. Smart detection for MTU blackholes is
needed at the hosts, and this is best done by sending large packets as early
as possible, establishing that you have an MTU blackhole, and analyzing all
cases of packet loss for those that look like they're created by an MTU
blackhole.

        DS