1. Maximum Segment Size (MSS) - Avoiding Fragmentation

The Maximum Segment Size (MSS) option (Kind=2, Length=4) is the most common TCP option. It is used during the three-way handshake for each side to declare the largest amount of data it is willing to receive in a single TCP segment.

Purpose: Its primary goal is to avoid IP fragmentation. The physical networks that make up the internet (like Ethernet) have a limit on the largest frame they can carry, known as the Maximum Transmission Unit (MTU). For Ethernet, the standard MTU is 1500 bytes. If TCP tries to send a segment that, once wrapped in an IP header, is larger than the MTU of a link, a router on the path will have to fragment the packet into smaller pieces. Fragmentation is inefficient and should be avoided.

Negotiation: In its initial SYN packet, a client typically calculates its MSS by taking the MTU of its outgoing interface (e.g., 1500 bytes for Ethernet) and subtracting the size of the IP and TCP headers (typically 20 bytes each). Thus, $1500 - 20 - 20 = 1460$ bytes. The server does the same. Both sides will then use the smaller of the two advertised MSS values for the duration of the connection. By agreeing on a segment size that fits neatly within the network-s MTU, TCP ensures its segments can travel end-to-end without being broken apart by routers.

2. Window Scale - Expanding the Highway

The Window Scale option (Kind=3, Length=3) was created to overcome the limitations of the original 16-bit Window Size field in the TCP header, which capped the receive window at 65,535 bytes (64 KB). This is insufficient for modern high-speed, long-latency networks (often called "long fat networks").

Purpose: It allows TCP to achieve high throughput on connections with a large Bandwidth-Delay Product (BDP). The BDP tells you how much data can be "in flight" on a network path at any given time. If the advertised receive window is smaller than the BDP, the sender will be forced to stop and wait for ACKs, unable to fully utilize the available bandwidth. The Window Scale option allows the receive window to be much larger, effectively "widening the pipe" to match the BDP.

Negotiation: This option must be sent in the initial SYN packet by the side that wishes to use it. The option contains a one-byte scale factor, which is a number from 0 to 14. This factor represents a left-bit-shift count. The true receive window size is then calculated by taking the 16-bit value from the header's Window Size field and shifting it left by the agreed-upon scale factor. For example, a scale factor of 7 means multiplying the window value by $2^7$, or 128. This allows for receive windows up to approximately 1 Gigabyte. If only one side sends the option, scaling is only enabled for the data flowing towards that side.

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 serves two crucial purposes.

• 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 Round-Trip Time (RTT) measurement. This is more reliable than the original method of timing a segment and its ACK, as it is not affected by delayed ACKs or retransmissions.
• Protection Against Wrapped Sequence Numbers (PAWS): On very high-speed networks, it is possible for the 32-bit sequence numbers to "wrap around" (go from $2^{32}-1$ back to 0) so quickly that a delayed packet from a previous cycle could arrive and be mistakenly accepted by a current connection. The PAWS algorithm uses the ever-increasing timestamps to reject such old duplicate packets. If a segment arrives with a timestamp that is older than the last one received for that connection, it is discarded, providing robust protection against this rare but potentially damaging scenario.

4. SACK (Selective Acknowledgment) - Precision Error Recovery

Standard TCP uses a cumulative acknowledgment system, which can be inefficient when multiple segments are lost from a single window of data. The Selective Acknowledgment (SACK) mechanism dramatically improves recovery performance in such scenarios.

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.

For example, if the receiver has received segments 1-2 and 4-5 but is missing segment 3, it will send duplicate ACKs for segment 3, but with a SACK option that says "I have received the data from 4-5". This gives the sender a precise map of the "holes" in the receiver-s buffer, allowing it to retransmit only the specific missing segments instead of relying on slow timeouts or retransmitting segments that have already been received.

5. TCP Fast Open (TFO) - Speeding Up Connections

One of the primary sources of latency in short-lived web connections is the three-way handshake, which requires a full round-trip before any data can be sent. The TCP Fast Open (TFO) option (Kind=34) is a relatively new extension designed to eliminate this RTT penalty for repeat connections.

Operation:

1. 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.
2. 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).
3. 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.

By allowing data to be sent in the very first packet, TFO effectively reduces the connection setup time to zero RTTs for repeat visitors, which can significantly improve web page load times.