TCP Congestion Control for a 10G World
Throughput Collapse Is a Control Problem, Not a Capacity Problem
August 2026
Abstract
By 2030, 10 Gbps ports will be standard at the network edge. However, TCP data flows may not always take advantage of the higher port rate. A congestion-control (CC) algorithm on the sender decides, subject to network conditions and device limits, how much of that rate an individual flow experiences. The algorithm decides the rate using the timing of returning ACKs, and that signal is often drowned out by network jitter. At 10 Gbps a NIC serializes a 1500 byte MTU packet in 1.2 µs. In contrast, timing noise from WiFi contention, cellular scheduling, and virtualization typically spans hundreds of microseconds to tens of milliseconds. The resulting throughput shortfall is a control problem that an increase in the network’s raw data rate does not fix. In fact, it makes it worse; a clean 10 Gbps port running under a typical network stack frequently delivers an eighth of its capacity. The shortfall impacts return on capital, handset battery life, and subscriber retention through reduced customer satisfaction. We summarize four companion papers describing an improved architecture built on three principles: the sender controls are decoupled and anchored to the NIC’s capability, fairness is made structural at port egress, and no controller output re-enters its measurement path. The outlined architecture is deployed in production as a kernel congestion control module and a queueing discipline. On live paths it delivers 1.3× to 2.5× the goodput of deployed CC algorithms, and 4.4× to 40x for CUBIC flows over satellite. The improvements in data delivery don’t just provide better application performance; they also improve battery life through reduced radio on-time and, we propose, will reduce mobile operator churn via higher customer satisfaction rates.
1 Introduction
Ten-gigabit connectivity is leaving the data center. The ITU’s 2030 broadband roadmap is built on 10 Gbps optical access [1], sized for the demands that 6G places on the access network. Silicon has followed: mass-market home-gateway chips now ship with 10G interfaces built in [2], WiFi 7 access points carry 10GBASE-T uplinks, servers commonly attach at 10 Gbps or faster, and data-center ports have moved past 100 Gbps. By 2030 we expect a 10 Gbps port to be the unremarkable default at the network edge. At that speed a 1500-byte packet serializes in 1.2 µs.
A port has a maximum transmit rate; however, a flow does not intrinsically inherit it. For a network-limited TCP or QUIC transfer, port capacity sets the ceiling while a congestion-control (CC) algorithm on the sender decides, round trip by round trip, how much of that ceiling the flow occupies, and no new hardware purchase changes the algorithm. In calibrated simulation of a 1 Gbps path with the 5% loss that wireless last-acres routinely produce, deployed CCs deliver 28 to 83 Mbps [3], and even a perfectly clean 10 Gbps port delivers only a fraction of itself (Section 3). Raising the port rate widens the gap between port and effective flow rates.
The algorithm those ports inherit was fixed in 1988, after the Internet’s congestion collapses [4], in an era whose wide-area bottlenecks ran at kilobits per second and whose fastest common LAN was 10 Mbps Ethernet: packet-transmission times were enormous relative to the timing noise around them, and Jacobson’s self-clocking design leaned on exactly that, assuming the spacing of returning ACKs preserves the bottleneck’s packet spacing [4]. The arithmetic has been refined many times since: CUBIC reshaped the window growth curve [5], and BBR paces at an explicitly modeled rate [6]. The signal architecture, however, is unchanged: the sender derives its rate from the arrival timing of ACKs, treats loss as evidence of congestion, and falls back to a retransmission timeout [7] whose deployed Linux floor is 200 ms [8]. Every one of those inputs was trustworthy on the paths that shaped them. None of them holds uniformly on the paths of 2030.
| What changed | Why the old control fails | Architectural response |
|---|---|---|
| Serialization fell a thousandfold; dominant jitter sources did not scale with it | ACK timing loses signal-to-noise | Pacing anchored to the NIC, not to ACK arrivals |
| Wireless produces scatter loss | Loss no longer implies congestion | Classify the loss before any rate response |
| The sender’s queue inflates its RTT | The measurement contains the controller’s output | Acyclic estimator dependencies |
| Mixed CCs compete under different laws | Fairness is emergent, not guaranteed | Structural per-flow scheduling at the egress |
| Interactions obscure cause | Goodput alone cannot attribute behavior | Deterministic, state-visible validation |
This paper takes a position: the throughput shortfall on modern paths is a control problem, not a capacity problem, and the remedy is architectural rather than parametric. We do not claim that deployed congestion control is wrong; we claim that the assumptions that originally justified ACK-clocked control have progressively weakened as networks evolved, that the sources of the noise sit in radios, schedulers, and hypervisors no transport operator controls, and that the fix therefore has to live in the controller’s estimators.
The argument herein synthesizes four studies developed together: the impairment analysis [3], the WarpRATE congestion controller [9], the PFQD queueing discipline [10], and the WarpSIM simulator that validates both [11]. The architecture is deployed: WarpRATE runs as a kernel module and PFQD as a host qdisc, operated together over production networks including a LEO satellite path (Section 7.3). Table 1 summarizes the need, and the remaining sections expand on its rows with Section 4 estimating the cost, in handset battery life and subscriber retention, of a 10 Gbps network upgrade.
2 Five Control Assumptions That No Longer Hold
Window-based congestion control rests on five original assumptions that were valid when the original architecture was designed. For each we state its role, the part it plays in setting a flow’s rate; what changed on the modern path; and the evidence, the measurement that shows it [3].
2.1 Assumption 1: ACK spacing reflects the bottleneck
Role. Deployed controllers depend on ACK timing: a window-based sender’s rate is implied by CWND over an RTT measured from ACKs, and a model-based sender samples its delivery rate from the same arrivals. The ACK stream is the clock the rate decision runs on.
What changed. Serialization time is set by NIC hardware; jitter is set by contention, scheduling, and preemption mechanisms that hardware upgrades leave untouched. For a 1500-byte packet, serialization has fallen three orders of magnitude, from 1,200 µs at 10 Mbps to 1.2 µs at 10 Gbps, while representative contention and scheduling jitter stays in a 100–500 µs band the hardware upgrades do not move (Figure 1). A clock is useful only while its tick is coarse compared to the noise around it, and Figure 1 shows the tick shrinking a thousandfold while the noise stays where it was.
Evidence. Figure 2 turns the comparison into a single number, the jitter–serialization ratio : jitter divided by the time to put one packet on the wire. Read it as how many packets’ worth of sending time the timing noise obscures. The relationship is arithmetic: a packet of size on a link of rate serializes in , so , and any jitter mechanism whose timescale does not fall inversely with link rate makes the ratio grow in proportion to link rate. is a scale-separation reference point rather than a formal failure boundary: below it the timing noise is smaller than one packet time, and above it a single excursion spans many packets’ worth of the information the sender is trying to read. At 10 Mbps the wire’s timescale still dominates all but the noisiest source; by 10 Gbps every source has crossed the line, with cellular scheduling being near 1,700 under deliberately conservative assumptions [12], WiFi contention is near 400, and OS and hypervisor preemption in the tens. Capacity does not help because an upgrade shrinks the denominator and leaves the numerator alone, so every generation of faster network hardware makes the ACK stream a less accurate clock.
2.2 Assumption 2: RTT measures the path
Role. The measured round trip converts a time window into a rate and sizes every bandwidth-delay estimate the controller keeps; it is a measured property of the path.
What changed. The observed round trip decomposes as : the sum of fixed propagation delay , any queueing delay that carries the congestion information , and the non-congestive timing variation of Section 2.1. The controller observes only the sum. Worse, is largely the result of the sender’s previous rate decisions. A controller that derives its rate as CWND/SRTT feeds its output back into its input: as the window grows under its avoidance law, the added in-flight data deepens the bottleneck queue, and the inflated RTT feeds back into the derived rate. The coupling ends only when the buffer overflows, which is bufferbloat in its self-reinforcing form.
Evidence. Kumar et al. measured the modern form on millimeter-wave paths: jitter depresses BBR’s windowed-minimum RTprop, the shrunken estimate exhausts the window, the starved sampler collapses the bandwidth model, and throughput collapses on a healthy link [13]. Vegas broke the self-feedback loop first [14]; it was correct in isolation but lost to loss-based competitors at shared bottlenecks (Section 5.2).
2.3 Assumption 3: loss means congestion
Role. Loss is how the architecture slows down: CUBIC’s 30% multiplicative decrease and BBRv3’s
inflight_hi cut are the mechanisms by which a flow yields capacity, and both fire on a
“loss event” regardless of its cause.
What changed. Wireless last-acres produce 1–5% packet loss from interference and scheduling, with handovers spiking loss by an order of magnitude [15]; none of it says anything about queue depth. A rate cut triggered by such loss slows the flow for no reason, and on impaired wireless paths it happens routinely.
Evidence. The distinction that matters is structural rather than statistical: scatter loss produces temporally dispersed gaps that rarely co-occur, while congestion-induced drops cluster at a specific queue and age together. Counting concurrent aged gaps separates the two; counting total gaps does not [9]. Section 3 measures what misreading scatter as congestion costs.
2.4 Assumption 4: both path directions behave alike
Role. The controller reads one path-quality signal for the whole connection, yet its feedback channel (the ACK return path) and its payload channel (the data path) are distinct transits that behave independently.
What changed. Impairments on the two directions have sharply different consequences, and path-aggregate metrics hide the difference. Table 2 shows the loss half: five percent
| Algorithm | Data-path loss | ACK-path loss | Both |
|---|---|---|---|
| WarpRATE | 618 | 745 | 574 |
| BBR | 426 | 633 | 210 |
| CUBIC | 22 | 648 | 2.7 |
| Algorithm | Data-path jitter | ACK-path jitter | Both |
|---|---|---|---|
| WarpRATE | 127 | 159 | 115 |
| BBR | 31 | 30 | 24 |
| CUBIC | 6 | 5 | 4 |
| CC | 1× BDP queue | 4× BDP queue | Change |
|---|---|---|---|
| WarpRATE | 903.1 | 903.1 | 0% |
| CUBIC | 882.8 | 882.8 | 0% |
| BBR | 861.4 | 878.7 | +2% |
loss on the ACK path is cheap, because the next cumulative ACK covers each unreported delivery in the aggregate. Under ACK-path loss the three measured controllers hold 633 to 745 Mbps, while the same loss on the data path collapses CUBIC to 22 Mbps and roughly halves BBR, and loss in both directions halves BBR again [3].
Evidence. Table 3 shows the opposite for jitter: CUBIC and BBR, which lost little to ACK-path loss, deliver 5 and 30 Mbps under 10 ms of ACK-path jitter, because jittered ACKs corrupt every timing-derived estimator the sender operates.
2.5 Assumption 5: deeper buffers improve throughput
Role. Buffer sizing is the operator’s traditional remedy for transport misbehavior: a deep enough queue was assumed to absorb whatever the probe overshoots.
What changed. Measured across controllers, buffer depth no longer matters to throughput (Table 4). Deepening a bottleneck queue from 1× to 4× BDP on a clean 1 Gbps path moves no controller by more than 2%: CUBIC’s HyStart exits slow start before the initial burst can overfill even the shallow queue, BBR’s STARTUP overshoot gains 2%, and a controller whose probe is bounded by hardware does not move at all.
Evidence. In Table 4 a four-times deeper queue changes no controller’s goodput by more than 2%.
The failures compound: the sweeps in [3] show each failure mode in isolation and a larger loss in combination. The rest of this paper addresses them together.
3 Why Capacity Does Not Fix It
In a network upgrade the port is the engine and congestion control is the transmission.
A half-million-dollar engine does not set a land speed record through a transmission that tops out at 100 mph. This section is about the transmission.
When throughput disappoints, the standing remedy is to buy capacity; three measured facts say the control layer is what sets delivered throughput.
The shortfall exists on perfectly clean paths. On a 10 Gbps, 25 ms path with no loss and no jitter, deployed CCs plateau near 1,300 Mbps [3]. The proximate cause is the kernel’s default socket sizing: a sender may hold at most the minimum of its congestion window, the receiver’s advertised window, and its send buffer, and the constraint is the tested kernel’s default 4 MB autotuned send-buffer ceiling against a 32 MB bandwidth-delay product. 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. The ceiling is well known to the operators who hit it: ESnet’s data-transfer tuning guides exist to raise these defaults, prescribing buffer maxima in the hundreds of megabytes for high-BDP science paths [16]. A sender that structurally cannot populate the path gains nothing from an additional gigabit. Further experimental results show that the losses increase as the data rate increases, with the same 1.3 Gbps plateau on a 2.5 Gbps port and on a 10 Gbps port (Section 7.1). The ceiling is absolute, not proportional, and is insidious because each new hardware generation delivers a smaller fraction of itself. The shortfall grows as the spending grows.
The failure costs scale with capacity. Slow start finds capacity by exceeding it, and the overshoot cost is proportional to BDP: about 125 KB of spilled data on a 2005-era 10 Mbps, 100 ms path, 3.75 MB at 1 Gbps and 30 ms, and 31 MB at 10 Gbps and 25 ms [3]. The recovery clock scales the same way: one RTO at Linux’s 200 ms floor [8] forgoes 250 KB at 10 Mbps and 250 MB at 10 Gbps, and it still resets the window to one segment. Neither mechanism changed; everything around them scaled up. A capacity upgrade therefore makes each control failure more expensive in absolute terms, which is the opposite of the outcome the upgrade was purchased for.
The upgrade degrades the signal itself. The jitter–serialization ratio of Section 2.1 grows with every generation of interconnect, so each hardware step makes ACK timing a noisier rate signal; the formal statement is in [3]. It also affects operational practice: upgrading only the backhaul behind an LTE eNodeB worsens at the handset and measurably degrades TCP, because the serialization component of the timing signal shrinks while the radio’s scheduling jitter stays put [3]. Loss-driven collapse is equally indifferent to provisioning: the 80 to 88% single-step drop at 0.5% loss, and CUBIC’s 4.2 Mbps at 10% loss, are set by the multiplicative-decrease arithmetic, and they arrive at nearly the same absolute figures whether the port beneath them is 1 Gbps or 10 Gbps.
What is instructive is that four decades of refinement have not really addressed the issue. The reason is that every refinement has stayed inside the signal architecture. Reno to NewReno to CUBIC reshaped the window arithmetic [5]; BBR remodeled the estimator [6]; a 2000s lineage retuned the loss-versus-reorder classifier; all of them still derive rate from ACK timing.
Active queue management acts from the network side and meets the same wall: it conditions the queue-derived signal presented to the endpoint, but it cannot remove timing corruption that arises elsewhere on the path and cannot repair a rate estimate corrupted upstream of the queue [17]. L4S adds a second control loop at the router whose marking is coupled to assumptions about the endpoint’s response [18] [19]; Section 7.2 discusses what happens when those assumptions and the traffic disagree.
The Refinements keep coming and the shortfall keeps growing because both approaches refine the processing of a signal that is itself degrading. The queue’s influence is meanwhile shrinking: as congestion control migrates into user-space QUIC stacks, an endpoint that ignores marking leaves injected loss as the network’s only remaining control, unwinding a decade of AQM work [3].
The sources of the noise are not fixable from the transport layer either: the schedulers, radios, and hypervisors that produce it belong to other operators and other stacks, and no transport deployment at the source reaches them. What remains reachable is the controller’s estimator. The fix is therefore insensitivity: classify a loss before responding to it, and respond to genuine queue growth while ignoring timing noise that carries no congestion information.
The conclusion we draw is that the shortfall between provisioned and delivered throughput is a property of the control law, and that closing it requires changing where control decisions get their signals and how they respond. Adding capacity does not do that, and neither does another estimator on top of the same degraded inputs. The network does not need to become deterministic if the congestion controller can distinguish congestion from nondeterminism.
4 The Business Case for Control First
A correct diagnosis is worth money. Three lines of reasoning, each anchored to measurement, say why an operator should understand it before signing up to procure the next hardware cycle.
Capital return. A port upgrade is priced on capacity, but what subscribers receive is delivered throughput, and Section 3 argues the divergence is structural: the control ceiling is absolute, so each generation delivers a smaller fraction of itself. A transmit slot that goes unused is not banked; it is unrecoverable [10]. Capacity planning that ignores the control layer therefore overstates the financial return.
Handset energy. Throughput shortfalls lengthen radio on-time, and the radio dominates device energy during transfer: measurement
on an operational 5G handset attributes 55% of total device energy to the 5G module, which is more than the display [20]. The RRC state machine compounds the effect: the radio holds its high-power state for the transfer plus an inactivity tail that has been measured at up to 80% of total radio energy [21] and persists on 5G [22]. With smartphone data consumption at 22 GB per month and forecast to nearly double by 2031 [23], every avoidable minute of transfer time is an avoidable minute of peak radio drain: field measurements on a production LTE-A network recorded 20 to 30% better handset battery life when data delivery speed doubled [9].
Subscriber retention. Battery is the lowest-scored attribute of any smartphone feature in the ACSI 2025 index at 77 of 100, 38% of mobile users cite battery life as their leading device complaint, 31% would switch operators over unresolved device issues, and network quality ranks second only to price as a churn driver [24]. Transport throughput touches both of the top non-price attributes correlated with churn: it is perceived network quality, and through radio on-time it translates directly to battery-life. A control-layer fix that increases data throughput and improves battery life lands directly on the two metrics an operator’s retention model already depends on.
5 A Separation of Transport Responsibilities
Modern transport problems are partly caused by responsibilities that have become coupled to noisy signals, circular feedback loops, and overlapping control mechanisms. The remedy is to separate those responsibilities, give each one a clear signal source and its control variable, and make the resulting behavior directly observable and reproducible. The argument is about system boundaries rather than any particular heuristic, and it divides the transport stack into the four layers of Figure 3: a diagnosis of which signals still carry information (Section 2), sender-side control, network-side scheduling, and a validation layer. Table 5 summarizes who owns what. In its third column every row places a decision next to the one signal that can still be trusted for it, and any alternative decomposition should meet the same test.
| Responsibility | Location | Architectural intent |
|---|---|---|
| Segment selection, recovery | Sender | Repair data without redefining the send rate |
| Pacing | Sender | A send clock not driven by ACK arrivals |
| In-flight volume | Sender | Bound outstanding data independently |
| Per-flow fairness | Egress scheduler | A structural guarantee, not an emergent one |
| Congestion signaling | Queueing discipline | Signal the flow whose queue is growing |
| Rate enforcement | Queueing discipline | A rate cap as a departure-time constraint |
| Experiment control | Simulator | Every decision reproducible and observable |
5.1 Sender: three decisions, three controls
A sender’s per-packet degrees of freedom1 are exhausted by three questions: what segment to send, whether there is room to send it, and how fast it should leave. Loss-based CCs collapse all three onto one variable: CWND simultaneously sets the rate, caps volume in flight, and shrinks on every loss. A perturbation in any signal reaches every decision at once. One spuriously detected loss triggers a rate cut, a window cut, and recovery entry when only a retransmission was warranted.
WarpRATE [9] is the existence proof that the three decisions can be separated while retaining high utilization in real world settings. Its send clock is bounded by the egress NIC’s wire speed, a physical quantity known at connection setup that no downstream impairment can corrupt, and is moved by a rate law whose only inputs are delivered volume, loss marks, CE echoes, and the RTT ratio. When a queue is present its in-flight bound is twice the proven rate times , which severs the queue-RTT feedback of Section 2.2 because the minimum tracks propagation rather than the queue. Loss detection absorbs path noise in a jitter-scaled SACK derived aging interval. Jitter, in effect, widens the sender’s patience instead of perturbing its rate. Startup begins from a seed rather than a slow-start search: the pace starts at a fixed rate bounded by the NIC, and the rate law runs from the close of the first epoch2. Recovery uses a single timer scaled to the path’s measured RTT rather than to a fixed floor, and dead-link detection is a separate wall-clock budget.
5.2 Network: scheduling instead of control
Egress paths have accumulated overlapping mechanisms, each with its state and failure modes: a queueing discipline, an AQM, a DiffServ classifier, and a rate policer. PFQD [10] consolidates them into one per-flow scheduler. Every egress port is an N-writer, single-consumer resource, which is exactly the model for which equal-weight processor sharing is the idealized target. Simultaneously max-min fair, work-conserving, and starvation-free; PFQD approximates ideal processor sharing with per-flow round-robin using two priority tiers for short flows and control packets, plus a demotion tier that keeps continuously backlogged elephants from taxing the short flows.
Congestion signaling is per-flow: a flow whose queue exceeds a threshold gets CE-marked at dequeue. A rate cap is specified as a per-flow minimum inter-packet departure time. The new qdisc implements scheduling, per-flow signaling, and pacing inheritance, with policing provided for routers. The scheduler needs no knowledge of any endpoint algorithm: CUBIC, BBR, WarpRATE, and unresponsive UDP each get equal dequeue turns, and each is isolated in its queue. That ignorance is the boundary the design defends. The sender decides how to adapt; the network decides only whose packet leaves next. The whole discipline reduces to a handful of independently meaningful parameters, and its per-flow state is small enough for fixed-function ASICs.
5.3 Validation: determinism and observability
An architecture built around decoupled controls has to be validated at the level of those controls, because aggregate goodput cannot reveal whether a gain came from the intended mechanism, an accidental interaction, or a simulator artifact. WarpSIM [11] is a pure discrete-event simulator whose time base is integer picoseconds and whose runs are a pure function of a JSON topology and one RNG seed, so traces reproduce byte-for-byte across machines: an algorithm change is attributable to the code rather than the environment, and regressions are detectable before shipping. Its CC harness mirrors the kernel’s congestion control interface, and every hook is also a logging point, so each run yields a per-flow time series of every signal the algorithm consumed and every decision it made. Fidelity is accomplished via calibration: impairment models are deduced from live captures, and every implemented controller must reproduce a live or published anchor before results from it are trusted; Section 7.1 quantifies the match.
6 Acyclic Control as a Design Principle
One principle recurs across all three implementation layers, and we believe it is the durable idea in the program:
A controller’s output must not re-enter its own measurement path through an uncontrolled network transformation.
Every sound engineer knows this rule in another form: keep the microphone away from the speaker, because a system that hears its own output howls. A congestion window driven by ACK timing is a microphone in front of its own speaker; the window inflates the queue, the queue inflates the measured RTT, and the inflated RTT sets the next window.
The principle needs a precise boundary, because congestion control is inherently a feedback system: sender output shapes network state, and network feedback shapes the sender. Treat the network as an external plant, and enumerate the controller’s internal estimators and control variables. What the principle discourages is an unguarded internal cycle: an estimator whose output changes the conditions from which that same estimator is refreshed. In our model, the dependency graph among internal variables must be acyclic.
Deployed transport violates this in several places at once. BBR’s documented collapse on mmWave links is a single loop traversed repeatedly: jitter depresses the RTprop estimate, the modeled BDP shrinks, the congestion window exhausts, delivered rate falls, and the falling delivery rate drags the bottleneck-bandwidth filter down with it [13].
CWND is simultaneously an output of the rate decision and an input to the next one. CUBIC closes the same loop through the queueing component of SRTT (Section 2.2). The deployed 200 ms recovery floor puts the sender in a loop with its own recovery clock and each backoff further starves the ACK stream that would have ended the backoff. At the network layer, an AQM whose marks provoke endpoint responses that change the very signal driving the marker repeats the same topology one hop removed. Each element of Section 5 can be read as breaking one of these cycles by design.
7 Evidence
A deterministic simulator made the solution possible: it reproduces each failure exactly, so every candidate fix can be tested against it. Three classes of evidence support the position: calibrated simulation, formal scheduling properties, and live-path measurement. Together they show that the failures of Section 2 can be fixed by an implementation that exists and runs on production networks.
7.1 Calibrated simulation
All simulation results come from WarpSIM under the calibration discipline of Section 5.3: impairment models deduced from live captures, controllers implemented from their specifications, and each required to reproduce a live or published reference goodput across anchors spanning 50 Mbps to 10 Gbps and 2 to 230 ms of RTT [11]. Table 6 collects the headline comparisons; the per-axis sweeps behind them are in [3] and [9].
Two points follow from Table 6. First, the failures it records are architectural, not parametric. Second, one unchanged control loop spans the entire envelope: the same WarpRATE configuration delivers 651 Mbps at 10% random
| Scenario | CUBIC | BBRv3 | WarpRATE |
|---|---|---|---|
| Clean 1 Gbps, 2 ms | 883 | 879 | 903 |
| 5% data-path loss, 1 Gbps | 22 | 426 | 618 |
| ACK-path jitter σ = 10 ms, 1% loss | 5 | 30 | 159 |
| Clean 10 Gbps, 25 ms, 1 GB | 1,298 | 1,264 | 7,190 |
loss where CUBIC delivers 3.0, degrades gracefully across 2 to 200 ms of RTT where the deployed CCs fall to 41 Mbps, and reaches 72% of a 10 Gbps port. That span is evidence that the decomposition, rather than a per-regime tuning, is the right approach. Across the full scenario sweeps the deployed CCs win a brief bandwidth throttle by roughly 5% and a handful of short-RTT loss cells by under 6%; every other row goes the other way [9].
The 10 Gbps row needs an explanation, since WarpRATE avoids the limit that caps the others. Every sender ran against the same receiver, whose autotuned window was sufficient; of the three terms that bound in-flight data, the congestion window, the advertised window, and the send buffer, the one binding the deployed CCs is the tested kernel’s default 4 MB autotuned send-buffer ceiling, which their machinery accepts as given.
WarpRATE instead sizes the same term from the rate-delay product of its own pace and requests a send buffer to match ([25]). A reviewer may object that WarpRATE was permitted to change a host resource limit the others were not; that is the architectural point. The row demonstrates a transport-stack limitation, not a congestion-algorithm one: WarpRATE treats BDP-dependent in-flight capacity as part of transport control, where the deployed stacks accept a memory-policy default unrelated to the path’s BDP. WarpRATE will degrade gracefully should the requested send-buffer capacity be unavailable but when it is, it delivers the best end-user experience.
7.2 Scheduling fairness as a structural property
The PFQD evaluation ran six CC pairings over CUBIC, BBR, and WarpRATE across a 25-point bandwidth–RTT grid (12 Mbps to 1 Gbps, 5 to 100 ms), ten seeds per point, for 4,500 trials against DualPI2 and FQ-CoDel at their specification defaults [10].
PFQD kept competing flows fair at 138 of 150 pairing-points while holding the link well utilized, gave identical flows identical shares, and did so without dropping a single packet. The comparison disciplines fall short in ways their own control loops predict. DualPI2 rewards endpoints that ignores CE marks, while FQ-CoDel reaches fairness by dropping packets and gives up utilization as a result. PFQD’s fairness comes from the scheduler rather than from endpoint cooperation. Work conservation, starvation freedom, deterministic worst-case delay bounds, and max-min convergence are each detailed in [10] reports the per-pairing results.
7.3 Live paths
Several production nodes were used to run back-to-back 240 MB downloads with WarpRATE, CUBIC, and BBR from the same server through a host-mode PFQD egress on three media, measuring the effective rate the client saw [9]. On a 35 ms wired ISP path (25 flows) WarpRATE delivered 1.5× the goodput of either stock CC, finishing 240 MB in 3.2 s against 4.4; on an 80 ms LTE cell (9 flows) 1.27×; on Starlink (10 flows) 4.4× CUBIC and parity with BBR. Where impairments to the ACK clock were minimal the algorightms most faired well, where impairments became significant WarpRATE maintains throughput above the others.
8 Deployment
An architecture that works only when every component ships at once is difficult to deploy. WarpRATE can be deployed in the data center at the host or in WarpEngine proxies at the data center edge. Similarly, WarpEngine proxies deployed at the telecom edge between core networks and subscriber networks, the last acres, yeilds maximum benefit since it reduces the bandwidth delay product such that buffer constraints do not apply.
PFQD can be equally valuable as a host egress qdisc and as a datacenter edge or TOR router. The two technologies are complementary and can be deployed at different times. The primary concern should be where in the network topology should the focus be first. Since congestion usually lives at subscriber-facing access ports whose moderate speeds and flow counts sit squarely in the region where the incumbent disciplines yield unstable and variable results, the edge is the proper initial deployment target.
An access operator who controls neither endpoint deploys WarpRATE inside a split-connection proxy at the wireless or shared backbone boundary. Simulated results show signinficant benefit (up to 40x) that no other solution reports. The proxy topology has two decades of precedent [26] and our 2019 field deployments of a CUBIC-based predecessor [9]; what changes under this architecture is the controller inside the proxy, which no longer inherits TCP’s failure modes.
9 Related Architectural Viewpoints
The work this paper synthesizes is closer in ambition to research that changed viewpoints than to incremental controller design. Congestion avoidance itself was an architectural correction imposed after collapse [4], and its central instrument, the ACK clock, is the assumption whose failure we document. Fair queueing established that per-flow scheduling could deliver isolation the endpoints cannot [27], and deficit round-robin made it cheap [28]; PFQD is a return to that line with the added position that the scheduler should also absorb the signaling and policing roles that accreted elsewhere. The AQM tradition from RED through CoDel and FQ-CoDel [29] [17] [30], and its current form in L4S and DualPI2 [18] [19], instead
accepts endpoint control loops as given and conditions the signals they see; that is the architectural fork measured in Section 7.2.
On the sender side, Vegas, PCC, and Copa each replaced the primary congestion signal while retaining ACK-derived measurement [14] [31] [32], and BBR moved to model-based pacing while feeding its estimators from the same degrading timing stream [6].
The newest work engages the noise directly: FRCC provably bounds the unfairness that jitter induces in delay-reading CCAs [33], and CCC gates rate changes on the trustworthiness of delay-derived congestion inference in datacenters [34]. Both support the premise and address one symptom each.
WarpRATE differs from all of these in what it refuses to couple rather than in which signal it prefers. QUIC relocated the entire control loop to user space [35], and the measured divergence across its implementations [36] is in our opinion evidence for, not against, keeping transport control where cross-flow state is visible.
10 Conclusion
By 2030 a 10 Gbps edge port will be unremarkable, and on that port a packet serializes in 1.2 µs while the timing noise around it still spans hundreds of microseconds to tens of milliseconds. ACK-clocked congestion control was justified by five assumptions that no longer hold uniformly. They weakened gradually enough that the industry’s response has been to buy capacity, and the measurements collected here show why that response cannot close the shortfall: the dominant failure costs increase with link speed while the signal quality degrades accordingly. Throughput collapse on modern paths is thus a control problem.
This paper argued how each assumption fails on modern paths, showed a shortfall that added capacity cannot close, priced the fix in capital return, handset energy, and retention, and presented an architecture backed by simulation, formal properties, and live deployment. We showed an existence proof in the form of WarpRATE and PFQD that a solution is within reach and exists and performs on live production networks.
A further prospect follows from the same architecture, though it has yet to be measured at scale. Today’s senders are not only victims of timing noise but sources of it: probe bursts, queue oscillation, and drop-driven retransmission from every flow become part of the jitter every other flow must filter. A sender paced smoothly from a hardware clock and an egress that resolves contention without drops should inject less of it. Fully deployed, the architecture could lower the network’s self-generated jitter and improve the timing environment every sender on the path experiences, including the legacy ones.
The idea we most want to carry forward is the acyclic-control principle: no controller output should re-enter its own measurement path through a transformation it does not control. Violating it is the root cause of the failures discussed herein. The future 10 Gbps networks depend on a new CC control approach that accepts jitter and operates using a control law that rides above the noise.
11 Statement on AI Use
AI, specifically models and tools provided by Anthropic, and OpenAI were used to create simulation harnesses, organize data sets, provide visuals showing results, and review drafts.
References
- [1] ITU-T Study Group 15, “Technical Report on International Optical Networks towards 2030 and Beyond (GSTR-ION-2030),” technical report, Oct. 2025.
- [2] Broadcom Inc., “Broadcom Accelerates Multi-Gig Broadband with Optimized 10G PON and Wi-Fi~8 Solutions for Mass Market.” Apr. 2026.
- [3] D. Vadura, “The ACK Stream No Longer Keeps Time: Jitter and the Erosion of TCP's Congestion Signal,” technical report, Mar. 2026.
- [4] V. Jacobson, “Congestion Avoidance and Control,” in Proceedings of the ACM SIGCOMM 1988 Conference, 1988, pp. 314–329. doi: 10.1145/52324.52356.
- [5] 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.
- [6] 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.
- [7] V. Paxson, M. Allman, J. Chu, and M. Sargent, “Computing TCP's Retransmission Timer.” RFC Editor, Jun. 2011. doi: 10.17487/RFC6298.
- [8] Linux Kernel Community, “TCP_RTO_MIN.” 2026.
- [9] D. Vadura, “WarpRATE: A Rate-Paced CC Solution,” technical report, Mar. 2026.
- [10] D. Vadura, “Practically Fair Queueing: A Per-Flow Scheduling Discipline for Shared Internet Links,” technical report, 2026.
- [11] D. Vadura, “WarpSIM: A Picosecond-Fidelity Discrete-Event Simulator for Modern Congestion Control,” technical report, Mar. 2026.
- [12] 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.
- [13] 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.
- [14] L. S. Brakmo and L. L. Peterson, “TCP Vegas: End to End Congestion Avoidance on a Global Internet,” IEEE, Oct. 1995, pp. 1465–1480. doi: 10.1109/49.464716.
- [15] A. Hassan et al., “Vivisecting Mobility Management in 5G Cellular Networks,” in Proceedings of the ACM SIGCOMM 2022 Conference (SIGCOMM '22), ACM, Aug. 2022, pp. 86–100. doi: 10.1145/3544216.3544217.
- [16] ESnet, “Fasterdata Knowledge Base: Host and Network Tuning for Data-Intensive Science.” 2024.
- [17] K. Nichols, V. Jacobson, A. McGregor, and J. Iyengar, “Controlled Delay Active Queue Management,” RFC 8289, 2018.
- [18] B. Briscoe, K. De Schepper, M. Bagnulo, and G. White, “Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture,” RFC 9330, 2023.
- [19] 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.
- [20] D. Xu et al., “Understanding Operational 5G: A First Measurement Study on Its Coverage, Performance and Energy Consumption,” in Proceedings of the Annual Conference of the ACM Special Interest Group on Data Communication (SIGCOMM '20), ACM, Aug. 2020, pp. 479–494. doi: 10.1145/3387514.3405882.
- [21] A. Balasubramanian, R. Mahajan, and A. Venkataramani, “Energy Consumption in Mobile Phones: A Measurement Study and Implications for Network Applications,” in Proc. ACM IMC, 2009. doi: 10.1145/1644893.1644927.
- [22] Y. Fang and others, “Energy Optimization for Mobile Applications by Exploiting 5G Inactive State,” IEEE Transactions on Mobile Computing, 2024, doi: 10.1109/TMC.2024.3377696.
- [23] Ericsson, “Ericsson Mobility Report,” technical report, Jun. 2025.
- [24] ACSI, “Telecommunications, Cell Phone, and Smartwatch Study 2025,” technical report, May 2025.
- [25] D. Vadura, “WarpRATE: Implementation, Deployment, and Validation on Live Networks,” technical report, 2026.
- [26] 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.
- [27] A. Demers, S. Keshav, and S. Shenker, “Analysis and Simulation of a Fair Queueing Algorithm,” in Proceedings of ACM SIGCOMM, 1989, pp. 1–12.
- [28] M. Shreedhar and G. Varghese, “Efficient Fair Queuing Using Deficit Round-Robin,” in Proceedings of ACM SIGCOMM, 1995, pp. 231–242.
- [29] S. Floyd and V. Jacobson, “Random Early Detection Gateways for Congestion Avoidance,” IEEE/ACM Transactions on Networking, vol. 1, no. 4, pp. 397–413, 1993.
- [30] T. Hoeiland-Joergensen, P. McKenney, D. Taht, J. Gettys, and E. Dumazet, “The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm,” RFC 8290, 2018.
- [31] 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.
- [32] V. Arun and H. Balakrishnan, “Copa: Practical Delay-Based Congestion Control for the Internet,” in 15th USENIX Symposium on Networked Systems Design and Implementation (NSDI '18), USENIX Association, Apr. 2018, pp. 329–342.
- [33] 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.
- [34] 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.
- [35] A. Langley and others, “The QUIC Transport Protocol: Design and Internet-Scale Deployment,” in Proc. SIGCOMM '17, ACM, Aug. 2017, pp. 183–196. doi: 10.1145/3098822.3098842.
- [36] R. Marx, J. Herbots, W. Lamotte, and P. Quax, “Same Standards, Different Decisions: A Study of QUIC and HTTP/3 Implementation Diversity,” in Proc. EPIQ '20, ACM, Aug. 2020, pp. 14–20. doi: 10.1145/3405796.3405828.