Subject: Re: MTU, MRU, and MSS

From: Vernon Schryver <[email-masked]>
Date: Wed, 4 Nov 1998 11:21:45 -0700 (MST)

> From: "Eric A. Hall" <[email-masked]>

> > Instead, a slightly modifed version of the familiar BSD computes a nice
> > value for the MSS that is based on the link MTU
>
> Well, that's the question. Shouldn't this be calculated according to
> MRU, particularly in those situations where MTU and MRU differ (PPP
> circuits with different MTU and MRU sizes, TR nets with fixed MTU but
> variable MRUs, etc)? 
>
> In such cases, the MSS should be defined according to the MRU of the
> local network, according to RFC 793 anyway. What value is there in
> deriving MSS from MTU instead?

In the case of PPP, things are not as simple as you imply.  It is
fairly common that the MTU and MRU change during the lifetime of
the connection.  Consider the effects of negotiating CCP or ECP on
the PPP MTU and MRU.  Consider also what happens if your PPP code
drops in and out of MP encapsulation as the number of links increases
to more than one and returns to one.

Then there is the fact that absolutely every conformant PPP
installation has an MRU of at least 1500, but may have a much
smaller configured MTU.  (While the PPP chitchat allows an PPP
system to ask for an MRU of less than 1500, it can always be forced
to accept 1500 by the peer Configure-Reject'ting the MRU option.)

Hosts tend to not talk directly to the boxes that know about the worst
complications of MTUs and MRUs.  They tend to talk to a LAN that has a
single value for the MRU and MTU.  (If your IP/802.5 code has differing
MTU and MRU, then I would not call that wonderful feature.)  In practice,
using a single value for both the MRU and MTU is good enough.  That it is
called the MTU reflects the fact that the MTU is the constraint on what
the system can choose to do, while the MRU is an implementation limitation.

Vernon Schryver    [email-masked]

---

From: [email-masked]
Date: Wed, 4 Nov 1998 10:49:12 -0800

*> 
  *> It's a problem when the implementing TCP insists on sending an MSS of
  *> 1460, even though the MRU of the PPP link may only be capable of 536
  *> byte segments (as is found with all Microsoft-native PPP clients).
  *> 

Sorry, I don't understand here whether it is Microsoft-native PPP
that is broken here, or TCP?

Bob

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 4 Nov 1998 12:48:53 -0700 (MST)

> Okay, so 1191 and 793/1122 are in conflict. Which wins?

Whatever works.

Consider the large computers of a few years ago with their 100 MByte/sec
"slow speed channels" connected to FDDI interfaces that necessarily used
the FDDI MTU but a TCP MSS of 32K to talk to nearby systems.  That was done
for good and sufficent real life reasons.  4.3BSD (perhaps only after Reno)
could both send and receive such fragment segments.

---

From: David Borman <[email-masked]>
Date: Wed, 4 Nov 1998 14:00:00 -0600 (CST)

> Date: Wed, 04 Nov 1998 10:48:06 -0800
> Subject: Re: MTU, MRU, and MSS
>
>
> > Note that RFC793 is not the latest word; this issue is discussed more
> > fully in RFC1122 (section 4.2.2.6).
>
> 1122 clarifies that systems must use MSS of 536 if not specified. It
> doesn't change the notion of MRU being the seed for MSS (when it does
> get specified). Indeed, it clarifies that MSS should be restricted to
> MSS_S, which is just another way of saying MRU.
  ^^^^^
A nit, that should be MMS_R, the maximum receive transport-message size.

> > However, I am not aware of any consideration of the possibility
> > that MTU and MRU (which I assume means Maximum Receive Unit?) might
> > be different.  Is this really a problem?
>
> It's a problem when the implementing TCP insists on sending an MSS of
> 1460, even though the MRU of the PPP link may only be capable of 536
> byte segments (as is found with all Microsoft-native PPP clients).

This should not be a problem unless the TCP receiving the MSS has bugs.

1)  On the machine that has the PPP link, the PPP layer should be
    communicating up to TCP that it received an MRU of 536, and TCP
    should then limit itself to sending packets no bigger than that, no
    matter how big the value is in the MSS option that it received.

2a) If the TCP is not the machine that has the PPP link, then if it
    implements PMTU Discovery, it shouldn't matter that the received MSS
    is larger than the MTU of one of the links in the path, that will be
    discovered.

2b) Otherwise, if it doesn't implement PMTU Discovery, then it doesn't
    know about the MTUs along the path, so since the remote machine is
    not on a local network, the TCP should be limiting it's packets to
    EMTU_S <= 576, which implies MMS_S = 556, or an Eff.snd.MSS = 536.

See RFC 1122 for more details.

In a nutshell, a well implemented TCP/IP should handle this situation
just fine.  Valid configurations that expose bugs in implementations
should not invalidate those configurations, the implementations should
be fixed.

		-David Borman, [email-masked]