MSS from MTU: TCP Maximum Segment Size

MSS from MTU: the largest TCP segment that fits

The MSS (Maximum Segment Size) is the biggest chunk of TCP payload you can fit in one IP packet without it fragmenting: MSS = MTU − IP header − TCP header. With plain IPv4 + TCP that works out to MTU − 40, which is why a 1500 B Ethernet MTU lands on the familiar MSS = 1460. Over IPv6 you subtract 60 instead (the 40 B IPv6 header plus 20 B of TCP), so the same link gives you 1440. Each end advertises its MSS during the SYN handshake using the MSS option, and the connection settles on whichever value is smaller. When the path is asymmetric, you'll see MSS Clamping set up on routers (mss-clamp-to-pmtu in Linux/iptables). PPPoE and VPN gateways lean on it a lot, forcing a smaller MSS so PMTUD doesn't get black-holed.

Applications: PMTUD, VPN tunnels and troubleshooting

It comes up when you set MSS clamping on PPPoE (usually 1452) or on IPSec/WireGuard tunnels (usually 1360–1400). It's also how you track down that "page loads halfway then hangs" symptom, which is almost always a PMTU black hole, and it feeds the maximum throughput per RTT in TCP performance modelling.

FAQ

What is the default MSS on Ethernet? 1460 bytes for IPv4 and 1440 for IPv6, assuming a 1500 B MTU with no extra options in play.

Difference between MTU and MSS? MTU lives at L2/L3 and covers the whole packet. MSS is an L4 thing: just the TCP payload, with the IP and TCP headers left out.

Why clamp MSS at all? If something along the path filters the ICMP "Fragmentation Needed" message, PMTUD quietly breaks. Clamping at the source sidesteps that by keeping segments small enough to get through the tunnel in the first place.