Re: yet another MTU discovery scheme

[Steve Deering <[e-mail]>]

>	But if the MTU is not returned in the Can't Fragment message, one
>	must determine the appropriate size (or revert to 576 byte datagrams).

I was suggesting that the MTU *would* be returned in the Can't Fragment
message.  Here is what I wrote:

	The variation I am proposing is to have the gateway that generates the
	Can't Fragment message include the recommended MTU (that is, the MTU
	of the next hop) in the 32-bit "unused" field of the Can't Fragment
	message.  (I'll call that field the "Recommended MTU field".)

In response to Can't Fragment messages from old gateways that don't yet 
report the MTU, the sender assumes the MTU to be 576, thus reverting to
the currently-approved behavior.  As the gateways are upgraded to include
the MTU in the Can't Fragment messages, and hosts are upgraded to take
advantage of it, optimal MTUs will be used and fragmentation will be avoided.

One nice thing about this scheme is that any host can start using it
today, without waiting for any gateway or receiver to be upgraded, and
still obtain some benefit -- if the path-MTU to any particular destination
is at least as big as MIN(first-hop-MTU, MSS), the host will take advantage
of it; otherwise it will back off to 576.  That's better than the current
situation, in which 576 is used for *all* off-subnet (or off-network)
destinations.  For instance, if Ethernet hosts started sending 1500 byte
packets with DF bit set, those packets could make it across most NSFnet
paths without incurring fragmentation *or* incurring any Can't Fragment
messages.

Steve