TCP Options | Teleinf Edu

Introduction: Extending the TCP Header

The standard TCP header is 20 bytes long and contains the fields needed for basic connection handling. Modern fiber, satellite, and mobile networks can offer high bandwidth, while some also have substantial delay. The basic fields can then be insufficient for using available capacity efficiently when the bandwidth-delay product is large.

TCP designers provided an extensibility mechanism: the TCP Options field. This variable-length space appears at the end of the base header. It allows features to be added without changing the mandatory fields.

TCP Options are additional pieces of information that can be included in a TCP segment to enable features that are not part of the original specification. These options are negotiated between the sender and receiver, typically during the initial . An option can be used after negotiation when its specification permits it. A TCP implementation ignores an unsupported option that has a length field. TCP options occupy at most 40 bytes because the base header cannot exceed 60 bytes. Some options are negotiated in SYN packets, while others can appear in later segments. This preserves interoperability across implementations and extends TCP with features used by high-throughput connections.

How TCP Options are Formatted

The Options field can contain multiple options, one after another. Each option follows a Type-Length-Value (TLV) format, except for the defined one-byte options.

Kind (1 byte): A number that identifies the type of option. For example, Kind=2 signifies the Maximum Segment Size option.
Length (1 byte): The total length of the option in bytes, including the Kind and Length fields themselves. For example, the MSS option has a length of 4 bytes.
Value (Variable length):The actual data associated with the option. The length of this field is 'Length - 2' bytes.

Two special single-byte options, End of Option List (Kind=0) and No-Operation (Kind=1), are exceptions to the TLV structure. End of Option List marks the end of the list, while No-Operation can align subsequent fields. Alignment to a 4-byte boundary can simplify processing, but every option does not have to start on such a boundary. The receiver reads each option's length, stops at End of Option List, and treats remaining space as header padding.

Common TCP Options in Detail

Common TCP options specify the maximum segment size, scale the receive window, report selectively acknowledged data, and carry timestamps.

1. Maximum Segment Size (MSS) - Limiting Fragmentation

The Maximum Segment Size (MSS) option (Kind=2, Length=4) is sent in SYN segments. Each side uses it to declare the largest amount of TCP data it is willing to receive in a single segment.

Purpose: Its main goal is to avoid . The physical networks that make up the internet (including Ethernet) have a limit on the largest frame they can carry, known as the Maximum Transmission Unit (MTU). On an IPv4 Ethernet path with an MTU of 1500 bytes, if TCP sends a segment that, after adding the IP header, is larger than the path MTU, a router may have to fragment the packet into smaller pieces. IPv6 routers do not fragment transit packets, so path MTU constraints still matter. Fragmentation is inefficient and should be avoided.

Negotiation: The MSS option is sent in a SYN packet. Each side advertises the largest data segment it is willing to receive. For IPv4 without additional options, an MTU of 1500 bytes gives $1500 - 20 - 20 = 1460$ bytes. A transmitted segment must satisfy the peer's MSS and the constraints imposed by the local MTU and path. TCP options increase header size, leaving less space for payload in a packet. This does not imply a universal rule that every direction uses the smaller of the two advertised MSS values.

MSS counts TCP payload bytes, not the complete IP packet. The sender also accounts for the local and path MTU and for the space occupied by TCP and IP headers, including options.

2. Window Scale - Supporting a Large BDP

The Window Scale option (Kind=3, Length=3) overcomes the 16-bit Window Size field limitation in the TCP header. Without scaling, that field advertises at most 65,535 bytes (about 64 KiB), which can be insufficient on high-speed networks with substantial delay.

Purpose: The option supports high throughput on connections with a large Bandwidth-Delay Product (BDP). BDP indicates how much data can be in transit on a path. If the advertised receive window is smaller than the BDP, the sender must wait for acknowledgments and cannot use all available bandwidth. Window scaling permits a larger advertised value.

Negotiation: The option must be sent in an initial SYN packet. It contains a one-byte factor from 0 to 14 that specifies a left shift of the 16-bit Window Size field. A factor of 7 multiplies the field value by $2^7$ , or 128. Each side negotiates its own factor for data flowing from the other side. Later advertisements use the scale negotiated in the SYN exchange. This allows a receive window of about 1 GiB.

The window field in a SYN is not scaled. A Window Scale option in a segment without SYN is ignored, so later advertisements use a scale only after it has been negotiated during connection setup.

3. Timestamps - Measuring Time and Protecting Data

The Timestamps option (Kind=8, Length=10) adds two 32-bit timestamp fields to the TCP header. It supports two main functions.

When negotiated, the option is sent on data and acknowledgment segments. TSval carries the sender's timestamp, while TSecr echoes the peer's value when the ACK flag is set.

Accurate RTT Measurement (RTTM): The sender places its current timestamp in the first field (TSval). The receiver, upon getting the segment, echoes this exact timestamp back in the second field (TSecr) of its acknowledgment segment. When the sender receives the echoed value, it can subtract it from its current clock to get a very precise and unambiguous measurement. The timestamps associate an RTT sample with a particular segment and reduce ambiguity in measurements involving a segment and its ACK. RTO measurement rules and timestamp-clock behavior still apply.
Protection Against Wrapped Sequence Numbers (PAWS): On very high-speed networks, 32-bit sequence numbers can wrap around (go from $2^{32}-1$ back to 0) before a delayed segment from a previous cycle arrives. PAWS compares timestamps and can discard a segment whose timestamp is older than the last accepted one, according to the rules in RFC 7323. This protects against some old duplicates.

4. SACK (Selective Acknowledgment) - Recovering from Multiple Losses

Standard TCP uses cumulative acknowledgments, which can be inefficient when multiple segments are lost from one data window. Selective Acknowledgment (SACK) describes received ranges more precisely and assists recovery in this situation.

Negotiation: To enable this feature, both the client and server must include the SACK-Permitted option (Kind=4, Length=2) in their initial SYN packets during the three-way handshake. This confirms that both parties understand and are willing to use SACK.

Operation: Once enabled, if the receiver gets a segment that is out of order, it sends back a duplicate ACK as usual. However, in the Options field of this duplicate ACK, it now includes a SACK option (Kind=5, Variable Length). This option contains one or more blocks, each specifying the start and end sequence numbers of a contiguous block of data that has been successfully received. SACK-Permitted authorizes SACK, while a SACK option carries the actual ranges.

For example, if the receiver has received segments 1-2 and 4-5 but is missing segment 3, it sends duplicate ACKs for segment 3 with a SACK option reporting the received range 4-5. The sender learns which range is missing and can retransmit segment 3 without resending data already received. The result depends on SACK support at both endpoints and on the retransmission algorithm.

A SACK option with $n$ blocks uses $8n+2$ bytes. The 40-byte options area can therefore carry at most four blocks, and fewer when timestamps also occupy option space.

5. TCP Fast Open (TFO) - Shortening Connection Setup

In short-lived connections, application data normally waits for the three-way handshake, adding at least one RTT. The TCP Fast Open (TFO) option (Kind=34) allows data to be sent in the SYN packet on repeat connections.

Operation:

On the first connection to a server, the process is normal. However, the server generates a special cryptographic "cookie" and sends it to the client. The client caches this cookie.
On subsequent connections to the same server, the client includes this cookie in its initial SYN packet. Along with the SYN packet, the client can immediately send some application data (e.g., an HTTP GET request).
The server validates the cookie. If it is valid, the server accepts the data that arrived with the SYN packet and passes it to the application immediately, even before the third part of the handshake (the final ACK) has arrived.

TFO can remove one RTT of waiting for application data on a repeat connection, but it does not make the entire TCP setup take zero RTT. Data in a SYN can be replayed, so it should be limited to operations safe under repetition. If the cookie is invalid, the server falls back to the normal handshake without accepting SYN data. A server can also decline TFO for policy or resource reasons. RFC 7413 describes TFO as experimental.