Re: Another proposal to think about

[Steve Deering <[e-mail]>]

Rich,

Your proposal to handle MTU discovery at the TCP level sounds
reasonable, except that it only works for TCP.  That means we would
have to make similar changes to any other "packetization" protocols,
such as TP4 or VMTP or NFS, in order for them also to take advantage
of MTU discovery.  Furthermore, not all packetization protocols have
return traffic on which to carry the MTU/MSS information -- there really
are one-way datagram protocols (e.g., sensor reports, video streams, etc.),
and they too may need/want MTU discovery.

Granted, my proposal also requires changes to the local implementation of
each packetization protocol, but not to the actual protocol and packet
formats used over the network.  I imagine it would be fairly difficult
to get ISO to allow "TPDU size" options in TP4 data packets, for example.

If we were to adopt your proposal, I would want to add a new option
to the SYN segments, for requesting the use of MSS options in data
segments.  An old TCP would ignore the request, and the new TCP would
stick to the current strategy (i.e., assume an MTU of 576 or whatever).
That would get rid of the problems with new TCPs sending fragmented
segments to old TCPs, and would avoid confusing any old TCP that is
unprepared to deal with a TCP option in a data segment (in case there
actually are any such TCPs).

Some comments on other points you raised:

>	My understanding is that powers above won't allow the IP header
>	to change, except possibly for something absolutely ness.

What led you to this "understanding", and to which "powers" are you
referring?  Jeff is checking with Jon Postel to see if defining the
currently undefined bit is totally out of the question; I wasn't aware
that he had received an answer yet.  We *are* a working group of the
IETF, whose job it is to recommend improvements to the protocol suite.
Obviously, our recommendations must take into account compatibility with
existing implementations, and in my draft RFC I devote a section to
discussing the compatibility issues.  If there are concerns that I
missed, please post them here.

>	...I am inclined to think that the routing protocols should
>	handle this problem.

I've heard this suggested by others as well.  I'm not sure what you
have in mind, but the usual suggestion is that MTU information should
be exchanged as part of the routing protocol, and that hosts should
be able to get that information by asking a neighboring router, by
eavesdropping on the neighboring routers, or by actively participating
in the routing protocol.

The problem with this is that it is unreasonable to expect any router
to maintain the MTU for all possible destinations.  For example, you
wouldn't expect the internal routers at Stanford to know the path MTU
to reach each subnet at MIT.  They might know the *minimum* MTU or the
*maximum* MTU for MIT, but using the minimum would waste bandwidth when
sending towards a subnet with a larger path MTU, and using the maximum
would cause fragmentation when sending towards a subnet with a smaller
path MTU.

Now, I could imagine extending the routing protocol to support some
sort of "probe" mechanism to learn the MTU of a specific path when
needed by a particular host.  I think my proposal is better because
it uses the actual user data packets as the probe, reducing the
number of required packets and eliminating one RTT delay.

Steve