Now that you know the rationale behind IP MTU and TCP MSS existence, let’s get into understanding what these two do and how they relate to each other.
In order to understand IP MTU and TCP MSS we need to work backwards.
Let’s assume an Ethernet frame … It all starts with Layer2’s maximum payload size – this is dictated by different media/encapsulation – for an Ethernet frame, this is 1500 bytes, the minimum being 46 bytes (see RFC 894). This limit is hardware dependent.
So the Ethernet payload can be maximum 1500 bytes (excluding the Ethernet header) – a.k.a. IP MTU (Maximum Transmission Size). But we also have the IP and TCP headers (2 x 20 bytes) to consider. This leaves us with 1500 – 40 = 1460 bytes maximum of application data. Since the application is packaged within TCP segments, we call this maximum as TCP MSS (Maximum Segment Size).
Lastly, keep in mind there are cases when a Layer2 protocol encapsulates another Layer2 protocol – for example: PPPoE, MPLS (encapsulated in Ethernet) and others. In such cases, we need to consider that the amount of Layer2 information increases. This implies a smaller IP MTU and consequently, a smaller TCP MSS.
More on TCP MSS …
There are two different contexts in which TCP MSS is relevant.
- TCP MSS on terminating traffic
- TCP MSS on transient traffic
In the first case, the TCP-MSS is transmitted (not negotiated!) between two end-points, in the SYN packet, during the 3-Way TCP handshake. These values don’t have to match and in most cases, they don’t.
However, it is also possible to configure a transient device (such as a router) to inspect the packets and to alter the TCP-MSS value. This will force the end-points to communicate using a matching MSS value. It does however add overhead to the router since the router has to inspect all SYN packets.
Next, I will show you few examples on IP MTU and TCP MSS.