Re: How to use an IP-header bit for Path MTU discovery.

[mogul (Jeffrey Mogul)]

    Each host-route entry would include a flag meaning "the last oversized
    packet I received from this recipient was NOT fragmented".  It should
    be turned on when the host route is created.  A host would simply copy
    this bit into all the IP packets that it sends to the other host and
    would start out with its favorite large MTU.
    Recipients of this bit use it by simply switching to a smaller MTU
    (576) if the bit is clear.  If they are talking to a host without the
    feature, they simply always switch down.

This is clever, and (as far as I know) novel.  It has some potential
problems, including the ones you mentioned, but especially the problem
common to all the RF-bit schemes: how many routers and end hosts will
drop packets with the bit set?  It would also break against those PCs
that cannot reassemble fragments; at least the "handshaking RF" scheme
solves this issue.

I tend towards liking this proposal for the simplicity of the
"two candidate MTU" approach; we already have some experience with
this kind of behaviour (cf. the "subnetsarelocal" flag in some versions
of BSD and BSD-derived systems).  Basically, if one is forced to think
of how many rational possibilities there are for the sender's segment
size, one can easily come up with 2: "576" and the first-hop-net MTU.
Coming up with a third choice is only necessary if we believe that
it is too far from optimal to be stuck with these two choices.

-Jeff