Re: Another proposal to think about

[sytek![e-mail] (Rich Fox)]

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

Yes your right, I only gave an example for TCP. But don't let this throw
you. In my note I gave a long description of how a TCP connection will
quickly converge on the path MTU. The only real new idea that was added
in this model was the fact that IP must report to the transport layer
above that fragmentation occurred and the size of the largest fragment 
( fragment 0 ). In your proposal I believe that this notion also exists!!
Since this information can be presented to UDP or any other transport layer
protocol, mtu discovery can be handled WITHOUT any changes to the IP header,
or the meaning of the IP header. This was the single most important point I
wanted to state in my proposal. I think in either of our solution the transport
protocols need to be notified as to what the mtu is, and each protocol will be
able to deal with that information as they choose.


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

My proposal does not change the actual protocol or packet formats. It, like
yours, requires changes to the local implementation of each packetization
protocol.

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

The host requirements doc says that all hosts must support sending and receiving
of the MSS option. It dusn't say that it must only support at SYN time, but it
says must support. So I think according to the HR doc you can send an MSS option
at any time. I believe that my proposal recovers from lost data frames with an
MSS option included.


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

Yes, you are right. That is why I say I am inclined to believe that the
routing protocols should handle the problem, and not that I am convinced
that they should. I surely do not want subnet routes advertised as well with
say RIP. I think the amount of traffic generated by RIP is one of the reasons
for all of the work being done in routing today. THe last thing I want to do
is add more traffic to RIP or require a new protocol to have to bear the grunt.
So at this point I am undecided as to whether or not the routing protocols
should handle mtu discovery, that is one of the reasons that I made the proposal
that I did.


thanks rich