The SACK Mechanism
Selective Acknowledgment (SACK) extends the TCP header using options to explicitly inform the sender about non-contiguous blocks of data that have been successfully received. By providing a map of received sequence ranges, the receiver enables the sender to isolate precisely which packets were lost. This capability transforms recovery from a guesswork-heavy process into a surgical operation.
The process operates through two primary TCP header components:
SACK Permitted Option: Negotiated during the initial three-way handshake, this field flags that both peers support the SACK mechanism.
SACK Blocks: Included in the header during data transfer, these blocks contain left and right edge sequence numbers, representing chunks of data that arrived out of order.
Efficiency and Performance Trade-offs
The primary benefit of SACK is the reduction of unnecessary retransmissions. By precisely identifying missing segments, the sender avoids sending data that the receiver has already buffered. This is particularly crucial in networks with high Bandwidth-Delay Products (BDP), where a single timeout-induced slow start can waste significant transmission time.
However, SACK introduces overhead. Since the TCP header has a finite size, the number of SACK blocks that can be reported is limited—typically to three or four blocks. In scenarios with extremely high loss rates where fragmented data spans many non-contiguous ranges, the receiver must prioritize which blocks to report. This requires a robust implementation that balances header space constraints with the need for accurate recovery instructions.
For engineers, SACK represents a fundamental shift from reactive, broad-stroke error recovery to informed, granular flow control. Understanding its mechanics is essential for debugging tail latency in distributed systems and optimizing high-performance network stacks.
