Subject: Re: TCP MSS option value

From: Bob Braden <[email-masked]>
Date: Sat, 22 Jan 2000 00:11:15 GMT

*> 
  *> 
  *> Please help me understand what RFC2581 intends regarding the value
  *> advertised in the MSS option when other options (e.g., Timestamp) are going
  *> to be used.
  *> 
  *> Suppose the MTU is 1500 bytes, and after the 3-way handshake a host is
  *> going to be sending on each segment 12 bytes of TCP options:  Timestamp
  *> plus two NOPs.  RFC879, "TCP Maximum Segment Size," says "THE TCP MAXIMUM
  *> SEGMENT SIZE IS THE IP MAXIMUM DATAGRAM SIZE MINUS FORTY" (all capital
  *> letters in  RFC879).  This implies that the host should advertise MSS=1460,
  *> but as  RFC 879 notes, when it was written there were "no TCP header
  *> options ... defined that would normally be sent at the same time as data
  *> segments."  RFC 1011 states "The TCP Maximum Segment Size is the IP Maximum
  *> Datagram Size minus forty," but sending TCP options with data segments was
  *> still an obscure subject when that was written.   Section 4.2.2.6, "Maximum
  *> Segment Size Option," of RFC1122, "Host Requirements -- Communications
  *> Layers,"  does not explicitly say what value to advertise in the MSS
  *> option, but it gives a formula for Eff.snd.MSS, "the maximum size of a
  *> segment that TCP really sends," that is based on SendMSS, "the MSS value
  *> received from the remote host," and the TCPhdrsize.  If one solves that

Ed,

The MSS option is NOT intended as an MTU discovery mechanism.  It
gives the max segment size the TCP receive and reassemble.  It does
not, and is not intended to, tell the sender how large a segment to
send.

It is strictly true, but perhaps irrelevant, that RFC 1122 does not
specify what value to send in an MSS option.  However, it DOES
give an upper bound on the value (MMS_R - 40) and a recommendation:
determine MMS_R as specified in sections 3.3.3 and 3.4 (I see it
should have referenced 3.3.2 also.)  When you dig down through
all that, you find that MMS_R = EMTU_R - 20, where EMTU_R is
the largest datagram IP can receive and reassemble... in other
words, 65532.

So the recommended answer is:  65532 - 20 - 20 bytes should be
sent in an MSS option.

So, back in the early days (early 1980s) the Berkeley Unix folks were
trying to make TCP work well, and they (re-)discovered that IP
fragmentation was a Bad Idea.  Rather than fix the protocol (by
inventing MTU Path Discovery), they put in a hack: set the MSS down to
the local interface MTU and hope.  This worked OK for awhile but was
not really the right answer.  The (perhaps painful) discussion in RFC
1122 was an attempt by a bunch of IETFers to set this business
straight.

Note that the value you should send in the MSS option has no relation
to the appearance of TCP options.  That is the problem of the sender
only.  What the sender has to do is complex.  When I implemented
the 1323 extensions and also T/TCP, I had to do considerable
hacking on the BSD TCP machinery to get right the logic that
determines a segment size to send. (I thought this was written
up somewhere, but I cannot find it in any of the relevant RFCs
now; maybe it was a comment in the T/TCP code).

Hope this helps,

Bob Braden

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 28 Jan 2000 11:15:17 -0500

> not, and is not intended to, tell the sender how large a segment to

Well, given that it provides an upper bound on segment size, it is
*pragmatically* the only knob you can use when attempting to
interoperate with systems not under your control with broken PMTUd
blackhole detection living in PMTUd black holes (like many web servers
living behind firewalls which block all ICMP).

Try surfing the web from behind a path with a bottleneck IP MTU of
1480 some time..  if you advertise an MSS greater than 1440, you'll
never see a full page from many servers..

						- Bill

---

From: Charles Esson <[email-masked]>
Date: Sat, 29 Jan 2000 06:04:02 +1100

Bill Sommerfeld wrote:

> > The MSS option is NOT intended as an MTU discovery mechanism.

There is a  relationship given in, rfc879 page 5, maybe it is  a game man
that relies on it. But rfc879 does make it pretty clear the MSS should be
less than the MTU.

> > gives the max segment size the TCP receive and reassemble.

But if the rules given in  rfc879 page 5 are followed the sender should be
able to assume the MTU is greater than the supplied MSS. So at least
fragmentation is avoided.

To know that the MTU is greater than the MSS is surely wasted knowledge,
you limit is still the MSS anyway.

Or has rfc879 been deprecated?

>  It does

Why? is there a rfc to back this statement up.