What is RACK?

Recent Acknowledgment (RACK) is a TCP loss-detection algorithm that judges whether a segment is lost from elapsed time since it was sent, rather than counting duplicate acknowledgments the way older TCP stacks do. That shift makes loss detection accurate during packet reordering and tail drops, and Versa’s VOS TCP optimization offers RACK as a selectable loss-detection method to speed up recovery.

Key takeaways

• RACK detects lost TCP segments using elapsed time, not duplicate-ACK counts.
• It tolerates packet reordering instead of mistaking it for loss.
• Tail Loss Probe (TLP) pairs with RACK to catch drops at a flight’s tail.
• Standardized in RFC 8985, RACK-TLP is now common in modern TCP stacks.
• VOS TCP optimization offers RACK as a selectable loss-detection method.

On this page: Why it matters · How it works · Components of RACK · RACK & Versa · FAQ

Why is RACK important?

Classic TCP loss detection – a fixed duplicate-ACK threshold, later refined by SACK-based recovery – works well on simple paths, but it gets two situations wrong. It can mistake reordering for loss, retransmitting a segment that was only delayed. And it is blind at a flight’s tail: once no more data is queued behind a lost segment, nothing triggers the duplicate ACKs the old algorithm needs, so recovery fell back to a slow retransmission timeout instead of a near-instant fast retransmit.

RACK closes both gaps by reasoning about time instead of ACK counts, paired with a probe mechanism for the tail case. Networks that combine multiple underlying links – the situation SD-WAN fabrics create routinely – see more cross-path reordering, and RACK’s tolerance for it keeps throughput and latency more predictable.

What is RACK?

Every transmitted segment gets a send timestamp. When an ACK or SACK block arrives, RACK checks each earlier, still-unacknowledged segment and asks whether enough time has passed – measured against the connection’s most recent round-trip-time sample – that it must be lost rather than merely reordered. That threshold is the reordering window: a gap unacknowledged longer than roughly the recent RTT gets marked lost and retransmitted immediately; a reordered segment’s late ACK inside the window causes no retransmit.

Using the most recent RTT sample, rather than a long-running average, lets RACK react quickly to latency changes. On its own, RACK only evaluates when an ACK arrives, so it still needs a mechanism for silence – why RFC 8985 pairs it with Tail Loss Probe rather than defining RACK alone.

Components of RACK

RACK-TLP, as standardized in RFC 8985, has two parts. Recent Acknowledgment (RACK) is the time-based detector described above: it runs whenever an ACK or SACK block arrives and reasons about elapsed transmit time to decide whether unacknowledged data is lost. Tail Loss Probe (TLP) covers what RACK alone cannot reach – a connection that has stopped sending, so no new ACK will arrive to reveal a loss. TLP arms a short probe timer, and if no ACK lands before it fires, sends a probe segment – new data if available, otherwise a retransmission of the last segment – purely to generate feedback.

That feedback confirms the data arrived, or gives RACK the signal to declare the segment lost, sidestepping the slower timeout older stacks would otherwise wait out.

RACK & Versa

Versa’s VOS TCP optimization offers RACK as a selectable TCP loss-detection method – the TCP Loss Detection setting defaults to classic duplicate-ACK counting, with Recent acknowledgment (RACK) as the alternative an administrator enables, implemented with the supplemental Tail Loss Probe per the IETF specification. SD-WAN paths often combine multiple underlying links with different latencies, so reordering is more common than on a single, direct path – precisely what RACK tolerates without an unnecessary retransmit. Tail-drop recovery matters too on WAN paths, where a lost final segment would otherwise stall a flow until a full retransmission timeout expired.

Frequently asked questions

What problem does RACK solve that older TCP loss detection didn’t?

Duplicate-ACK counting assumes a fixed number of out-of-order ACKs means loss, which misfires on ordinary reordering, and it has no signal when a flight’s last segment is lost. RACK uses elapsed time instead, catching both cases without retransmits triggered by normal jitter.

How does RACK differ from duplicate-ACK-based fast retransmit?

Fast retransmit declares loss after a fixed count of duplicate ACKs, regardless of how much time has actually passed. RACK instead compares elapsed time since a segment was sent to the connection’s recent round-trip time, so it can tell a slow, reordered packet from a genuinely lost one.

What is Tail Loss Probe, and how does it relate to RACK?

TLP is RACK’s companion mechanism for the case where a connection stops sending, so no new ACK can arrive to reveal a loss. TLP arms a short timer and sends a probe segment if no ACK shows up, generating the feedback RACK needs to detect the loss quickly.

Is RACK the default loss-detection algorithm on modern systems?

RACK-TLP was standardized as RFC 8985 in 2021 and has since become the default loss-recovery mechanism in mainstream stacks, including Linux. It coexists with SACK rather than replacing it, since RACK still relies on SACK information to identify missing segments.

Does RACK replace TCP SACK?

No. SACK (Selective Acknowledgment) tells a sender which segments arrived, and RACK uses that information as an input. RACK is the decision layer that interprets SACK data and transmit timestamps to decide when enough time has passed to call a gap a loss, not a substitute for SACK itself.

More on RACK

If you want to learn more, these are sources we trust.

Related terms

If you’re reading about RACK, these are worth looking at next.