[tcpm] TCP MSS option - FYI original discussion

[David Borman <[e-mail]>]

In today's TCPM session, Matt Mathis asked when the TCP MSS option  
discussion first happened.  I looked it up, and I originally posted  
the discussion to the [e-mail] mailing list in 1993.  Here's the  
text of that original message, taken from my mail archives.

			-David Borman

> From dab Thu Jan  7 14:12:10 1993
> To: [e-mail]
> Subject: TCP MSS & Timestamps
>
>
> In recent private mail conversation, it has come to my
> attention that we probably don't all have a common view on
> what to do with the TCP MSS value in the presence of TCP
> options, since the TCP MSS value only refers to the TCP
> data part of the packet, and the presence of TCP options
> will affect that value.
>
> Since 1323 is eligible for elevation to Draft status, this
> is a good time to revise the document to clarify this issue.
>
> First, there is a maximum packet size.  When you insert options,
> the amount of space available for TCP data within a non-fragmented
> IP packet goes down by the length of the options.  So, the option
> length needs to be accounted for.
>
> The "be conservative in what you send" rule can be applied
> in two ways.  The first is in the generation of the MSS
> value, you can say "well, I'll assume that the other side
> won't adjust for the length of the options, so I'll adjust
> for the option length when sending the MSS".  Meanwhile,
> on the other side, when sending a packet, you can say "well,
> I'll assume that the other side did not adjust for the options
> length when it sent the MSS, and so I'll decrease the data
> size by the option length".  You can do both, but then the
> packets will usually be short.  So, you should pick one or the
> other, but not both.
>
> With two places to do the accounting for the options vs.
> the MSS value, you get a grid like:
>
>                 | MSS is adjusted       | MSS is not adjusted
>                 | for options           | for 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     |                       |
>
> The bottom right-hand corner is what we want to avoid, since that
> is the case when IP will have to fragment the packet.  The only
> way that the side that is sending the datagrams can guarantee that
> it doesn't send IP packets that are too long is to always adjust
> the data length by the length of the options.  It would be better
> to send a packet that is a few bytes too short rather than one
> that is a few bytes too long.
>
> So, the bottom line is that I'd like to see a paragraph added
> to 1323 stating that the generated MSS value only takes into
> account the fixed IP and TCP header lengths, and that the side
> that is generating the datagrams needs to adjust the length of
> the TCP data to account for any IP or TCP options that it inserts
> into the datagram.
>
> Anyone disagree?
>
>                         -David Borman, [e-mail]
>