1 Introduction

TCP uses congestion control (CC) to decide how fast to transmit and how much data to keep in flight [1] [2]. For decades the dominant approach has been window-based: the sender tracks a per-session congestion window (CWND) and a round-trip-time estimate (RTT). Reno, NewReno, CUBIC [3], and Compound TCP all follow this model¹. Google’s BBR [4] broke partially away by pacing at an explicitly modeled rate, but BBR still derives that rate from ACK-timing measurements whose fidelity has eroded under modern path conditions.

Production CCs feed ACK-timing inputs into their signal-to-action conversion: the RTT sample, the delivery-rate estimate, the ACK arrival cadence itself. Over the preceding two decades those inputs have degraded as reliable signals on the wireless, virtualized, and high-BDP paths that now dominate traffic. The degradation is not easily fixable through additional algorithmic refinement. NIC packet serialization has outpaced the dominant jitter sources by roughly three orders of magnitude (§2), which makes jitter second only to packet loss as the impairment shaping CC behavior on modern paths. Finally, virtualized infrastructure adds correlated jitter that EWMA filters have difficulty rejecting and wireless last-acre loss is no longer a reliable congestion signal §3.

Access infrastructure is moving toward a 10 Gbit foundation [5], and every defect measured here widens with that upgrade; the same study shows the egress queue cannot close the shortfall, because a scheduler can reward senders that pace well and constrain those that do not, but it cannot repair the sender’s corrupted estimator. [6] shows the degradation is manageable with a production CC satisfying the design principles this paper closes with (§9); on live paths in it delivered 1.5× CUBIC and BBR on a wired ISP path, 1.3× on LTE, and 4.4× CUBIC on satelite, a margin that grows as the ACK clock degrades. All from one control loop with no per-medium profile.

The remainder of the paper is organized as follows: §2 through §5 discuss failure modes that compound on the impaired paths modern infrastructure routinely produces. §6 measures each mode by sweeping one impairment dimension at a time, §7 reports directional findings that end-to-end throughput hides, and §8 argues that QUIC’s relocation of CC into user space compounds impairments. §9 closes with an enumeration of properties that, in our opinion, a next-generation CC algorithm should satisfy.

2 The Jitter-Serialization Inversion

Jitter is the variation in packet arrival delay; serialization time is the time it takes to inject a packet onto the wire, set by the NIC hardware and the negotiated data rate. The two have different masters: serialization falls with every hardware upgrade, while jitter is driven by contention, scheduling, and preemption mechanisms that those upgrades leave untouched.

Figure 1 holds one representative jitter source nearly constant while the link rate scales three orders of magnitude underneath it. The source is WiFi contention delay, improving only modestly from 500 µs to roughly 350 µs across 802.11 generations [7] [8]; serialization of a 1500-byte packet meanwhile falls from 1,200 µs at 10 Mbps to 12 µs at 1 Gbps, a small fraction of the

jitter beside it, and at 10 Gbps it is effectively invisible. Process scheduling jitter is amortized across burst transmissions, but the sources themselves do not speed up with NIC bandwidth improvements: WiFi contention, cellular scheduling, hypervisor preemption, and OS context switches all run on clocks of their own.

The rate formula at the heart of window-based CC is:

so noise in RTT perturbs the computed rate directly. The measured round trip decomposes as $\text{RTT}\left(𝑡\right)={\text{RTT}}_{\text{base}}+𝑄\left(𝑡\right)+𝐽\left(𝑡\right)$: fixed propagation, genuine queueing, and non-congestive timing noise respectively. A controller needs $𝑄$ but observes only the sum, and a scheduler excursion is indistinguishable from the same microseconds of queue growth. In signal terms $𝑄$ is the signal and $𝐽$ the noise, so the signal-to-noise ratio of ACK timing as an estimator of network state declines with every hardware generation. We define the jitter-serialization ratio ${𝐽}_{𝑆}$ as jitter magnitude over serialization time. A packet of size $𝐿$ on a link of rate $𝑅$ serializes in ${𝑇}_{𝑠}=\frac{𝐿}{𝑅}$, so

and for any jitter process whose timescale does not fall as $\frac{1}{𝑅}$, Equation (2) grows linearly in link rate: the inversion follows from the sources having clocks that are not the link’s clock. RFC 8868 [9] already normalizes delay variation by packet serialization time.

Figure 2 plots ${𝐽}_{𝑆}$ across five link speeds for LTE/cellular, WiFi TXOP, hypervisor, and OS-scheduler jitter. The values are deliberately conservative, chosen to show the status quo in its best possible light: cellular jitter runs 4–16 ms under grant-based scheduling [10] and 10–20 ms once DRX sleep cycles are active [11], and we use 2 ms, two to ten times below the literature, while WiFi TXOP contributes about 0.5 ms and hypervisor and OS-scheduler jitter come in under 0.1 ms. The last two are conservative as well: the IX [12] dataplane work measured commodity-OS network stacks adding hundreds of microseconds on 10 GbE hardware capable of 10–20 µs, and the Bobtail study traced ~30 ms 99.9th-percentile tails in EC2 to virtualization scheduling [13]. Every source crosses the ${𝐽}_{𝑆}=1$ threshold; only the link speed at which it happens differs.² ${𝐽}_{𝑆}$ is a scale-separation indicator rather than an estimator-error model; mapping it quantitatively onto estimator error is deferred to the validation companion [14]. The standard answer to “my network is slow!” under-utilizes the equipment it buys: the step from 100 Mbps to 1 Gbps still had usable RTT signal, while 1 Gbps to 10 Gbps delivers less than expected because the ACK timing signal is dwarfed by jitter, and even a clean path hits the socket-buffer ceiling measured in §6. The asymmetry persists because jitter does not aggregate away as capacity grows [15], and RFC 9743 now warns from the standards track that delay varies for reasons unrelated to congestion and that reading such variation as congestion needlessly reduces throughput [16].

Offload and link-layer batching. Jitter is not the only process that erases ACK spacing. Receivers coalesce back-to-back segments with generic receive offload (GRO) and acknowledge the aggregate. WiFi block acknowledgment and cellular uplink grants release ACKs in batches, and senders emit TSO bursts that leave the NIC as a single block. On a wired ISP path we measured ACKs arriving in clumps every 4 ms with half the slots empty, 4 to 20 ACKs per clump, and 13 to 14 segments acknowledged per ACK, 56 at the 90th percentile [14]. The coalescing window is set in time, by NAPI polling and interrupt moderation, so the number of segments folded into one ACK grows with link rate, just as ${𝐽}_{𝑆}$ does. An estimator that reads rate or capacity from inter-ACK spacing, such as HyStart’s ACK-train exit or BBR’s delivery-rate sample, then reads the host’s batching schedule along with the path. BBR’s extra_acked estimator [17] only budgets extra in-flight for the batching; its rate estimate remains susceptible to it. Disabling GRO is not a remedy: it is on by default, and commodity CPUs need it to sustain 10 Gbps.

3 The Queue–RTT Feedback

When a sender injects data faster than a bottleneck can drain it, packets accumulate in the bottleneck queue and the sojourn time adds directly to the measured round-trip time, which lowers the computed rate through Eq.1. CUBIC’s window meanwhile continues to grow under its congestion-avoidance law, and the added in-flight data fills the queue further: queue grows, RTT rises, the derived rate shifts, the queue grows again. BBR exhibits the same coupling, mitigated by inflight caps and loss bounds. The feedback is architectural: SRTT conflates the propagation delay that a rate calculation needs with the queueing delay that is the result of that

calculation, and feeding a result back into its own input is the formal definition of positive feedback.

Formal statement. Let ${𝑑}_{𝑝}$ be the propagation delay and $𝑞\left(𝑡\right)$ the queue depth at time $𝑡$ expressed as a delay, then

and the sender computes its target rate as

On an uncongested path $𝑞\approx 0$ and the computation is correct. On a congested one $𝑞$ rises and $𝑟$ falls, and the loss-based response is to grow CWND on the next round to maintain throughput. But the rate that actually leaves the wire is bounded by serialization speed, so a larger CWND against a saturated wire becomes more in-flight bytes, a deeper queue, a larger $𝑞$, and a smaller $𝑟$ still. The cycle ends only when a loss event fires fast retransmit, and the accumulation at that terminal point is bounded by the buffer depth rather than by any rate decision the CC made. This is the bufferbloat pathology, and the remedy in the literature has not been to break the loop but to compensate for it at the queue, with AQM disciplines such as CoDel and PIE measuring sojourn time and injecting early loss or ECN marks in a bid to trigger a CC’s congestion response.

Queue compensation is insufficient. AQM is corrective rather than preventive: it assumes the CC will drive its rate to a buffer-depth limit and arranges for the response to fire at a smaller queue, leaving the CC’s own architecture unchanged. Three consequences follow. Its defaults encode an assumed RTT scale, so CoDel’s 100 ms interval and 5 ms target behave qualitatively differently on a 2 ms LAN than on a 600 ms satellite path, and one setting cannot serve both. It operates only where it is deployed, while wireless last-acres, cellular base stations, hypervisor virtual

switches, and ISP edge queues each run their own discipline or none at all, and the feedback loop survives in every hop that lacks one. Finally, it cannot compensate for the loop’s contribution to the rate estimate: a CC deriving rate from SRTT sees SRTT inflated by the queueing component whether or not the queue is being managed, so the estimate is incorrect even when the queue is shallow, a limit the companion scheduler study measures directly, finding even that the ECN signal DualPI2 adds profits most the sender that ignores it [5].

Mitigation in production CCs. BBR [4] partially escapes the feedback loop by deriving its rate from a delivery-rate sample and a windowed minimum of RTT ($\text{RTprop}$) rather than from SRTT directly, but both estimators are fed by measurements whose noise has grown with link speed (§2). Kumar et al. [18] document the resulting collapse on millimeter-wave paths: once jitter depresses the windowed-minimum RTprop below half the average RTT, BDP shrinks, CWND shrinks, delivery rate drops, BtlBw collapses, and the loop closes through a different state variable.

4 The Slow-Start Trap

TCP enters every connection through slow start: CWND begins at 10 segments per RFC 6928 [19] and doubles every RTT until a loss is detected or HyStart’s delay-based exit fires. It was designed when that initial window was a small fraction of the bandwidth-delay product, doubling was a reasonable way to find the path’s capacity, and a loss during the probe reliably meant the path was full; modern paths routinely violate all three conditions.

Figure 3 shows CUBIC doubling CWND every RTT, overshooting, losing packets, cutting to 70%, and regrowing through the cubic function in a cycle that leaves the path mostly empty during recovery; Figure 4 shows BBR’s STARTUP at twice estimated BtlBw on the same dataset, overshooting to twice the BDP in flight before its loss response settles it. Both probe capacity by exceeding it, but what follows differs: on a 1 Gbps link with 5% loss RFC 9438 CUBIC [3] manages 15.0 Mbps, 1.5% of capacity, while BBRv3 [4], whose inflight_hi bound stops it treating every loss as a window cut, holds 405 Mbps, 40%.³

Overshoot without a bounded correction is the failure. A sender has no way to find the bottleneck’s capacity except by testing it, so every CC at some point sends above the bottleneck rate and reads the drop, or above the bottleneck delay and reads the inflation. What decides the outcome is what bounds the overshoot and how soon the correction lands. Slow start’s overshoot scales with BDP, and its correction is a loss-triggered window cut that restarts the search. A bounded overshoot with a path-anchored correction behaves differently: the seeded start of [6] sends 3× above a 170 Mbps satellite path for one round trip; at the close of the first epoch, one minimum RTT later, its rate law reads the delivered volume and the RTT inflation and sets the pace to the rate the path delivered (bisecting over a few epochs when the path sits far below the seed), and the live retransmit rate across three media stayed under 0.05% of packets.

Packet loss compounds. CUBIC applies a 30% multiplicative decrease to every detected loss regardless of cause. Under the 5% Bernoulli loss routine on cellular last-acres, the chance of at least one loss inside a window of $𝑛=100$ in-flight packets is $1-{0.95}^{𝑛}$, or 99.4%, so every recovery is interrupted before the cubic function reaches its asymptote. BBRv3’s inflight_hi response at 2% loss stops the algorithm treating every loss as a window cut, which is why it keeps 40% of the link where CUBIC keeps 1.5%; the cost returns when the ACK direction loses too (§7).

5 The RTO Penalty

When every other recovery mechanism fails, TCP falls back to the retransmission timeout, floored at one second by the specification [2] and at 200 ms by deployed Linux, with exponential backoff. One RTO on a lossy-but-alive link costs 200 ms of zero throughput, enough at 1 Gbps to have carried 25 MB where this paper’s 10 MB transfer itself takes 84 ms at wire speed, and it resets CWND to one MSS and restarts slow start, compounding the cycle of §4. In the Figure 3 trace CUBIC falls through to

RTO three times. Linux’s 200 ms floor was chosen when access RTTs ran 100–300 ms on dial-up and early DSL, which made it a small multiple of the natural round trip and a reasonable guard against spurious retransmits. The machinery around it has since been revised, F-RTO detecting spurious timeouts and RACK-TLP front-running the timer, but the floor value itself survives every revision: the slowest deployed paths still exist, and one global floor that guards them cannot also fit a 2 ms LAN.

Backoff compounds it. Doubling the timeout on each attempt is correct for a sustained outage and harmful for transient loss recovery. A single dropped ACK can cost the sender a cumulative-ACK advance, leave it short of the dupACK threshold, and drop it through to RTO, which waits 200 ms, retransmits, meets another loss, waits 400 ms, and continues until the sender is in a feedback loop with its own recovery clock and the path’s capacity no longer bears on recovery time. This is the mechanism behind the CUBIC trace of Figure 3, where three RTO events punctuate a single 10 MB transfer on a 1 Gbps path with 5% loss and hold it to 15 Mbps (§4).

What RACK-TLP fixes and what it does not. RACK-TLP [20] replaced the fixed dupACK count with a time-based reorder threshold and added a Tail Loss Probe firing at $2\times \text{SRTT}$, 4 ms on a 2 ms link. Neither replaces RTO: if the probe is itself lost, the sender still falls through to the 200 ms floor.

6 Failure Magnitude

The four preceding failure modes are design artifacts, and each needs its magnitude measured. We do so using test sweeps that walk one impairment dimension while holding the others fixed on a picosecond-resolution discrete-event simulator, calibrated against production captures as described in [6], reporting goodput for RFC 9438 CUBIC and BBRv3 on a 1 Gbps path moving a 10 MB transfer, at 2 ms RTT unless the sweep varies it, with bottom panels adding a compounding impairment. The figures also trace

WarpRATE [6], a rate-paced reference CC included to show that the collapse measurements belong to the algorithms rather than to the path characteristics.

Jitter. Figure 5 sweeps Gaussian jitter from σ = 0.2 to 200 ms. The decline separates the field by estimator: CUBIC falls from 843 Mbps to 251 by σ = 5 ms, the rttvar of a busy LTE cell, and to 12 by 200 ms; BBR holds better at small jitter, 782 at 1 ms against CUBIC’s 350, but falls faster beyond it, to 183 at 5 ms and 1.7 by 200 ms; the rate-paced reference declines gracefully from 906 to 91. Compounding 1% data-path loss gives what §2 predicts: loss cuts interact with jitter-inflated recovery estimators, and CUBIC holds under 20 Mbps from σ = 5 ms onward.

Loss rate. Figure 6 sweeps loss from 0 to 10% at RTT = 2 ms. A cliff appears at 0.5%, where CUBIC drops 90% in one step, 883 to 85 Mbps, while BBR loses 34%; by 10% CUBIC delivers 3.0 Mbps on the 1 Gbps link. Adding σ = 1 ms jitter leaves the cliff at the same loss rate, confirming loss rather than jitter as the dominant impairment here. The cliff follows from treating every loss as congestion: one packet in

200, cut by 30%, becomes sustained CWND collapse.

Round-trip time. Figure 7 sweeps RTT from 2 to 200 ms, over which the deployed CCs decline from roughly 883 Mbps to 41: exponential slow start needs about seven RTTs to fill a 25 MB BDP and the 10 MB transfer ends first, which is the slow-start trap as a function of path length. Adding 0.5% loss and σ = 1 ms jitter holds CUBIC under 8 Mbps beyond 50 ms of RTT and takes BBR from 531 down to 19 across the same range.

Link speed and the socket-buffer ceiling. Figure 8 sweeps a clean 25 ms path from 100 Mbps to 10 Gbps moving 1 GB. Through 1 Gbps all three CCs track the port, 929 to 966 Mbps at 1 Gbps; at 2.5 Gbps the deployed CCs stop, CUBIC at 1,296 Mbps and BBR at 1,263, and at 10 Gbps they deliver the same 1,298 and 1,264 while WarpRATE scales to 7,190, 72% of the port. The ceiling is the kernel’s default socket sizing: of the congestion window, the receiver’s advertised window, and the send buffer, the constraint is the tested kernel’s default 4 MB autotuned send-buffer ceiling, which over a 25 ms round trip admits at most 1,280 Mbps, one-eighth of the 32 MB BDP, so the sender structurally cannot populate the path however cleanly it behaves and the plateau sits at the same absolute figure whether the port is 2.5 or 10 Gbps. Administrators can raise the buffer defaults, but they are sized by memory policy rather than matched to path BDP, so the defaults dominate in practice. Operational practice confirms the attribution: ESnet’s data-transfer tuning guides prescribe socket-buffer maxima in the hundreds of megabytes to reach line rate on high-BDP paths, and observe that on clean, tuned testbeds the choice of CC scarcely matters [21].

Table 1: Loss direction asymmetry. Goodput in Mbps under 5% Bernoulli loss.

Algorithm	Data-path loss	ACK-path loss	Both
WarpRATE	618	745	574
BBR	426	633	210
CUBIC	22	648	2.7

Wireless burst patterns. Figure 9 tests four models approximating real wireless media at RTT = 30 ms with 0.5% loss: Gaussian σ = 5 ms, WiFi TXOP at 2 ms burst intervals, LTE 1 ms subframe alignment, and 5G NR 0.5 ms slot scheduling. Across the four, CUBIC delivers 6.5 to 7.7 Mbps and BBR 56 to 178 on the 1 Gbps link. Burst-and-gap arrival and subframe batching corrupt exactly the ACK timing CUBIC and BBR pace from, the correlated-arrival case §2 identifies as hardest for EWMA estimators to reject.

Buffer depth. Holding the clean 1 Gbps path fixed and moving the bottleneck queue from 1× to 4× BDP moves no CC by more than 2%: CUBIC stays at 883 Mbps (HyStart exits slow start before the initial burst can overfill even the shallow queue), WarpRATE at 903, and BBR moves only from 861 to 879. Buffer depth, long treated as a universal amplifier, is moot under modern slow-start exits and paced starts; a probe bounded by hardware needs no compensation (P2, §9). The full study, and the qdisc layer’s structural inability to correct sender architecture, are in the companion papers [6] [5].

Each sweep isolates one dimension while real paths combine several, and the modes compound rather than add, as every bottom panel shows. None of these collapses is a tuning artifact: each traces to an architectural property catalogued in §2 through §5, and each persists at default settings on paths that wireless and high-BDP infrastructure routinely produce.

7 Path-Direction Asymmetry

Impairments can occur on the data direction or on the ACK return direction, and the two affect CC behavior asymmetrically. The asymmetry is invisible in a path-aggregate loss or jitter figure and surfaces only under per-direction injection. Each cell below is the mean of five seeds on the same simulator as §6, with WarpRATE included as a reference for a CC architected against the asymmetry.

Loss direction. In Table 1, ACK-path loss is largely benign for every CC⁴: the receiver already holds the data the lost ACKs described, and cumulative acknowledgment is self-repairing by design. Data-path loss is harmful for every CC, but the magnitude separates them by what each does on detection: loss-based CCs cut the rate on every event regardless of cause and deliver an order of magnitude less, while the delivery-rate and rate-paced CCs bound their inflight and keep most of their rate. Loss in both directions

Table 2: Jitter direction asymmetry. Goodput in Mbps, $𝜎=10$ ms with 1% data loss, 30 ms WAN.

Algorithm	Data-path jitter	ACK-path jitter	Both
WarpRATE	127	159	115
BBR	31	30	24
CUBIC	6	5	4

splits the field by architecture: the rate-paced sender holds most of its data-path figure, model-based BBR halves, and window-based CUBIC falls a further order below its own as the thinned ACK stream starves the window growth that recovery depends on.

Jitter direction. ACK-path jitter is the inverse case, harmful exactly where ACK-path loss was benign, because jittered ACKs corrupt the sender’s inter-arrival measurement and inflate every timing-derived estimator: a thinned ACK clock still tells the truth, a jittered one lies.

Impairment effects are asymmetric. Two impairments across two directions produce four distinct cases. Lost ACKs thin the feedback stream without requiring retransmission, so a correctly architected sender absorbs the variance without a rate response. Jittered ACKs force every timing-derived estimator to ingest noise. Lost data must be retransmitted, and the CC’s policy decides whether a rate cut accompanies it.

When an access medium has a lopsided profile, a satellite uplink with jittered scheduling over a clean downlink or a cellular cell with bursty downlink loss and a quiet uplink, the sender’s CC is responding to the harmful direction even when the operator’s attention may be on the other. Most deployed monitoring tools do not report the two directions separately.

8 CC in User Space

QUIC moved congestion control into the application for sound reasons: the stack iterates without kernel changes and reaches clients without an OS update [22]. The cost is visibility. Each library runs its own controller, and Marx et al. found CC among the causes of behavioral divergence across more than eighteen production stacks [23]. Flows from one host no longer share ${\text{RTT}}_{\text{min}}$ or the metrics cache, and a controller that ignores ECN can be held only by injected loss, contained at best by a per-flow-fair egress [5]. The kernel’s pluggable setsockopt(TCP_CONGESTION) interface keeps that cross-flow view while still letting the operator choose the algorithm.

9 Design Principles for the Next Generation of CC

The preceding sections inventory four failure modes (§2 through §5), findings that end-to-end throughput hides (§7 and the buffer-depth sweep in §6), and a placement question (§8). Each proposed principle below is a constraint on the signal layer, and each negates a measured failure mode. We state them in the normative language of RFC

2119 [24] and RFC 8174 [25]: P1 through P6 are requirements the measured failure model imposes, and P7 is our deployment recommendation.

P1: the three per-packet decisions MUST be decoupled. A sender’s degrees of freedom on every transmission are exhausted by what segment to send, whether there is room for it, and how fast it should leave [6]. Loss-based CCs collapse all three onto CWND and delivery-rate CCs collapse two, so a perturbation in any signal touching the shared variable reaches every decision at once: one lossy packet triggers a rate cut and a window cut and an entry into recovery when only the retransmit was warranted.

P2: the pacing clock MUST have a network-independent physical anchor. On modern paths, every signal observable through the ACK stream has degraded: the delivery-rate sample is corrupted by ACK-path jitter (§7), the SRTT CUBIC paces against is inflated by queue depth (§3), and the dupACK count is corrupted by reordering. A pacing clock anchored in any of them inherits the respective degradation, so the clock MUST derive from a quantity the path cannot corrupt: egress NIC wire speed, known at setup, stable for the flow, and independent of anything downstream. Network feedback MUST modulate the effective rate only through separately bounded controls. The anchor requirement has a measurement corollary, the offload-granularity principle: any timing-derived signal a CC retains MUST be read above the quantum that TSO segmentation, GRO coalescing, and link-layer ACK schedulers impose, because below that quantum per-packet timing measures the host rather than the path. BBR’s extra_acked aggregation estimator [17], added after BBRv1 underperformed on WiFi and cellular by reading batched ACKs as missing capacity, is the one deployed acknowledgment of that quantum; it budgets extra in-flight for the quantum but leaves the rate estimate susceptible to it, where [6] reads its rate evidence as delivered volume over a span of at least eight epochs and 200 ms, above the quantum by construction, and leaves per-ACK timing to loss detection alone.

P3: slow start MUST be replaced or updated. Slow start was correct on networks with small BDP and low loss, and neither assumption holds today; the overshoot now scales with BDP and its recovery is interrupted by every path loss in CWND. The replacement MUST NOT search for capacity by doubling a window against loss: it MUST start at a deterministic, RTT-independent rate and bound the first round trip’s overshoot with a correction that lands within a few epochs, so a long-haul flow neither stalls between steps nor pays for the search with its own drops.

P4: loss classification MUST precede rate response. CUBIC’s 30% multiplicative decrease and BBR’s inflight_hi cut both answer a “loss event” defined operationally as a missing SACK gap. This conflates a tail drop that shed several packets from one burst with scatter loss from wireless interference. The separation is structural rather than statistical: scatter produces temporally dispersed gaps that rarely co-occur, congestion produces clustered gaps sharing one origin. A CC MUST classify the event before responding to it; counting concurrent aged gaps distinguishes the two where counting total gaps does not.

P5: the recovery clock MUST scale with the path. Linux’s 200 ms RTO floor (the specification’s own is a full second [2]) was chosen when a typical access RTT was a meaningful fraction of it, and it has never been revised though the underlying RTTs have moved by two orders of magnitude, so an RTO now costs more than the entire transfer time of most payloads. The recovery clock MUST derive from the measured path rather than a global constant, and the operator’s dead-link budget, set in seconds, MUST be separate from the path’s retry interval, set in milliseconds.

P6: the dependency graph MUST be acyclic. BBR’s collapse on jittery paths is a positive feedback loop closed through CWND: RTprop corruption shrinks the BDP estimate, the shrunken BDP exhausts CWND, the exhausted window starves the delivery-rate sampler, and the starved sampler collapses BtlBw. CWND sits in that loop as both an output of the rate decision and an input to the next one, and CUBIC closes the same loop through the queueing component of SRTT (§3). An estimator’s output MUST NOT reach its own input.

P7: CC SHOULD reside in the kernel. Unlike P1–P6, which constrain the signal layer, this is a deployment position, and we hold it because P1’s decoupling, P2’s anchor, P3’s start, and P6’s graph all require visibility across every flow on the host, which user-space CC forfeits, leaving the operator to accept duplicated state or enforce policy at an egress that does not trust the sender (§8). This is the most contestable principle; we state it for discussion.

The principles are stated normatively because the analysis preceding them is empirical: a CC violating one is exposed to the corresponding failure under the conditions measured here. [6] is the existence proof that the seven are jointly satisfiable; this paper argues that P1–P6 are jointly REQUIRED under the measured failure model, with P7 RECOMMENDED as the deployment that preserves their enforceability.

10 Related Work

Each thread below is read against the principles of §9, and the deployed baselines set the reference: RFC 9438 CUBIC [3] collapses all three per-packet decisions onto CWND and paces from SRTT, violating P1, P2, P3, P4, and P6; BBRv3 [4] separates the rate model but still derives it from ACK timing, probes by overshoot, and cuts uniformly on loss, violating P2, P3, P4, and P6.

Loss- and reorder-tolerance refinements. Between 2000 and 2007 a lineage attacked the spurious-loss problem from inside the window-based, ACK-clocked design: DSACK [26] let a sender detect unnecessary retransmits, Blanton and Allman [27] adapted DUPTHRESH from an EWMA of recent reordering,

and RR-TCP [28] refined the reorder-versus-loss classifier for throughput gains on the order of 10%. The whole arc operates inside the architecture §3 identifies as the structural source of the failure, which is why its most polished member still delivers single-digit percent of capacity under 5% loss: an early, partial P4 that leaves P1, P2, and P6 unaddressed.

Delay-based and hybrid CCs. Compound TCP, FAST TCP, and PCC [29] each address one or more of the modes catalogued here, the delay-based members yielding bandwidth before the queue overflows. None matched CUBIC’s or BBR’s footprint, for a structural rather than technical reason: in a mixed-CC network, a sender that yields before overflow yields to one that does not. P1’s decoupling asks for no such yielding, and every member still measures through the ACK stream (P2).

Jitter-robust CC. A recent line formalizes the noise term this paper measures. GCC filters a jitter-corrupted delay gradient through a Kalman estimator [30]; Arun et al. prove that CCAs reading fair shares out of delay signals starve under non-congestive variation [31]; FRCC bounds the resulting unfairness by encoding only the flow count in the signal [32], and CCC gates datacenter rate changes on the trustworthiness of delay-derived congestion inference [33]. Each filters, bounds, or discounts the corrupted signal; the principles here ask instead for a send clock that never ingests it (P2), the stronger invariance, and none revisits the coupled decision structure (P1). The noise term itself has a thirty-year record: Zhang, Shenker, and Clark reproduced ACK compression in two-way-traffic simulation [34], Mogul measured it on live Internet paths [35], and NIC offload engines and link-layer ACK schedulers have since made routine what cross-traffic once made occasional.

ECN-based and data-center CCs. DCTCP [36] introduced proportional CE-mark response in fabrics with universal ECN, and L4S [37] generalizes it to a two-queue public-internet deployment through DualPI2 [38] and a low-latency sender profile. That effort answers a different question, the queueing delay a low-latency flow sees on a shared bottleneck, and the modes here are independent of it: an L4S-compliant CUBIC still loses bandwidth to 5% wireless loss (P4), still overshoots slow start (P3), and still paces from SRTT (P2).

Medium-informed CC. CLAW [39] routes PHY-side metrics from the device’s diagnostic interface into an inferred CWND fed back to the sender, and against Starlink’s ~15 s handovers SatPipe [40] patches BBR with a schedule-aware Queue-Maintenance state. Each is correct on its own medium and brittle off it, needing a PHY-aware sender, privileged client access, or a CUBIC fallback when the bottleneck moves. A signal layer that gives a handover’s loss burst time to resolve before declaring it congestion (P4) reaches the same verdict endogenously and needs none of that machinery.

Edge proxies and AP-side termination. RFC 3135 [41] formalized Performance-Enhancing Proxies for links where loss-as-congestion underperforms, and WiFox [42] reported 400–700% downlink goodput gain from AP-side termination on a 45-node testbed. Those works establish the pattern any proxy-resident CC inherits; the contribution here is to the signal layer inside it, since a proxy running stock TCP inherits every failure mode above even when the topology localizes the impairment.

Surveys and measurement studies. The measurement-driven critiques nearest this paper each take one slice: the starvation analysis [31] and FRCC [32] treat inter-flow fairness under jitter, CCC [33] the trustworthiness of delay-derived inference, and Cardwell et al. [4] inventory some of the same signal-degradation arguments without reaching the conclusion of §9. What has not appeared is the cross-impairment view taken here: the historical scale inversion of ACK timing, its consequences measured across the deployed CC architectures, and the signal-layer requirements that follow. This paper consolidates operations folk knowledge into a citable analysis.

11 Conclusion

Cerf et al. specified the Transmission Control Program in 1974, and the protocol we depend on today was finalized in RFC 793 [1] seven years later. Congestion control was not part of either document; it was added in 1988, after the first congestion collapses were observed. Its signals are the ACK arrival cadence, the dupACK count, SRTT, and the binary loss event. All were robust in the era that produced them, when wide-area bottlenecks ran at kilobits per second, the fastest common LAN was 10 Mbps Ethernet [43], and a packet’s transmission time dwarfed the timing noise around it. As we have argued here, they are no longer robust today and more importantly are expected to diverge further tomorrow.

Three implications follow. First, the problem compounds with investment: because ${𝐽}_{𝑆}$ grows linearly in link rate, every infrastructure upgrade widens the shortfall between provisioned and delivered bandwidth, and the operator’s standard remedy for slowness, more bandwidth, buys progressively less of it. Second, the fix cannot come from the network: timing uncertainty has migrated out of the wire into queues, radios, hypervisors, and schedulers, so no physical-layer spend restores the signal. The network does not need to become deterministic if the congestion controller can distinguish congestion from nondeterminism, which makes the solution to reliable throughput an estimator-design problem rather than an infrastructure problem. Third, placement decides enforceability: as CC migrates into user-space stacks, the network’s only universal lever over a sender that ignores its signals reverts to injected loss, unwinding a decade of AQM work that existed to avoid exactly that.

The proposed design principles of §9 consolidate the analysis into a normative set of constraints: decoupled per-packet decisions, a hardware-anchored pacing clock, deterministic startup, structural loss classification, a path-scaled recovery clock, an acyclic dependency graph, and kernel placement. We argue that P1–P6

are jointly required under the measured failure model, with kernel placement (P7) as our deployment recommendation; [6] is the existence proof that all seven are jointly satisfiable. In September 2026 one kernel module delivered 1.5× CUBIC and BBR on a 35 ms wired ISP path, 1.3× on LTE, and 4.4× CUBIC with parity against BBR on Starlink, where CUBIC reads scatter loss as congestion; the margin is ordered by how far each medium has degraded the ACK clock, which is this paper’s claim. A second wired set three days later, on a revised startup, held the wired margin unchanged.

The contribution of this paper is the analysis rather than any specific algorithm. The network of 2026 differs from those of 1998 and 2005 in ways the standards track has not yet addressed, and the implication of that omission is the single-digit percentages of capacity that production CCs deliver at the impairment levels and path configurations measured herein. The cost stays hidden because every running CC is self-throttling. The sender cannot deliver more than the algorithm permits, and the application takes what it thinks it is allocated. Satisfying the seven principles [6] recovers that capacity for the operator’s provisioned bandwidth, the user’s completion times, and the handset’s radio budget at once.

TCP’s utility is not in question; five decades of deployment settled that. The question is whether a congestion-control layer designed in the 1980s, for links that routinely carry 10,000× the data they carried in 1988, should still be treated as settled.

12 Statement on AI Use

AI, specifically models and tools provided by Anthropic, were used to create simulation harnesses, organize data sets, and provide visuals showing results.

References

• [1] J. Postel, “Transmission Control Protocol.” RFC Editor, Sep. 1981. doi: 10.17487/RFC0793.
• [2] V. Paxson, M. Allman, J. Chu, and M. Sargent, “Computing TCP's Retransmission Timer.” RFC Editor, Jun. 2011. doi: 10.17487/RFC6298.
• [3] L. Xu, S. Ha, I. Rhee, V. Goel, and L. Eggert, “CUBIC for Fast and Long-Distance Networks.” RFC Editor, Aug. 2024. doi: 10.17487/RFC9438.
• [4] N. Cardwell, Y. Cheng, C. S. Gunn, S. H. Yeganeh, and V. Jacobson, “BBR: Congestion-Based Congestion Control,” Communications of the ACM, vol. 60, no. 2, pp. 58–66, Feb. 2017, doi: 10.1145/3009824.
• [5] D. Vadura, “Practically Fair Queueing: A Per-Flow Scheduling Discipline for Shared Internet Links,” technical report, 2026.
• [6] D. Vadura, “WarpRATE: A Rate-Paced CC Solution,” technical report, Mar. 2026.
• [7] IEEE, “IEEE Standard for Information Technology—Telecommunications and Information Exchange between Systems—Local and Metropolitan Area Networks—Specific Requirements—Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications,” no. IEEE Std 802.11-2016. 2016. doi: 10.1109/IEEESTD.2016.7786995.
• [8] S. Muhammad, J. Zhao, and H. H. Refai, “An Empirical Analysis of IEEE 802.11ax,” in 2020 International Conference on Communications, Signal Processing, and their Applications (ICCSPA), 2021, pp. 1–6. doi: 10.1109/ICCSPA49915.2021.9385748.
• [9] V. Singh, J. Ott, and S. Holmer, “Evaluating Congestion Control for Interactive Real-Time Media.” RFC Editor, Jan. 2021. doi: 10.17487/RFC8868.
• [10] F. Ronteix-Jacquet, “On Radio Access Network Uplink Latency and Jitter: Measurements and Analysis,” in ITC 33 – Networked Systems and Services, Avignon, France, Aug. 2021.
• [11] I. Johansson, “Congestion Control for 4G and 5G Access,” Internet-Draft draft-johansson-cc-for-4g-5g-02, Jul. 2016.
• [12] A. Belay, G. Prekas, A. Klimovic, S. Grossman, C. Kozyrakis, and E. Bugnion, “IX: A Protected Dataplane Operating System for High Throughput and Low Latency,” in 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI '14), 2014, pp. 49–65.
• [13] Y. Xu, Z. Musgrave, B. Noble, and M. Bailey, “Bobtail: Avoiding Long Tails in the Cloud,” in 10th USENIX Symposium on Networked Systems Design and Implementation (NSDI '13), 2013, pp. 329–341.
• [14] D. Vadura, “WarpRATE: Implementation, Deployment, and Validation on Live Networks,” technical report, 2026.
• [15] W. E. Leland, M. S. Taqqu, W. Willinger, and D. V. Wilson, “On the Self-Similar Nature of Ethernet Traffic (Extended Version),” IEEE/ACM Transactions on Networking, vol. 2, no. 1, pp. 1–15, 1994, doi: 10.1109/90.282603.
• [16] M. Duke and G. Fairhurst, “Specifying New Congestion Control Algorithms.” RFC Editor, Mar. 2025. doi: 10.17487/RFC9743.
• [17] N. Cardwell, Y. Cheng, S. H. Yeganeh, I. Swett, and V. Jacobson, “BBR Congestion Control,” Internet-Draft draft-cardwell-iccrg-bbr-congestion-control-02, Mar. 2022.
• [18] R. Kumar et al., “TCP BBR for Ultra-Low Latency Networking: Challenges, Analysis, and Solutions,” in 2019 IFIP Networking Conference (IFIP Networking), IEEE, 2019, pp. 1–9. doi: 10.23919/IFIPNetworking.2019.8816856.
• [19] J. Chu, N. Dukkipati, Y. Cheng, and M. Mathis, “Increasing TCP's Initial Window.” RFC Editor, Apr. 2013. doi: 10.17487/RFC6928.
• [20] Y. Cheng, N. Cardwell, N. Dukkipati, and P. Jha, “The RACK-TLP Loss Detection Algorithm for TCP.” RFC Editor, Feb. 2021. doi: 10.17487/RFC8985.
• [21] ESnet, “Fasterdata Knowledge Base: Host and Network Tuning for Data-Intensive Science.” 2024.
• [22] A. Langley et al., “The QUIC Transport Protocol: Design and Internet-Scale Deployment,” in Proceedings of the ACM SIGCOMM 2017 Conference (SIGCOMM '17), ACM, Aug. 2017, pp. 183–196. doi: 10.1145/3098822.3098842.
• [23] R. Marx, J. Herbots, W. Lamotte, and P. Quax, “Same Standards, Different Decisions: A Study of QUIC and HTTP/3 Implementation Diversity,” in Proceedings of the 2020 Workshop on the Evolution, Performance, and Interoperability of QUIC (EPIQ '20), ACM, Aug. 2020, pp. 14–20. doi: 10.1145/3405796.3405828.
• [24] S. Bradner, “Key Words for Use in RFCs to Indicate Requirement Levels.” RFC Editor, Mar. 1997. doi: 10.17487/RFC2119.
• [25] B. Leiba, “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words.” RFC Editor, May 2017. doi: 10.17487/RFC8174.

• [26] S. Floyd, J. Mahdavi, M. Mathis, and M. Podolsky, “An Extension to the Selective Acknowledgement (SACK) Option for TCP.” RFC Editor, Jul. 2000. doi: 10.17487/RFC2883.
• [27] E. Blanton and M. Allman, “On Making TCP More Robust to Packet Reordering,” ACM SIGCOMM Computer Communication Review, vol. 32, no. 1, pp. 20–30, Jan. 2002, doi: 10.1145/510726.510728.
• [28] M. Zhang, B. Karp, S. Floyd, and L. Peterson, “RR-TCP: A Reordering-Robust TCP with DSACK,” in Proceedings of the 11th IEEE International Conference on Network Protocols (ICNP '03), IEEE, Nov. 2003, pp. 95–106. doi: 10.1109/ICNP.2003.1249760.
• [29] M. Dong, Q. Li, D. Zarchy, P. B. Godfrey, and M. Schapira, “PCC: Re-architecting Congestion Control for Consistent High Performance,” in 12th USENIX Symposium on Networked Systems Design and Implementation (NSDI '15), USENIX Association, May 2015, pp. 395–408.
• [30] G. Carlucci, L. De Cicco, S. Holmer, and S. Mascolo, “Analysis and Design of the Google Congestion Control for Web Real-Time Communication (WebRTC),” in Proceedings of the 7th International Conference on Multimedia Systems (MMSys '16), 2016. doi: 10.1145/2910017.2910605.
• [31] V. Arun, M. Alizadeh, and H. Balakrishnan, “Starvation in End-to-End Congestion Control,” in Proceedings of the ACM SIGCOMM 2022 Conference, 2022, pp. 177–192.
• [32] A. Agarwal, V. Arun, and S. Seshan, “FRCC: Towards Provably Fair and Robust Congestion Control,” in 23rd USENIX Symposium on Networked Systems Design and Implementation (NSDI '26), 2026.
• [33] W. Jiang, H. Li, K. Wang, Y. Hu, and X. Han, “CCC: Re-architecting Delay-based Congestion Control in Datacenter Networks,” in 23rd USENIX Symposium on Networked Systems Design and Implementation (NSDI '26), 2026.
• [34] L. Zhang, S. Shenker, and D. D. Clark, “Observations on the Dynamics of a Congestion Control Algorithm: The Effects of Two-Way Traffic,” in Proceedings of the ACM SIGCOMM 1991 Conference (SIGCOMM '91), ACM, Sep. 1991, pp. 133–147. doi: 10.1145/115992.116006.
• [35] J. C. Mogul, “Observing TCP Dynamics in Real Networks,” in Proceedings of the ACM SIGCOMM 1992 Conference (SIGCOMM '92), ACM, Aug. 1992, pp. 305–317. doi: 10.1145/144179.144419.
• [36] M. Alizadeh et al., “Data Center TCP (DCTCP),” in Proceedings of the ACM SIGCOMM 2010 Conference (SIGCOMM '10), ACM, Aug. 2010, pp. 63–74. doi: 10.1145/1851182.1851192.
• [37] B. Briscoe, K. De Schepper, M. Bagnulo, and G. White, “Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture,” RFC 9330, 2023.
• [38] K. De Schepper, B. Briscoe, and G. White, “Dual-Queue Coupled Active Queue Management (AQM) for Low Latency, Low Loss, and Scalable Throughput (L4S),” RFC 9332, 2023.
• [39] X. Xie, X. Zhang, and S. Zhu, “Accelerating Mobile Web Loading Using Cellular Link Information,” in Proceedings of the 15th Annual International Conference on Mobile Systems, Applications, and Services (MobiSys '17), Niagara Falls, NY, USA: ACM, Jun. 2017, pp. 427–439. doi: 10.1145/3081333.3081367.
• [40] D. Zhao, X. Zhang, and M. Lee, “SatPipe: Deterministic TCP Adaptation for Highly Dynamic LEO Satellite Networks,” in IEEE INFOCOM 2025 – IEEE Conference on Computer Communications, IEEE, 2025.
• [41] J. Border, M. Kojo, J. Griner, G. Montenegro, and Z. Shelby, “Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations.” RFC Editor, Jun. 2001. doi: 10.17487/RFC3135.
• [42] A. Gupta, J. Min, and I. Rhee, “WiFox: Scaling WiFi Performance for Large Audience Environments,” in Proceedings of the 8th International Conference on Emerging Networking Experiments and Technologies (CoNEXT '12), ACM, Dec. 2012, pp. 217–228. doi: 10.1145/2413176.2413202.
• [43] J. F. Shoch and J. A. Hupp, “Measured Performance of an Ethernet Local Network,” Communications of the ACM, vol. 23, no. 12, pp. 711–721, Dec. 1980, doi: 10.1145/359038.359044.