Re: yet another MTU discovery scheme

[Steve Deering <[e-mail]>]

>	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.

Right.  In case it wasn't clear from my description, I should point
out that this does get fixed when the gateway to the sub-576 hop is
upgraded to include the MTU in its Can't Fragment messages.

>	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).

The RF-bit scheme will also work with fragmenting "bridges", assuming they
carry the RF-bit through into the fragments.

>	What would be more interesting is to get a picture of how many paths
>	would suffer from the "non-local double-shrink" problem...

Agreed.  The DF scheme as I described it allows the MTU of a single-shrink
path to be discovered in less than the RTT to the destination, and the MTU
of a multi-shrink path to be discovered in *possibly* (but not necessarily
-- it depends on where the shrink points are) greater than the RTT to the
destination.  If there are many more single-shrink paths than multi-shrink
paths, this will yield lower *average* discovery delay than, say, a scheme
based on probing all the way to the destination (or last-hop-router).

How about this issue of ID wraparound?  The odds of incorrect reassembly
due to ID wraparound seem extremely small to me.  I think it requires that
a fragment hang around in the Internet or in a reassembly buffer while
65,535 more packets with the same source, destination, and protocol
pass it by, and that the 65,536th packet be fragmented.  Assuming the
hosts are incurring only occasional fragmentation, as in the RF-bit
scheme, is incorrect reassembly going to happen more often than, say,
the delivery of packets with bit errors that are not detected by the
TCP checksum?

Steve