Subject: Re: TCP MSS option value

From: Thomas Narten <[email-masked]>
Date: Fri, 04 Feb 2000 13:02:00 -0500

Bob,

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

This makes complete sense (and the same rule applies to IP
options). I.e, what the MSS option should be communicating is precise
information that allows the sender to send a maximal sized packet that
will be properly reassembled by the receiver.  If the sender includes
options (whether TCP or IP) it needs to take that into account when
sending the TCP segment.

Likewise, a receiver has no way of knowing what options its peer will
be sending (i.e., they could vary on a segment-by-segment basis), so
it should not consider options when calculating the MSS value it
advertises.

Bottom line, the sender and receiver need to agree on what the MSS
value really means. Looking way back to RFC 879, it very clearly
states:

>    The MSS counts only data octets in the segment, it does not count the
>    TCP header or the IP header.

and later:

>    The relationship between the value of the maximum IP datagram size
>    and the maximum TCP segment size is obscure.  The problem is that
>    both the IP header and the TCP header may vary in length.  The TCP
>    Maximum Segment Size option (MSS) is defined to specify the maximum
>    number of data octets in a TCP segment exclusive of TCP (or IP)
>    header.

Later RFCs seem consistent with this, but sometimes are a bit
imprecise in the exact language used regarding options.  

RFC 2581 says:

>    RECEIVER MAXIMUM SEGMENT SIZE (RMSS):  The RMSS is the size of the
>       largest segment the receiver is willing to accept.  This is the
>       value specified in the MSS option sent by the receiver during
>       connection startup.  Or, if the MSS option is not used, 536 bytes
>       [Bra89].  The size does not include the TCP/IP headers and
>       options.

There is a bit of an ambiguity here with this definition. First, the
MSS doesn't really mean "largest segment the receiver is willing to
accept", it means largest data part that can be accepted in a received
segment, assuming the segment has minimal IP and TCP headers (e.g.,
N-20-20)".

Mentioning "options" in the same sentence as "does not include the
TCP/IP headers and options" is confusing, as it could be read to imply
that the receiver needs to understand about what options will be
received, and adjust the MSS advertisement as appropriate. But the
receiver has no way of knowing what options will be sent (and when),
so the mentioning of options in the context of the MSS advertisement
is inappropriate. All talk about options should be dealt with in the
context of computing the Send MSS.

[email-masked] writes:

> If I understand correctly that RFC2851 says TCP should advertise MSS opt
> value of 1448 when MTU=1500 and TCPoptionLength=12, then I have some
> further questions about how to calculate Eff.snd.MSS, the number of data
> bytes to send in a segment along with the headers and options:

My take is that RFC 2851 should not be interpreted to say that the
advertised MSS should be 1448 above.  It should be 1460, and the Send
MSS calculation of RFC 1122 still applies.

> I hope I have misinterpreted RFC2581's intentions regarding MSS option
> value.

I believe Ed is misintepreting RFC 2581's intent.

Thomas

---

From: David Borman <[email-masked]>
Date: Fri, 4 Feb 2000 13:33:24 -0600 (CST)

Sigh, I *really* need to plow through and get the revision
to RFC 1323 done.  It has a section in Appendix A addressing
MSS, which I've attached.

			-David Borman, [email-masked]

   TCP Options and MSS
              
        There has been some confusion as to what value should be filled 
        in the TCP MSS option when using TCP options.  RFC-879
        [Postel83] stated:

             The MSS counts only data octets in the segment, it does not
             count the TCP header or the IP header.

        which is unclear about what to do about TCP options.  RFC-1122
        [Braden89] attempted to clarify this in section 4.2.2.6, but 
        there still seems to be confusion.
              
        So, the MSS value to be sent in an MSS option should be equal to
        the effective MTU minus the fixed IP and TCP headers.  Since
        both IP and TCP options are ignored when calculating the value
        for the MSS option, if there are any IP or TCP options to be
        sent in a packet, then the sender must decrease the size of the
        TCP data accordingly.  The reason for this can be seen in the
        following table:

                         +--------------------+--------------------+
                         | MSS is adjusted    | MSS isn't adjusted |
                         | to include options | to include options |
        +----------------+--------------------+--------------------+
        | Sender adjusts | Packets are too    | Packets are the    |
        | length for     | short              | correct length     |
        | options        |                    |                    |
        +----------------+--------------------+--------------------+
        | Sender doesn't | Packets are the    | Packets are too    |
        | adjust length  | correct length     | long.              |
        | for options    |                    |                    |
        +----------------+--------------------+--------------------+

        Since the goal is to not send IP datagrams that have to be
        fragmented, and packets sent with the constraints in the lower
        right of this grid will cause IP fragmentation, the only way to
        guarantee that this doesn't happen is for the data sender to
        decrease the TCP data length by the size of the IP and TCP
        options.  And since the sender will be adjusting the TCP data
        length when sending IP and TCP options, there is no need to
        include the IP and TCP option lengths in the MSS value.