Subject: MTU, MRU, and MSS

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 04 Nov 1998 07:53:27 -0800

Question about PPP MTU/MRU sizes and how they affect the MSS being
advertised in various implementations:

RFC 793 states unequivocably that the local network's MRU should be used
for the value that is advertised in the MSS:

        Maximum Segment Size Option Data:  16 bits

          If this option is present, then it communicates the maximum
          receive segment size at the TCP which sends this segment.

However, many of the systems I've been testing don't seem to do this,
instead choosing to advertise a (predetermined) fixed size that has no
relation to the negotiated MRU. Also, some systems seem to use the MTU
for the MSS, even though MRU should be the deciding factor since A) the
spec says so, and B) anything larger would fragment.

Does anybody have a good reason for not defining MSS based on MRU?

-- 
Eric A. Hall                                            [email-masked]
+1-650-685-0557                                    http://www.ehsco.com

---

From: [email-masked] (Alan Cox)
Date: Wed, 4 Nov 1998 17:24:05 +0000 (GMT)

> Does anybody have a good reason for not defining MSS based on MRU?

Pre MTU BSD always advertised a lower MSS for 'non local' connections.
Linux uses the MTU but allows the user to override the value, SGI's 
appear to advertise a fixed max of 48K on HIPPI. 

There are plenty of reasons for being the MSS size

o	To keep window > 2*mss for performance
o	To get optimal sized buffers from the remote end for local
	host speed
o	To avoid fragmentation on mixed media paths without MTU
	discovery

Alan

---

From: [email-masked] (Alan Cox)
Date: Wed, 4 Nov 1998 17:48:06 +0000 (GMT)

> Pre MTU BSD always advertised a lower MSS for 'non local' connections.
   ------^
 discovery

---

From: "Kevin M. Lahey" <[email-masked]>
Date: Wed, 04 Nov 1998 10:37:56 -0800

In message <[email-masked]>"Eric A. Hall" writes
>          receive segment size at the TCP which sends this segment.

Doesn't this mean the largest segment that can be reassembled on
that host, rather than the largest frame that can be received over
that link?

RFC1191 (Path MTU Discovery) suggests:

   The MSS option should be 40 octets less than the
   size of the largest datagram the host is able to reassemble (MMS_R,
   as defined in [1]); in many cases, this will be the architectural
   limit of 65495 (65535 - 40) octets.  A host MAY send an MSS value
   derived from the MTU of its connected network (the maximum MTU over
   its connected networks, for a multi-homed host); this should not
   cause problems for PMTU Discovery, and may dissuade a broken peer
   from sending enormous datagrams.

          Note: At the moment, we see no reason to send an MSS greater
          than the maximum MTU of the connected networks, and we
          recommend that hosts do not use 65495.  It is quite possible
          that some IP implementations have sign-bit bugs that would be
          tickled by unnecessary use of such a large MSS.

Given the number of asymetric routes out there, it seems to make
some sense to send the maximum of the MRUs of the interfaces
on the host.  This is what we do in NetBSD right now, although
I've heard reasonable arguments for using the MRU of the interface.

Given the number of run-time configurable network interfaces out there,
I wonder how useful the MSS is at all?  What if I boot my system on the
Ethernet, establish a connection, and then fire up my [mythical]
PPP-over-SONET interface?  It'd be nice for the connection to adjust to
use all of the available MTU.  Wouldn't this be useful for mobile
applications as well?

Kevin
[email-masked]

---

From: "Kevin M. Lahey" <[email-masked]>
Date: Wed, 04 Nov 1998 11:14:39 -0800

In message <[email-masked]>"Eric A. Hall" writes
>
>> > If this option is present, then it communicates the
>> > maximum receive segment size at the TCP which sends this segment.
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>My interpration is that this means "one whole segment," but I could be
>wrong. If as you say, the question is moot.
>
>>    as defined in [1])
>Okay, so 1191 and 793/1122 are in conflict. Which wins?

Actually, I don't think there is really much of a conflict.
RFC 1122 says:

            The MSS value to be sent in an MSS option must be less than 
            or equal to:

               MMS_R - 20

            where MMS_R is the maximum size for a transport-layer
            message that can be received (and reassembled).  TCP obtains
            MMS_R and MMS_S from the IP layer; see the generic call
            GET_MAXSIZES in Section 3.4.

Kevin
[email-masked]

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 04 Nov 1998 10:54:43 -0800