SYSTEM Cited by 1 source
TCP Reno¶
TCP Reno is the classical loss-based congestion-control algorithm standardised by RFC 5681 — the workhorse CCA underpinning Internet TCP for decades before CUBIC displaced it as the Linux default. Reno also ships as an alternative CCA in quiche, Cloudflare's user-space QUIC / HTTP/3 library.
Algorithmic core¶
Reno is the textbook AIMD (additive-increase, multiplicative-decrease) loss-based CCA:
- Slow start.
cwnddoubles every RTT until reachingssthreshor a loss event. - Congestion avoidance (AIMD). Post slow-start,
cwndgrows linearly (+1 MSS per RTT — "additive increase") until a loss event. - On loss.
cwnd ← cwnd / 2,ssthresh ← cwnd/2("multiplicative decrease"). Resume congestion avoidance. - No epoch state. Unlike CUBIC, Reno has no cubic-growth- curve reference timestamp; no "shift forward by idle duration" optimisation; no minimum-cwnd recovery-start-time state variable whose arithmetic can overflow the congestion- avoidance boundary.
That structural simplicity is what made Reno the control experiment in Cloudflare's 2026-05-12 quiche minimum-cwnd- death-spiral diagnosis: the same 10 MB download under 30% loss during the first 2 s that failed ~60% of runs on CUBIC passed 100% on Reno (Source: sources/2026-05-12-cloudflare-when-idle-isnt-idle-how-a-linux-kernel-optimization-became-a-quic-bug).
Reno vs CUBIC trade-off¶
- Reno is gentler but slower to ramp up on high-BDP paths.
Linear
cwndgrowth means a fat pipe (large bandwidth-delay-product) takes many RTTs to fill. - CUBIC's cubic growth curve wins on high-BDP paths because
cwndaccelerates further from the last loss point. The cost is a more complex state machine — see concepts/cubic-epoch — and, as the 2026-05-12 post showed, more corners where port-from-kernel-to-userspace bugs can hide. - Both are loss-based: neither distinguishes "loss because the bottleneck buffer overflowed" (genuine congestion) from "loss because of a wireless flake" (false positive). Model-based CCAs like BBRv3 are the alternative family.
Seen in¶
- sources/2026-05-12-cloudflare-when-idle-isnt-idle-how-a-linux-kernel-optimization-became-a-quic-bug
— canonical wiki instance as the control experiment that
localised the CUBIC minimum-cwnd death-spiral bug. Swapping
CUBIC for Reno on the identical test fixture (10 MB download,
RTT = 10 ms, 30% loss for first 2 s, 10 s timeout) produced 100% pass rate — directly implicating CUBIC-specific logic, not quiche's general QUIC handling.
Related¶
- systems/cubic-congestion-control — the loss-based CCA family member Reno sits alongside as Linux/quiche options.
- systems/bbrv3 — the model-based alternative.
- systems/quiche — the userspace embedder offering Reno + CUBIC + BBRv3.
- concepts/congestion-window
- concepts/bytes-in-flight
- companies/cloudflare