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

[[e-mail]]

The best solution to the MTU problem seems to be to augment
the routing protocols to slosh MTU information around the net.
Then, your local gateway can give you sound hints about what MTU
to use for your desired destination. But this sort of solution
may not happen quickly.

Accordingly, the value of any other solution, in my mind, depends
intimately upon its deployment time. The question of "can we get
a header bit?" is less interesting than the question of "what
needs to be deployed for the mechanism to work?"

The question of a header bit is important because it determines
the cost of the discovery mechanism, but it is not very problematic.
In the absence of a header bit, the performance cost of an IP
option may be prohibitive. But neither the cost of IP option
processing nor the availability of a header bit seem to be issues
that will benefit from a great deal of debate.

Rather, a more interesting question is "what software changes are
required by whom in order for the mechanism to work?"

Clearly, the sending host needs to participate in any MTU discovery
mechanism in order for it to work (amazing deduction, huh?).

Clearly, some cooperation is also needed from some set of
gateways on the path and/or the receiving host, but the nature
and extent of this cooperation is pretty much the central (only?)
question of this effort.

If one is concerned about deployment times, the best mechanisms
are those that have a chance of working even in the absence of
universal deployment. One can argue about whether gateways or
hosts are updated more quickly, but one might also do well to
consider strategies that beg the question.

STRAW MAN:

At the Sending Host:

The IP user (e.g., a TCP connection) turns on the "RF Option" (or
header flag, if you prefer) on "appropriate" outgoing IP datagrams.
This option/flag is NOT copied on fragmentation (i.e., it always
sticks to the first fragment).

At the Last Hop Gateway (post fragmentation processing):

If the "RF Option" is set on a locally-destined packet, and if the MF
flag is set on said packet, then the gateway sends an ICMP Report
Fragmentation message back to the source. The Total Length field of
the IP header in the data portion of said ICMP message will reflect
the least MTU along the path. The "RF Option" of said packet is
then removed/turned off, the header checksum is recomputed, and
the packet forwarded on its way.

At the Receiving Host:

If the "RF Option" is set on a received packet, and if the MF
flag is set on said packet, then the host sends an ICMP Report
Fragmentation message back to the source (as above).

Discussion:

This mechanism requires deployment of new software in the sending
host AND EITHER the last hop gateway OR the receiving host. Thus,
it begs the question of whether gateway software is more quickly
updated than host software. Either way, you win.

If the header rewrite and recomputation of the checksum at the
last hop gateway seems onerous, observe that the mechanism works
nearly as well even if you don't do it. In cases where both the
last hop gateway AND the receiving host have the new software,
the result would be 2 ICMP messages directed back at the source.
Even this cost can be avoided by administratively disabling host
generation of ICMP RF messages on networks where the relevant
gateways already support this feature.

A weakness of this idea is that it does not win at all if neither
the last hop gateway nor the receiving host has new software. In
particular, if all the gateways in the net are smart, but your
last hop gateway (and destination host) is dumb, then you lose.
This weakness is addressed by strategies in which all the smart
gateways cooperate to give you an upper bound on the MTU. It is
not clear to me, however, that an upper bound on the MTU is worth
the effort of computing it. If you aren't stopping fragmentation
completely (on a given path), there seems little point in (possibly)
reducing it.

More grist for the mill,
Chuck