From dab Thu Jan 7 14:12:10 1993
To: tcplw at cray.com
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, dab at cray.com
