Summary

  • RACK marks a segment lost from transmission time, ACK/SACK evidence, RTT and a bounded reordering window. It does not observe a physical drop.
  • A later DSACK can suggest that a retransmission was spurious because duplicate data reached the receiver, but it does not identify the network cause.
  • Operations should retain inference inputs and every transmitted copy instead of converting a recovery decision into incident fact.

The retransmission can be correct before the history is known

RACK asks a practical question: has enough newer delivery evidence and enough time accumulated to retransmit an older unacknowledged sequence range? The sender cannot wait indefinitely for proof. It must choose a bounded point at which recovery is safer than continued delay.

RFC 8985 therefore treats loss as an inference. A segment becomes eligible only when a later-sent segment has been delivered and the older segment remains undelivered beyond the estimated round-trip time plus the reordering window. That is stronger than a bare timer, but it is still evidence available at one sender at one moment.

Parallel forwarding, wireless link repair and other mechanisms can reorder packets. The original may still be in flight when its sequence range is marked lost. The mark means “retransmit this range under the algorithm,” not “a probe observed this packet being destroyed.”

RACK’s clock is part of the decision

RACK stores the most recent transmission time for each segment, including retransmissions. It selects the most recently sent segment known to have been delivered and derives a recent RTT sample. Older outstanding ranges are compared with that delivery point and the reordering window.

The window is deliberately adaptive and bounded. A small initial value recovers short flows quickly but accepts some risk of spurious retransmission. Evidence of reordering can expand the budget; the bound prevents indefinite delay from becoming the price of every ambiguous packet.

TLP covers the sparse-ACK edge. Before an RTO, it sends new data or retransmits the highest-sequenced segment to solicit feedback. The returned ACK can give RACK enough evidence to infer that earlier ranges need repair. The probe creates information; it does not turn an inference into direct observation.

DSACK changes the retrospective account

RFC 2883 lets a receiver report a duplicate segment or duplicate sequence range. When a sender receives DSACK after retransmitting, the evidence can suggest that the retransmission was unnecessary and that reordering, delayed delivery or duplication affected the sequence history.

That hindsight matters. RFC 8985 recommends using DSACK to expand the reordering window because a prior window may have been too small. Yet DSACK does not name the queue, radio, link, tunnel or ECMP member responsible. It reports duplicate receipt, not a complete causal trace.

Sources