Summary

  • A TCP MSS option in a SYN announces how much TCP data its sender is prepared to receive. The two directions can carry different limits; the handshake does not select one shared value.
  • The sender must still derive an effective send MSS from the remote receive bound and the IP layer's current transmission limit, then reduce data for the options actually present on each packet.
  • MSS is not Path MTU, receive window, application-message framing, or a promise that every later segment will carry the announced amount.

The number governed the other endpoint

RFC 793 defined Maximum Segment Size as TCP option Kind 2, Length 4. Its sixteen-bit value communicated the maximum receive segment size at the TCP sending the SYN-bearing segment. The option belonged at connection establishment, but that location did not make it a jointly chosen property.

A value of 1,460 in the client's SYN constrains data sent from server to client. A value of 1,200 in the server's SYN-ACK constrains client to server. Buffers, interfaces, address-family assumptions and local policy need not be symmetric. Both statements can be true at once.

RFC 879 made the language unusually direct in 1983. It called MSS an announcement, “often mistakenly called a negotiation,” and said it could be used independently in each direction. A negotiation would normally compare proposals and produce a shared result. MSS had no such selection step. Each receiver spoke only for the capacity it controlled.

That distinction matters after the packet leaves a standards diagram. A dashboard field named “negotiated MSS” loses both speaker and direction. An asymmetric but valid connection can look inconsistent, and a later operator can apply a limit to the wrong flow.

The arithmetic behind 536

The historical IPv4 baseline required hosts to receive and reassemble a 576-octet datagram. Subtract the fixed twenty-octet IPv4 header and fixed twenty-octet TCP header, and 536 octets remain for TCP data. RFC 879 clarified that MSS counts data octets, not the IP or TCP headers.

SYN and FIN each consume a position in TCP sequence space, but neither becomes an MSS data octet. Sequence-space occupation, payload length and full IP-datagram size are related ledgers, not synonyms.

RFC 1122 required TCP implementations to send and receive the MSS option. If no value arrived during setup, the sender had to assume 536. The current consolidated specification, RFC 9293, retains 536 for IPv4 and supplies 1,220 for IPv6: the 1,280 minimum minus a forty-octet IPv6 header and twenty-octet TCP header.

An absent option therefore does not grant permission to send any size. It activates a conservative default. The defaults are not measurements of a current route, product recommendations or predictions that later segments will be filled to that length. They bound action when a more specific receive statement is missing.

A receive ceiling was not a path certificate

RFC 1122 separated the SendMSS received from the peer from the effective send MSS. RFC 9293 preserves the distinction. The maximum TCP can really send must fit both the peer's receive/reassembly bound and the largest transmission size the IP layer permits, with current headers accounted for.

A receiver may be able to accept 9,000 octets while a tunnel in the path cannot carry the corresponding datagram. A wide path may carry 9,000 while the receiver has announced only 1,200. The first fact belongs to an endpoint. The second belongs to a path context. Neither actor can enlarge the other's authority.

This is the boundary with Path MTU Discovery. The existing PMTUD history follows router errors, path caches and delivery probes through which a sender revises its estimate of the narrowest path. Its ledger expressly excludes a TCP MSS tutorial. MSS supplies a different input to packetization: the remote endpoint's directional receive ceiling.

Actual segments can be smaller than every known ceiling. The application may have fewer bytes ready; receive or congestion windows may restrict flight; a retransmission may use a different boundary; TCP options may occupy space; scheduling may release a partial segment. A small observed payload alone does not prove MSS rewriting or path capacity.

A fixed announcement could not price every future header

IP and TCP headers can vary from packet to packet. That produced a durable accounting question: should an endpoint subtract space for every option that might later appear when it advertises MSS?

RFC 6691 assigned the work to the party holding the relevant knowledge. When calculating the value placed in the MSS option, subtract only the fixed IP and TCP headers from the effective MTU. Do not pre-subtract hypothetical variable options. When constructing an actual packet, the sender must shorten the TCP data by the IP and TCP options that are really present.

The receiver at SYN time cannot know which combinations its peer will use on every future packet. One fixed MSS cannot represent all variable combinations. The sender alone knows the header it is assembling now.

If the receiver reserves option space and the sender subtracts it again, segments become unnecessarily short. If neither accounts for actual options, the packet becomes too long and may fragment or be dropped. The durable rule is not a universal safety margin. It is one adjustment, by the actor that knows the packet.

RFC 6691 also corrected the premise of an old RFC 879 example that subtracted an IP Security option directly from the announced MSS. A verified erratum fixed the padding arithmetic inside that example, but the later specification showed that the subtraction itself belonged at packet construction rather than in the announcement. RFC 9293 now consolidates the fixed-header rule.

An erratum proposed for RFC 1122 claimed its effective-MSS formula double-subtracted IP options. Erratum 6381 was rejected. The verifier notes distinguish space reserved by IP from options TCP passes to IP. A research record must preserve the status of a proposed correction rather than treating every erratum submission as operative text.

Too small was also a policy choice

Conservative values have costs. RFC 6691 warns that setting MSS too low can prevent Path MTU Discovery from finding and using a larger path. The connection can remain reachable while producing more packets, more header work and a persistent loss of capacity that looks like an unavoidable network fact.

That does not justify advertising only the best case on an interface with a variable effective MTU. Header compression may occasionally need to send a full header to resynchronize state, and retransmission may occur in that larger form. RFC 6691 recommends using the smallest effective MTU so the advertised receive statement remains repeatable.

IPv6 jumbograms expose the expressive limit of the sixteen-bit field. A value of 65,535 is treated as infinity and Path MTU Discovery determines the actual usable MSS. “Infinity” delegates the final decision to another mechanism; it does not certify an infinite path.

A registry preserved grammar, not a live connection

The IANA TCP Parameters registry still lists Kind 2, Length 4 as Maximum Segment Size and points to RFC 9293. That establishes continuity of the shared syntax. It does not prove what an operating system advertised, whether a middlebox rewrote it, or what size crossed a path.

RFC 9293 obsoleted RFC 793, RFC 879 and RFC 6691 and replaced the TCP portions of RFC 1122. Consolidation preserved the important division of labor. The receiver announces what it knows about itself. The sender joins that ceiling to what IP permits. Variable overhead remains with the actor constructing the current packet.

MSS is therefore a ceiling with a speaker and a direction. A defensible connection record retains both announcements, the default if either was absent, each sender's effective calculation and the packets actually observed. One field called “negotiated MSS” grants a convenient number authority it never had.

Sources and evidence limits

These sources establish specifications, revision status and registry continuity. They do not measure present deployment, operating-system defaults, middlebox rewriting, live path MTU, performance, or the cause of a specific incident.