Summary

  • A cumulative ACK is a durable boundary: every earlier byte has arrived. A SACK block is different—it says that a later range is queued now, and the receiver may later discard it.
  • The distinction keeps recovery responsibility at the sender. The sender retains data, combines partial reports into a scoreboard and chooses retransmissions under unchanged congestion rules.
  • D-SACK made the report more diagnostic by revealing duplicates, but it still did not prove a cause or prescribe a response. TCP gained shared evidence without creating receiver-side authority.

The bytes that could not yet be released

Assume a sender has transmitted bytes 5000 through 9000. The first segment is missing, later segments arrive, and the receiver reports the block [5500,9000). The sender now has unusually specific news: much of the flight is waiting beyond one hole.

Yet it must not erase its copy of those later bytes. Memory pressure may cause the receiver to discard data it previously described. A retransmission timeout may arrive after the report has become stale. Only when the ordinary acknowledgment advances beyond a range does the sender receive the protocol's final cumulative commitment.

SACK therefore begins with a productive contradiction. The report is detailed enough to change action but not strong enough to end responsibility.

One field that was allowed to make a promise

RFC 793 defined ACK X to mean that every octet below X has been received and X is next expected. This cumulative boundary supports ordered delivery and eventually lets the sender release buffered data.

The same strength makes the field silent about islands beyond the first gap. Repeated ACK 5000 cannot distinguish one missing segment from widespread loss. As windows grew, resending everything wasted capacity, while discovering one hole per round trip wasted time.

The solution did not weaken the promise. It added a second kind of statement with deliberately weaker force.

A published option was not yet a common practice

RFC 1072 proposed selective acknowledgment options in 1988. The receiver would negotiate permission in the SYN and describe non-contiguous data during the connection. Peers that did not understand the option could continue with cumulative ACKs.

The design did not become the shared Internet mechanism in that form. RFC 6247 later moved RFC 1072 to Historic, and the intervening record attributes non-deployment to disagreement involving window scaling. Publication established a proposal, not simultaneous implementation.

A report intentionally smaller than the queue

RFC 2018 revised the option in 1996. SACK-Permitted appears only in SYNs. A later SACK option carries pairs of 32-bit sequence edges: the first byte of a queued block and the byte immediately after its end. The normal ACK keeps its original meaning.

TCP offers only forty bytes of option space. A SACK option can carry four blocks alone and commonly three when timestamps are present. A receiver may therefore hold more islands than one packet can describe. It places the block changed by the newest segment first and repeats recent blocks in later acknowledgments, because reports can themselves be lost on the reverse path.

No individual SACK is a complete inventory. The sender accumulates small, overlapping observations into its own model.

Reneging draws the line between advice and receipt

RFC 2018 explicitly calls SACK information advisory. A receiver may renege: it may discard bytes it previously reported. The sender can avoid retransmitting a SACKed range during ordinary recovery, but it must retain the original data until cumulative acknowledgment covers it.

After a retransmission timeout, the sender must be prepared for earlier SACK information to be wrong. This fallback is not an embarrassing exception. It is the mechanism that makes optional, revocable evidence safe. The base commitment survives when the richer channel fails.

RFC 6675 later specified a conservative sender-side scoreboard. Reports update an estimate of what remains in the network; the sender decides which segment is eligible next. The receiver supplies coordinates, not the recovery program.

A duplicate can be observed without explaining itself

RFC 2883 extended the first SACK block so a receiver could report duplicate data. D-SACK can support several different explanations: packet reordering, loss of an ACK, network replication or a retransmission timer that fired too early.

The document deliberately prescribes no single response. It also notes that the sender cannot necessarily trust the receiver to report honestly. A duplicate report is evidence of an arrival pattern, not proof of its cause and not authority to alter every sender algorithm.

Better testimony did not create more capacity

Selective evidence also remained separate from congestion entitlement. RFC 5681 defines the sender's congestion obligations, and RFC 2018 requires SACK recovery to preserve them. Knowing which bytes are missing helps spend a permitted window wisely; it does not enlarge that window.

This is why SACK is not a second version of the congestion-collapse story. Congestion control asks how much the sender may put into the path. SACK asks which retained bytes are the best candidates within that budget.

Sources and evidence limits

The RFCs establish cumulative and selective semantics, option limits, reneging, sender recovery and duplicate reports. They do not establish one worldwide deployment date or one performance gain for every path. A SACK block cannot identify the failed device, prove loss rather than reordering, authenticate the receiver or certify permanent storage.

The historical achievement was narrower and more durable: TCP made a revisable report interoperable while keeping the final promise, the retained copy and the consequences of action with the sender.