RFC 6691 / START HERE
TCP MSS sizing, before the details
TCP Options and Maximum Segment Size (MSS). TCP is the Transmission Control Protocol, which carries an ordered byte stream; MSS describes a receive limit for its data.
This Informational publication explains two different calculations: advertise how much data an endpoint can receive, then make each outgoing packet fit its actual headers and network size budget. It is a historical clarification obsoleted by RFC 9293, the current TCP specification.
Why it exists
Earlier advice confused where optional headers should be counted. Subtracting them twice wastes space; failing to account for them can make a packet too large. The guide separates a receiver’s advertisement from the sender’s per-packet responsibility.
A familiar example
For a chosen 1500-byte IPv4 budget, subtract the 20-byte IP and 20-byte TCP base headers to advertise MSS 1460. A packet with 12 extra-header bytes then carries at most 1448 data bytes. A smaller path limit can reduce that further: MSS is not proof of end-to-end delivery.
Helpful background
You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.
What you’ll learn next
Begin with chapter one, or choose a topic.
- Advertise receive space, not packet sizeTCP carries an ordered stream of bytes between two endpoints. Maximum Segment Size (MSS) is an option one endpoint sends to describe how much TCP data it can receive in an ordinary segment.→
- Give options room in each packetOptional header fields take bytes inside a packet. They do not create extra space just because the MSS advertisement was calculated without them.→
- Avoid subtracting the same options twiceThere are two different decisions: what receive limit to advertise, and how much data to put in this packet. Confusing them can make packets too short or too long.→
- Respect the path as well as the peerThe peer’s receive MSS describes an endpoint limit. A smaller link on the route can impose a tighter packet budget.→
- Choose conservatively when interface budgets varySome interfaces have a changing effective MTU, for example when header compression occasionally needs full headers to resynchronize. A fixed receive advertisement must account for that risk.→
This introduction explains RFC 6691 (2012). This publication has a successor; see the related guides and the RFC status. Read the original RFC ↗