TCP Selective Acknowledgment Options
obsoletes
- rfc-1072 — TCP extensions for long-delay paths
Extracted elements (28)
Including multiple SACK blocks per option packet compensates for lossy ACK return paths. With the timestamp option present, three SACK blocks fit; each block is thus normally reported in at least three successive ACKs, limiting unnecessary retransmissions due to lost ACKs.
RFC 2018 modifies RFC 1072's SACK proposal in exactly two ways: (1) the first SACK block always reports the most recently received data, reducing the need for long SACK options; and (2) full 32-bit sequence numbers are carried instead of offsets, simplifying implementation and improving robustness.
SACK is not specified to trigger new congestion control behavior; existing Reno-style fast recovery and slow-start algorithms are preserved unchanged. Future research may leverage SACK's additional information, e.g., for wireless environments where loss is not a congestion signal.
The first SACK block always reports the most recently received segment so the sender has the most up-to-date view of the receiver's queue state. Subsequent blocks repeat recently reported blocks for redundancy against ACK loss, ensuring each block appears in at least three successive ACKs.
Older TCP implementations without SACK support will not be unfairly disadvantaged when competing against SACK-capable TCPs. SACK's worst-case unnecessary retransmission exposure is strictly less than that of current non-SACK TCP.
When TCP SACK is used together with the Timestamp option (RFC 1323), the timestamp option consumes 10 bytes (plus 2 bytes padding), leaving room for at most 3 SACK blocks rather than 4.
After a retransmit timeout, the data sender MUST retransmit the segment at the left edge of the window, regardless of whether the SACKed bit is set for that segment.
After a retransmit timeout, the data sender SHOULD turn off all SACKed bits, since the timeout may indicate the receiver has reneged on previously SACKed data.
If the data receiver generates SACK options under any circumstance, it SHOULD generate them under all permitted circumstances, ensuring consistent behavior.
If the data receiver has not received a SACK-Permitted option for a given connection, it MUST NOT send SACK options on that connection.
SACK options SHOULD be included in all ACKs which do not ACK the highest sequence number in the data receiver's queue. The receiver SHOULD send an ACK for every valid segment containing new data, and each such ACK SHOULD bear a SACK option.
The congestion control algorithms present in de facto standard TCP implementations MUST be preserved. In particular, recovery is not triggered by a single ACK reporting out-of-order packets, and the sender limits segments sent per ACK during recovery.
The data receiver SHOULD include as many distinct SACK blocks as possible in the SACK option, and SHOULD fill remaining space by repeating the most recently reported SACK blocks not already subsumed by an included block.
The data sender MUST NOT discard unacknowledged data before it is acknowledged by the Acknowledgment Number field in the TCP header, since the receiver may later renege on SACKed data.
The first SACK block MUST specify the contiguous block of data containing the segment which triggered the ACK, unless that segment advanced the Acknowledgment Number field. This ensures the SACK option reflects the most recent change to the receiver's buffer queue.
The SACK-Permitted option MUST NOT be sent on non-SYN segments.
When a retransmit timeout occurs, the data sender MUST ignore prior SACK information in determining which data to retransmit, because the data receiver is allowed to discard SACKed data.
When receiving an ACK containing a SACK option, the data sender SHOULD record the selective acknowledgment for future reference and skip SACKed segments during later retransmission.
When reneging, except for the newest segment, all SACK blocks MUST NOT report any old data which is no longer actually held by the receiver.
When reneging, the first SACK block MUST reflect the newest segment received, reporting at minimum the left and right edges of the newest segment, even if adjacent data has been discarded.
The SACK option is advisory: the data receiver is permitted to later discard data already reported in a SACK option (reneging), for example when buffer space runs low. Discarding SACKed data is discouraged but explicitly allowed.
The SACK option (Kind=5, variable length) is sent by the data receiver to convey non-contiguous blocks of received data. Each block is defined by a Left Edge and Right Edge, both 32-bit unsigned integers in network byte order. A SACK option with n blocks has length 8*n+2 bytes.
The SACK-Permitted option (Kind=4, Length=2) is a two-byte TCP option sent only in a SYN segment to indicate that the sender supports and will process the SACK option once the connection is established.
This document allocates two TCP option kind values: Kind=4 for SACK-Permitted (Length=2, SYN-only) and Kind=5 for SACK (variable length). These extend the TCP options space defined in RFC 793.
The SACK option neither strengthens nor weakens TCP's existing security properties. No new security considerations are introduced beyond those already present in TCP.
The data sender maintains a SACKed bit per segment in the retransmission queue. On receipt of a SACK option, SACKed bits are set for segments wholly within a SACK block; SACKed segments are skipped during retransmission. On retransmit timeout, all SACKed bits are cleared.
Each SACK block consists of two 32-bit unsigned integers in network byte order: Left Edge (first sequence number of the block) and Right Edge (sequence number immediately following the last byte of the block). Up to 4 blocks fit in the 40 bytes of TCP option space; only 3 blocks fit when the Timestamp option is also present.
The SACK-Permitted option is encoded as two bytes: Kind=4, Length=2. It carries no data payload and MUST NOT appear on non-SYN segments.