re: TCP maximum segment size determination

Jeffrey Mogul (
16 Nov 1987 1704-PST (Monday)

Craig Partridge writes (regarding the use of a "probe" mechanism
to find out the real MTU of a path):

    By the way, the scheme is sound even if the path changes if you
    treat the IP option and the TCP MSS values as distinct.

I would amplify this: any mechanism to discover MTUs should be viewed
as an IP-level mechanism, available to all protocols (not just TCP).

TCP, in turn, should already be asking the IP layer "what is the largest
appropriate MTU for this connection/destination/path?" and then never
sending anything larger. This can be done in the absence of any new
protocol, and is in fact approximately what is done in 4.3BSD (except
that there the layering is somewhat blurred, in that the TCP code goes
and looks directly at the interface MTU, rather than asking IP via
a nicely abstracted interface.)

Craig is also right that if the MTU changes during a connection (e.g.,
because the route changes) then it should be possible to adapt. However,
instead of using his proposed mechanism (as I understand it) of:
        TCP receives redirect
        TCP initiates new probe
        TCP updates MSS
I would instead keep most of this at the IP level
        IP receives redirect (or "time to re-probe" timer expires)
        IP initiates new probe
        IP receives probe info and passes new MTU to TCP analogous to
                what it does with a source quench
Thus, TCP only has to accept MTU values from IP, not manage the protocol
of obtaining them.

If packets are traveling along paths with different MTUs, and the
rate at which paths change is faster than 2*RTT, then perhaps it should
be possible to recognize this and simply stick with the lower (lowest)
MTU rather than try to second-guess what is either an oscillating or
load-balancing gateway. How often does this happen, though?

I think it's important to realize that we should be able to obtain
moderate improvements in the likely cases without having to try for
optimal behaviour in the general case.


This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:39:56 GMT