Subject: Re: MTU, MRU, and MSS

From: [email-masked]
Date: Wed, 4 Nov 1998 10:22:33 -0800

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

Note that RFC793 is not the latest word; this issue is discussed more fully
in RFC1122 (section 4.2.2.6).

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?

Bob Braden

---

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

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

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

Other situations (like TR's variable-length MRU) may not be "problems"
so much as they are "less efficient" solutions. An arguable position.

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

---

From: "Steve Alexander" <[email-masked]>
Date: Wed, 4 Nov 1998 12:58:55 -0800

> byte segments (as is found with all Microsoft-native PPP clients).

My recollection from implementing path MTU discovery some years back
is that the only way to get any reasonable performance from MTU
discovery is to break the segment size / MTU / MRU correlation that
seems so natural and always offer an MSS that is the biggest thing that
you can atomically receive on the link from which you received the SYN.

Otherwise, you always offer something either too big, or too small.

Unfortunately, since paths can change after the 3-way handshake is
completed, this is simply a SWAG over the life of the connection.
At some point, it might be cool if IP could indicate whether the
datagram was reassembled so that TCP could renegotiate the MSS during
the life of the connection.  Unfortunately, I think that you can't do
that by law, and if you could, most implementations would dry heave
regardless.

-- Steve