Summary

  • RFC 3517 converted cumulative acknowledgments and SACK blocks into a sender-side scoreboard, then used SetPipe() to estimate how many octets should still be treated as in flight.
  • The estimate could conservatively count two copies of retransmitted data because the sender did not know which copy had left the network. cwnd - pipe authorized another send; it did not prove path inventory or delivery.

Imagine a sender after several losses in one window. A cumulative acknowledgment says where the uninterrupted prefix ends. SACK blocks report islands received beyond the gap. None of those messages places an observer inside the routers. Yet the sender must decide whether to retransmit, send fresh data or wait.

RFC 2018 supplied the receiver's vocabulary. SACK-Permitted negotiated use of selective acknowledgment, and SACK blocks described non-contiguous received ranges. That evidence sharply reduced needless retransmission after multiple losses. It was still advisory. A receiver could discard data it had previously SACKed, so the sender could not free the retransmission buffer until cumulative acknowledgment advanced.

RFC 3517 supplied a conservative way to act on the evidence. The sender kept HighACK, HighData, HighRxt, RecoveryPoint and a scoreboard. Update() marked ranges cumulatively ACKed or selectively ACKed. IsLost() judged a sequence number lost only after a threshold of higher SACK evidence. The judgment was useful, but it did not reveal the link, queue or event that dropped a segment.

SetPipe() then traversed sequence space from HighACK to HighData. Unsacked data not yet judged lost increased pipe because the sender assumed it remained in the network. Retransmitted octets at or below HighRxt also increased it. The result was explicitly an estimate.

The most revealing rule was double counting. If data was retransmitted before being classified lost, the original and retransmitted copy could both contribute to pipe. The sender could not know whether one transmission or both had left the network. Counting both reduced the risk of injecting too much additional traffic. It encoded uncertainty into a control variable instead of laundering uncertainty into a false measurement.

When the duplicate-ACK threshold opened recovery, RecoveryPoint was set to HighData, the congestion window was reduced under the contemporary congestion-control rules, the first presumed loss was retransmitted and SetPipe() ran. Each later ACK updated the scoreboard and caused the estimate to be recalculated. If cwnd - pipe left at least one SMSS of room, NextSeg() chose what could be sent next.

That subtraction was a permission check, not a sensor. Incrementing pipe after transmission changed the sender's account. It did not certify that a packet entered a particular queue, remained on the path, reached the receiver or was consumed by an application. A cumulative ACK beyond RecoveryPoint ended the episode at a different evidence layer.

The surrounding RFCs make the boundary clearer. Limited Transmit in RFC 3042 could use the first two duplicate ACKs to send new data before fast retransmit. D-SACK in RFC 2883 could report duplicate arrivals and help reveal unnecessary retransmission or reordering. RFC 5681 described the congestion-control framework, while RFC 6582 gave NewReno a partial-ACK recovery method without requiring SACK. Each mechanism changed what the sender could infer or do; none installed a packet counter in the path.

Timeout remained the fallback. When a retransmission timeout occurred, prior SACK information could no longer be treated as durable because the receiver might have reneged. The sender's apparently detailed scoreboard was therefore neither a permanent receiver ledger nor proof of application delivery.

RFC 6675 obsoleted RFC 3517 in 2012. It refined the loss threshold, recovery entry and rescue retransmission rules, but retained the language of estimate and the advisory character of SACK. The historical correction was not that pipe became truth. It became a better-specified estimate.

RFC 6937 later introduced Proportional Rate Reduction and contrasted delivery-based recovery pacing with the RFC 6675 pipe algorithm. That shift matters: recovery accounting is a policy surface. Different algorithms can act conservatively on the same incomplete evidence without any of them becoming a direct measurement of the network.

RFC 9293 now supplies the TCP base specification, and IANA records the SACK-Permitted and SACK option assignments. A registry row establishes code-point authority. It does not prove negotiation on a connection, correct scoreboard behavior, a particular loss event or a delivered byte.

The durable lesson is modest and powerful. Internet protocols often need operational variables before reality is fully observable. A sound standard names the variable's evidence, scope and uncertainty. RFC 3517 did that with pipe: enough knowledge to choose the next transmission, not enough knowledge to claim the network had been counted.

Sources