Contents

Maximum Segment SizeEdit

Maximum Segment Size

Maximum Segment Size (MSS) is a fundamental parameter of the Transmission Control Protocol (Transmission Control Protocol) that specifies the maximum amount of application data that can be carried in a single TCP segment. The value is negotiated during the initial handshake between two endpoints, using the MSS option carried in the TCP options field of the SYN packets. In practice, MSS serves as a guardrail to ensure that each data segment can traverse the entire network path without requiring the routers to perform fragmentation.

The MSS is closely tied to the path’s Maximum Transmission Unit—the largest packet size that can be transmitted without fragmentation on a given link. Since a TCP segment includes both payload and headers, the MSS is typically computed as the MTU minus the size of the IP header and the TCP header. This relationship means that the same MSS must fit through all links along the route, which is why the path MTU discovery process exists to determine the smallest MTU on the path and adjust expectations accordingly. See Path MTU Discovery for more on how networks determine the usable path size.

Definition and purpose

  • What MSS governs: the amount of payload data a single TCP segment can carry, excluding the IP and TCP headers.
  • Where MSS is advertised: during the TCP three-way handshake, via the MSS option in the SYN segment; each endpoint advertises the maximum it is willing to receive, and the effective MSS is the smaller of the two advertisements.
  • Why MSS matters: a properly chosen MSS minimizes fragmentation risk, reduces processing overhead from smaller-than-necessary segments, and influences throughput and latency characteristics.

In most common networks, MSS values fall in a narrow band that reflects typical MTU values. For a standard Ethernet network using IPv4 with an MTU of 1500 bytes, the usual MSS is around 1460 bytes (1500 minus the 20-byte IP header and the 20-byte TCP header). In IPv6 environments, where the header is larger, MSS tends to be around 1440 bytes on similarly sized links. Networks that use tunneling or encapsulation (for example, VPNs or virtual LANs) can see smaller effective MSS values due to the additional header overhead introduced by the tunnel. See Ethernet and IPv4 / IPv6 for more on header sizes, and Tunneling or VPN for how encapsulation affects MSS.

Negotiation and operation

  • During the handshake, each end advertises an MSS value. The host on the sending side will typically use the smaller of the two advertised MSS values as the maximum segment size for data sent in either direction.
  • The practical effect is that TCP segments that carry user data will not exceed the negotiated MSS, ensuring that their total size (payload plus headers) fits within the smallest MTU encountered along the route.
  • If path MTU discovery detects a smaller MTU downstream (for example, due to a foe of fragmentation or a misconfigured link), subsequent TCP connections may negotiate a smaller MSS to avoid fragmentation.

For a clearer picture of how MSS interacts with other TCP concepts, see Three-way handshake and TCP header and TCP options.

Relationship to MTU, PMTUD, and fragmentation

  • MTU: MSS is derived from MTU by subtracting the IP and TCP header sizes. Different link technologies have different MTUs, so MSS values vary by path.
  • PMTUD (Path MTU Discovery): PMTUD helps identify the smallest MTU along a path, allowing endpoints to select compatible MSS values. When PMTUD works reliably, it minimizes fragmentation risk and improves performance.
  • Fragmentation: If a packet larger than the MTU traverses a link without support for fragmentation, it must be fragmented somewhere along the path. Fragmentation can degrade performance and complicate handling of certain security and filtering devices. An appropriately sized MSS reduces the likelihood of fragmentation.

See also MTU and Path MTU Discovery for more background on how these pieces fit together.

Typical values and network effects

  • Standard Ethernet with IPv4 and MTU 1500: MSS ≈ 1460 bytes.
  • IPv6 on the same MTU: MSS often ≈ 1440 bytes because the IPv6 header is larger.
  • VPNs and tunneling: Encapsulation adds header bytes, typically reducing the MSS. For example, VPN tunnels that add several extra headers can shrink MSS by a few dozen to a few hundred bytes, depending on the tunnel type and configuration. In some cases, operators implement MSS clamping on VPN devices to ensure tunnels don’t induce fragmentation inside the tunnel. See MSS clamping for more on this practice.
  • Data-center networks with jumbo frames (MTU often 9000): MSS can be much larger (up to about 8960 bytes on IPv4, subject to the actual headers involved), which can improve throughput for bulk transfers, though end-to-end paths must support the larger MTU.

The choice of MSS involves a trade-off between throughput and robustness. Larger MSS reduces header overhead and increases potential throughput, but it raises the risk of fragmentation or dropped connections if any hop along the path cannot handle the size. Smaller MSS can be more robust in complex networks with diverse equipment—especially where VPNs, NATs, or tunneling devices sit in the path—but it adds header overhead and can lower raw throughput.

Tunneling, VPNs, and MSS clamping

When traffic is encapsulated for tunneling or traverses devices that apply additional headers, the effective MTU of the path can shrink. To avoid hard failures or inefficient fragmentation, network operators sometimes apply MSS clamping on certain devices. MSS clamping fixes the MSS to a value that fits through the tunnel reliably, even when the tunnel adds headers that would otherwise push segments over the path MTU. See MSS clamping for a discussion of this practice and its implications for interoperability and performance. See also VPN and Tunneling for how encapsulation changes the header overhead that TCP segments must tolerate.

See also