1

MSS are calculated as MSS = MTU - IP header length - TCP header length.

One example is MSS=1500-20-20=1460 in Ethernet.

This calculation neglects the options in TCP and IP headers, which lead to variable header length.
To my understanding, when TCP assembles segments, it is aware of the options in TCP header and it can truncate the data to the "right" size to satisfy MSS as it considers IP header for 20 bytes.

However, TCP has no knowledge of IP options as it is on top of IP layer, then how can it assemble segments correctly?
For example, a TCP segment has 1460 bytes, and IP decides some options are needed, which makes its header longer than 20 bytes.

In such situation, does IP need to split the TCP segment to satisfy MTU (which seems to lower the efficiency of transmission as the second packet may have only few bytes in its payload)?

Are there any negotiation between TCP and IP in implementation to avoid such split in IP?

2

From RFC6691

When calculating the value to put in the TCP MSS option, the MTU
value SHOULD be decreased by only the size of the fixed IP and TCP
headers and SHOULD NOT be decreased to account for any possible IP or TCP options; conversely, the sender MUST reduce the TCP data length
to account for any IP or TCP options
that it is including in the
packets that it sends.

(emphasis mine)

So the problem is avoided.

Edit : as pointed out by hertitu the cited RFC is not an Internet Standards Track, so let's check RFC1122 which is an Internet Standard.

The maximum size of a segment that TCP really sends, the "effective send MSS," MUST be the smaller of the send MSS (which reflects the available reassembly buffer size at the remote host) and the largest size permitted by the IP layer:

           Eff.snd.MSS =

              min(SendMSS+20, MMS_S) - TCPhdrsize - IPoptionsize

where:

        *    SendMSS is the MSS value received from the remote host,
             or the default 536 if no MSS option is received.

        *    MMS_S is the maximum size for a transport-layer message
             that TCP may send.

        *    TCPhdrsize is the size of the TCP header; this is
             normally 20, but may be larger if TCP options are to be
             sent.

        *    IPoptionsize is the size of any IP options that TCP
             will pass to the IP layer with the current message.

As you can see the MSS must take into account both the IP option size and the TCP options.

Concerning :

However, TCP has no knowledge of IP options as it is on top of IP layer, then how can it assemble segments correctly?

TCP is responsible for passing the IP options requested by the application to the IP layer, so it can compute what will be the IP option size.

  • Note that (a) this RFC states This document is not an Internet Standards Track specification; it is published for informational purposes. so this is not necessarily what happens in practice, do you know if it is? And (b) it doesn't specify how the sender can calculate the data length, which still leaves the OP's last question open. – hertitu Oct 5 '16 at 11:29
  • @hertitu you're right, thanks for pointing this out. I have amended my answer. – JFL Oct 5 '16 at 12:48
  • It looks a little bit weird to me that TCP should know the format of IP options which come from the application, but it does solve the question I asked. Thank you JFL and hertitu. – fiedel Oct 7 '16 at 2:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.