Advertise receive space, not packet size

The endpoint advertising MSS is the receiver of the data it limits.

• RFC 6691 is an Informational clarification, obsoleted by the current TCP specification RFC 9293. Its distinction between advertising MSS and sizing individual packets is retained in RFC 9293 section 3.7.1.
• RFC 6691 section 2 says the advertised MSS SHOULD subtract only fixed IP and TCP headers from the chosen effective MTU, and SHOULD NOT subtract possible options. A Maximum Transmission Unit (MTU) is a byte budget for a complete IP packet, including its headers.
• The fixed TCP header is 20 bytes. The fixed IPv4 header is 20; the fixed IPv6 header is 40. With a chosen 1500-byte effective MTU, the ordinary examples advertise 1460 for IPv4 or 1440 for IPv6. These are worked values, not universal defaults.
• The MSS option has Kind 2, Length 4 and a 16-bit value. It MUST NOT be sent in segments without SYN, TCP’s connection-start flag (RFC 9293 section 3.2). A SYN-ACK can advertise the other endpoint’s independent receive limit.
• The example’s right endpoint advertises 1460 to the left sender. After connection establishment, left-to-right data uses that receive bound. MSS is neither a receive-window advertisement nor a promise that the whole network path can carry that packet.

Only ordinary, non-jumbogram TCP is illustrated. The chosen MTU and receive capability are assumed suitable; RFC 6691 does not select an MTU for a multi-homed host. Header drawings are schematic, not to byte scale. Modern absence-of-option defaults are 536 for IPv4 and 1220 for IPv6 (RFC 9293 section 3.7.1).