7

I understand the MSS is the Maximum Segment Size, which is the size of the Payload TCP will send. I also understand that a "receiving" MSS value is suggested by both parties in a TCP conversation during the 3-way handshake, and both parties will adhere to the other's proposed MSS when sending data.

My question is, what goes into setting the MSS? What factors does a Client or Server use when they state "I want you to send me TCP segments in maximum chunks of X" bytes. Is it solely based on the MTU? Do other factors go into the calculation of one side's MSS?

(while somewhat unrelated to my question, this Q&A did provide some useful background information)

Improve this question

1 Answer 1

Reset to default
11

1. What goes into setting the MSS?

In the question you referenced it stated this, the MSS is derived directly from MTU. A typical Ethernet MTU will 1500, but IP and TCP headers must also be taken into account - each of them are 20 bytes.

Note: Just an FYI, MTU can be different sizes - see Jumbo Frames for an example.

We end up with:

MSS = 1500 - 20 - 20
MSS = 1460 bytes of TCP data

I'd like to emphasize something you mentioned, you are 100% correct in stating that the MSS for the TCP connection is established during the 3 way handshake. Should either side of the connection want to adjust its MSS, the TCP connection would have to be torn down and re-established. Before going any further, we need to clarify that a "receive MSS", what you're thinking of is the TCP receive window. This is not the same as the MSS.

2. Do other factors go into the calculation of one side's MSS?

So remember, the TCP MSS is established during the TCP handshake along with all of the other session options. The vast majority of the time the agreed upon MSS will be the largest possible payload that can be sent in a TCP segment without fragmentation. The last part is key, this means if a client and server are trying to establish a TCP connection, and the client has a smaller MSS size set, the connection will choose the smaller of the two values to avoid said fragmentation.

As it should be noted, it is possible to manually set MSS if whoever is running the application/service doesn't care about fragmentation.

3. What factors does a Client or Server use when they state "I want you to send me TCP segments in maximum chunks of X bytes?" Is it solely based upon the MTU?

The bottom line is that TCP will try to squeeze as much data into each message as it can to maximize network efficiency. To be clear, a single un-fragmented TCP segment's payload (headers, data, options, etc.) CANNOT exceed than that of the MSS, if that single TCP segment is one message, or a piece of a fragmented one is irrelevant to TCP - that's what it's designed to handle.

It's not solely based on MTU of the end hosts, but as previously mentioned it is derived from it. Things like a lower "Path MTU" (see Path MTU Discovery (PMTUD)), can affect network performance.

Other factors can affect network performance as well, but not necessarily only MSS. You can check out things like TCP Tuning, if you'd like an idea of what else you might think about when designing an application or service around TCP.

Improve this answer
6
  • Thanks for the response, however this doesn't quite fully answer my questions. You mention PMTUD -- I understand how it works, but when is it actually run? I just captured random browsing sessions from my PC and the only TCP packets with DF on were ACKs and SYNs, so as far as I can tell, my Client never ran PMTUD (None of the SYN packets were >100 bytes). As such, did it simply calculate an MSS based solely on MTU-20-20? Did anything else go into factoring the MSS? How did my client know that there wasn't a smaller MTU link in transit? Or did my client even care?
    – Eddie
    Dec 3, 2014 at 16:34
  • @Eddie Whether PMTUD happens, typically depends on if the destination is local or on a remote network. The RFC does a better job at explaining it than I will, take a look at sections 2, and 3 (it's not long). tools.ietf.org/html/rfc1191.
    – Jordan Head
    Dec 3, 2014 at 17:53
  • @Eddie Oh, and as for the mention of the MTU of 576 bytes, that is the smallest MTU possible. All devices must be able to handle an MTU of 576, never smaller.
    – Jordan Head
    Dec 3, 2014 at 17:54
  • Reading the RFC, it seems the MSS Proposed in each SYN is indeed exactly a factor of MTU-20-20 (RFC879 Section 7). It also appears that you are right when you say both parties agree to use the lowest MSS from each other's SYNs as the MSS for the conversation (RFC879 Section 7). I head read conflicting answers about this (whether they agreed to use the lowest, or respected each other's differing MSS values). However, according to the RFC, it doesn't seem like any other factors go into determining MSS, but you mentioned there were... can you elaborate?
    – Eddie
    Dec 3, 2014 at 22:43
  • In terms of MSS as a standalone concept, there aren't any other factors, apologies for the unclear language. I was trying to point out that if traffic does not need to be fragmented, it's rather inefficient in terms of protocol overhead, however if your application requires all data to be delivered in a single message, you're going to be fine with that additional overhead. But by "other factors" I meant the things you should be aware of in terms of TCP options, should you be okay with data being fragmented. It's just a related conept to keep in mind when thinking about any of this.
    – Jordan Head
    Dec 3, 2014 at 23:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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