TCP SACK: Narrowing Loss Recovery with Selective Acknowledgments
How TCP SACK reports received ranges beyond the cumulative ACK, what D-SACK can signal, and why these options do not replace retransmission or congestion control.
Publication & corrections: infostoa · Editorial standards
Individual author and specialist reviewer information is not provided for this article.
A TCP cumulative acknowledgment identifies the next byte expected after the contiguous data received so far. If later data arrives beyond a gap, the cumulative ACK may not show which following ranges have already reached the receiver. Selective acknowledgment (SACK) adds that information so a sender can avoid retransmitting data that is already present. SACK assists loss recovery; it does not replace TCP retransmission or congestion control.
Negotiation and the cumulative ACK
RFC 2018 allows a TCP endpoint that can receive SACK information to send a SACK-Permitted option in a SYN during connection setup. After the connection opens, the receiver can report the edges of noncontiguous sequence ranges in a SACK option. This does not change the cumulative ACK field. The ACK number still marks the end of contiguous data, while SACK blocks describe data received beyond a gap that prevents cumulative acknowledgment from advancing.
For example, if range A is missing but later ranges B and C arrive, the cumulative ACK can remain before A while SACK reports B and C. The sender can compare those blocks with its transmission queue and record what has already arrived. TCP option space is limited, so an ACK may not carry every block. RFC 2018 recommends reporting recent changes and repeating some earlier blocks, but lost ACKs or limited space can leave the sender’s view late or incomplete.
A sender scoreboard distinguishes retransmission candidates
RFC 2018 describes one possible sender implementation: maintain a queue of transmitted but not cumulatively acknowledged segments and mark ranges covered by SACK. When choosing a later retransmission, the sender can skip blocks reported as SACKed and retain unacknowledged ranges as candidates. This bookkeeping is commonly called a SACK scoreboard. It maps receiver reports to the sender’s own transmission history; it does not prescribe one complete operating-system algorithm.
When multiple segments are lost in one window, the sender can distinguish received ranges from gaps more precisely than with cumulative ACK information alone. This can reduce needless retransmission of later data that already arrived. The timing of retransmission and fast recovery still depends on loss-detection and congestion-control algorithms and their implementation. SACK does not promise a particular recovery time or throughput gain for every loss pattern.
D-SACK is a clue about duplicate reception
RFC 2883 defines the Duplicate SACK (D-SACK) extension. If the receiver gets a sequence range it already received, it can report the duplicate range in the first SACK block. The sender can compare that clue with its own retransmission history to assess whether retransmission followed actual loss or whether delay or replication on the path produced a duplicate arrival. D-SACK is evidence for an assessment, not a complete network diagnosis.
If the ACK carrying the report is lost, the sender will not receive that D-SACK information. The sender must interpret it alongside the cumulative ACK and its own transmission record. RFC 2883 also cautions that an observed duplicate may relate to an earlier cycle through the sequence-number space. A duplicate block should therefore not be treated as definitive proof of packet replication without considering reordering and retransmission context.
SACK and congestion control have different jobs
SACK is an acknowledgment option that gives a more detailed view of received data. Congestion control regulates how much data is sent and at what rate; timers and loss detection affect when recovery begins. Because these mechanisms interact, seeing SACK in a packet capture does not establish the congestion window, retransmission timing, or achieved throughput. RFC 2018 describes SACK as advisory and notes that a receiver may later discard data it previously reported in a SACK block.
The expert perspective when reading a capture is to separate SYN negotiation, cumulative ACK movement, repeated blocks, retransmission order, and duplicate reports. Diagnosing a particular implementation also requires its operating system and version, congestion-control module, timestamps, and capture location. This article explains option semantics and examples in two IETF documents; it does not rate the performance or security of every TCP connection.