Summary

  • RACK marks an older TCP transmission lost only after a later-sent segment has been acknowledged and the older one has remained unacknowledged beyond an RTT-derived reordering window. It converts delivery evidence into a time-ordered test rather than treating a fixed duplicate-ACK count as proof.
  • Tail Loss Probe sends at most one controlled probe before the retransmission timeout to invite an acknowledgment. The probe is a question, not a loss verdict; RACK detects, while congestion control separately decides when recovery may send.

The third ACK was never a stopwatch

TCP’s familiar fast-retransmit story begins with duplicate acknowledgments. If three arrive, the sender infers that something earlier probably went missing. That rule works best when enough later packets remain in flight to generate the evidence. A short web response, a request ending at the tail of a window, or an application-limited flow can lose its final segment and have no succeeding train of packets to produce three witnesses. Recovery then falls through to the retransmission timeout, a deliberately conservative backstop.

Selective acknowledgment improved what the receiver could report. RFC 2018 lets an ACK describe non-contiguous byte ranges already received. RFC 6675 turns that scoreboard into a loss-recovery procedure, but its principal loss threshold still counts discontiguous SACKed sequences or bytes above a hole. Packet duplication, stretch ACK behavior and reordering can make a count either late or overconfident. The count reflects what happened in sequence space; it is not a measurement of how long the disputed transmission has been exposed to the path.

RFC 8985’s Recent ACKnowledgment, or RACK, changes the axis. Its authors are Yuchung Cheng, Neal Cardwell, Nandita Dukkipati and Priyaranjan Jha. IETF published their work on the Standards Track in February 2021, so the design is a collective standards result, not an invention that can be assigned to one co-author. Cardwell’s public IETF and Google Research profiles establish his connection to the work and to networking research. They do not establish that he controls every implementation bearing the algorithm’s name.

A later delivery starts the case

RACK remembers the most recent transmission time of each outstanding segment, including the time of a retransmission. When an ACK or SACK proves delivery of data sent later than an outstanding segment, the sender obtains a reference event: the path has delivered something that departed after the disputed packet. The sender records the latest such delivered transmission and its acknowledgment time.

That evidence is necessary but insufficient. Let the disputed transmission be S. RACK can mark S lost only when a later-sent packet has been delivered and S has remained unacknowledged for at least an estimated round-trip time plus a reordering window. The specification describes a conceptual timer for each segment, but an implementation need not literally allocate thousands of timers; one timer can track the earliest expiry implied by the outstanding set.

This is the mechanism’s intellectual economy. An ACK proves that a byte range reached the receiver. A SACK proves delivery outside the cumulative ACK frontier. Neither proves why S has not been acknowledged. Congestion, wireless loss, receiver behavior, a different path, benign reordering and delayed feedback can look similar at the sender. RACK does not discover the cause. It asks whether the combination of later delivery and elapsed time is now strong enough to treat S as lost for transport recovery.

The timestamp requirement matters. RFC 8985 requires the sender to retain the latest transmission time for every outstanding segment at a granularity finer than one quarter of the minimum RTT. Coarser records blur together packets that the algorithm is supposed to order. The RFC estimates four or eight bytes of additional state per segment, depending on the timestamp representation; that estimate is implementation context, not a universal memory bill.

Reordering gets a budget, not a pardon

A path can deliver packets out of order without losing them. RACK therefore adds a reordering window to its RTT test. Under the RFC’s conditions, that window can begin at zero or a small fraction of the minimum RTT. If Duplicate SACK reports reveal that a retransmission was spurious, the sender gains evidence that the path reordered more deeply than expected and can enlarge the window. The document recommends DSACK-based adaptation and says the window should be bounded by the smoothed RTT.

The window encodes a real tradeoff. A narrow setting reacts quickly, reducing the time an application waits for genuine loss, but it risks retransmitting a merely delayed packet. A broad setting tolerates disorder and wastes less capacity on false positives, but it postpones repair. “Time based” therefore does not mean “certain.” It means that uncertainty is made explicit in a bounded temporal allowance, rather than hidden inside a fixed number of duplicate ACKs.

This also clarifies what operators should log. A useful RACK decision receipt contains the disputed segment’s latest send time, the send time of the later delivered segment, the acknowledgment or SACK that established delivery, the RTT estimate, the current reordering window and any DSACK evidence that changed it. A packet trace showing only “RACK loss” records a conclusion without the premises needed to audit it.

One probe at the quiet end

RACK has a companion in RFC 8985: Tail Loss Probe, or TLP. The tail is where ACK-clocked evidence becomes scarce. Rather than wait immediately for the retransmission timeout, the sender schedules a probe timeout, typically around twice the smoothed RTT, subject to the specification’s interaction with delayed acknowledgments and the RTO. TLP requires a fresh RTT measurement and cannot leave more than one probe outstanding.

When the probe timer fires, the sender transmits new data if data is available and the congestion window permits it. Otherwise it retransmits the highest-sequence outstanding segment. That choice is deliberate: a new or repeated tail packet may elicit an ACK that reveals the state of earlier data. The sender can temporarily send one probe beyond a full congestion window, but that byte accounting is not erased; the next ACK must reconcile it.

The probe itself proves nothing about the original tail. It is an instrumented question sent into an otherwise silent conversation. Its returning ACK may provide the later-delivery evidence RACK needs, or may show that the original data arrived and only acknowledgment dynamics were quiet. If the probe is also lost, the RTO remains the final safety net. Calling TLP “an early retransmission decision” misses the control boundary: it creates evidence; RACK evaluates loss.

Detection does not own the congestion window

Once RACK marks a segment lost, it still may not transmit whenever it likes. RFC 8985 explicitly requires retransmission to wait until the congestion-control algorithm permits it. RFC 5681 defines the established congestion-control obligations; RFC 6937’s Proportional Rate Reduction is recommended for pacing transmissions during recovery. Loss detection and sending authority are coupled, but they are not the same subsystem.

That separation prevents a plausible but dangerous shortcut. Faster evidence should shorten uncertainty, not silently exempt recovery from network-safety rules. A sender that treats every RACK decision as an unconditional license to burst retransmissions would convert a better sensor into a more aggressive actuator. The architecture instead supplies a finding to congestion control, which owns the rate response.

RACK also differs from the retransmission timer standardized in RFC 6298. RTO protects progress when finer-grained evidence does not arrive; its backoff is intentionally cautious. RACK and TLP attempt to resolve common losses before that deadline without deleting it. The stack is layered: selective acknowledgments describe received ranges, RACK assesses time-ordered loss, TLP solicits evidence at the tail, congestion control regulates recovery, and RTO catches silence that defeats the earlier mechanisms.

What the acknowledgment cannot certify

It is tempting to convert precise timing into a larger claim about the network. That would be an evidentiary mistake. Delivery of a later packet does not certify that the path is healthy, that a middlebox behaved correctly, that the endpoint identity is trustworthy, or that the application consumed the bytes. It does not locate congestion. Even a correct loss inference is a transport-level conclusion made from sender-visible signals.

The security discussion in RFC 8985 inherits the known concerns around SACK. It also notes a narrower advantage: ACK splitting is less effective because acknowledgment of one additional byte does not advance RACK’s record of the most recently delivered transmission. That is resistance to one tactic, not a general authentication property. Forged or misleading transport feedback remains a different problem from ordering honest feedback in time.

The idea has travelled. RFC 9002’s QUIC loss detection uses time thresholds and acknowledges RACK-TLP as part of its lineage, but QUIC’s packet-number spaces, acknowledgment rules and congestion-control interface are not simply TCP transplanted. Similarity is useful for comparison; it is not evidence that the two mechanisms have identical state, thresholds or operational authority.

A measured historical motivation

The 2013 paper “Reducing Web Latency: the Virtue of Gentle Aggression,” whose authors include Cardwell, studied loss recovery in a sample of Google frontend traffic. In that bounded environment, the paper reported that 77 percent of observed losses were repaired through RTO rather than fast recovery. In its experiments, the tested combination of mechanisms reduced mean latency by 23 percent and 99th-percentile latency by 47 percent.

Those figures explain why the quiet tail mattered to the designers. They are not a current deployment census, an Internet-wide forecast, or a guarantee created by RFC 8985. The paper predates the final Standards Track text and evaluates a particular system. Its durable lesson is narrower: when many transactions are short, mechanisms that require a long run of later packets leave a large class of losses waiting for the bluntest timer.

Sources