WarpRATE: A Rate-Paced CC Algorithm
June 2026
Abstract
The major deployed TCP congestion control algorithms control their transmissions using the ACK stream. Reno, NewReno, and CUBIC clock sends using ACK arrivals, while BBR paces at a rate modeled from ACK-timing measurements. In either form the design assumes the ACK stream carries a usable signal beyond its acknowledgment of received bytes. The problem is that on modern paths, where wireless scheduling, virtualization, and AQM noise routinely exceed packet serialization time by orders of magnitude — the timing signal has eroded into noise. WarpRATE therefore separates rate, volume, and loss detection into distinct controls: the send clock is anchored to the egress NIC’s wire speed and adjusted with a rate law whose only inputs are delivered volume, loss marks, CE echoes, and the RTT ratio. In-flight data is bounded by an ALLOW capacity window of twice the rate-delay product; and jitter tolerance comes from an RTT baseline and a coefficient-of-variation-moderated LOSST loss-detection interval. In discrete-event simulation and on live deployments, WarpRATE sustains high throughput under compound loss and jitter that cuts traditional CCs to a few percent of available link capacity.
1 Introduction
As outlined in [1], TCP derives its sending rate from ACK-timing signals whose fidelity has eroded over todays modern data paths. WarpRATE, the design this paper presents, tolerates the eroded signal rather than filtering it. Under compound loss and jitter that cuts traditional CCs to a few percent of link capacity, WarpRATE carries 4–5× what BBR and 20–30× what CUBIC deliver1, and yields 651 Mbps at 10% random loss where CUBIC manages 3.0 Mbps (§7.3). On live deployments across a wired ISP path, LTE, and Starlink, production nodes measure 1.3–2.5× improvements over CUBIC and BBR where the ACK clock is intact and +4.4× CUBIC on Starlink where it is not (§7.2).
2 Background
5G cells routinely experience 1–5% packet loss due to interference, slot schedulling induced multi-millisecond jitter, and intermittent handover events that can spike loss rates by an order of magnitude [2]. Under these conditions, today’s widely deployed congestion control (CC) algorithms experience throughput collapse, which degrades user experience and lengthens radio on-times. With average smartphone data consumption at 22 GB/month and rising [3], each throughput shortfall compounds into aggregate radio on-time. This is significant since during active data transfer the radio is the dominant drain: measurement on an operational 5G handset attributes 55% of total device energy to the 5G module2.
Our field measurements on a production LTE-A network showed a 20–30% improvement in handset battery life when data delivery speed was increased by 2×. The results are consistent with the tail-energy literature and show that TCP performance has consequences well beyond throughput. The mobile device’s RRC state machine holds the device in high-power RRC_CONNECTED state for the duration of each transfer plus a post-transfer inactivity timer — the “radio tail”. Balasubramanian et al. [4] measured this tail at up to 80% of total radio energy on 3G devices, with 5–12 second durations per transfer, and the pathology persists on 5G3, where the CONNECTED-to-INACTIVE tail still dominates device energy budgets [5].
Radio-tail energy translates directly into operator economics. The ACSI 2025 [6] study rates battery at 77/100, the lowest-scored attribute of any smartphone feature, in an index whose overall score has reached a decade low. In the same survey, 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.
3 TCP Congestion Control Ontology
Every transmission opportunity in a TCP flow forces the sender to answer three questions that, together, fully determine what leaves the wire next.
- What segment should be sent — new application data or a retransmission of something the receiver has not yet acknowledged?
- Is there room for that segment given the path’s physical capacity, the receiver’s advertised buffer, and any data already in flight?
- How fast should the segment depart relative to the segments that preceded it?
Segment selection, flow budget, and pacing exhaust the sender’s per-packet degrees of freedom4. A congestion control algorithm is, in operational terms, a procedure for converting flow state signals into answers to the previous three questions.
3.1 Signals
A TCP sender observes a small, stream related, set of raw signals [ACK, SACK, RWND, ECN (CE/ECE), and RTT]. It uses them to derive the smoothed RTT (SRTT) per [8]; the running 10 s minimum , RTTVAR, rateOf(LOSS), rateOf(DELIVERY), DSACK [9], and a BDP upper bound from . Individual CC algorithms then compute derived quantities such as BBR’s delivery-rate sample, DCTCP’s ECN fraction, or Copa’s queueing delay. Furthermore, and arguably unexpectedly so, the receiver can influence the sending rate by modulating RWND, choosing not to echo ECN, and altering the timing of ACKs and SACKs.
3.2 Control
CUBIC [10], is the default Linux congestion controller and the dominant CC algorithm on the public internet. It answers all three questions through a single variable, . The pacing rate is computed as and loss modulates the rate down by shrinking the window. Coupling all three answers onto CWND is the algorithm’s defining feature and the source of the failure modes that §8 catalogs. BBR [11] decouples pacing (an explicit rate as ) from the flow-budget (an inflight cap derived from ). However, both of CUBIC’s and BBR’s estimators are fed by ACK timing, which on jittery paths no longer corresponds to a stable underlying property; Kumar et al. [12] document the resulting collapse on millimeter-wave wireless. Other delay-based and learning designs — Vegas [13], DCTCP [14], Copa [15], PCC [16] — may synthesize a different signal but share the dependence on ACK-derived measurements.
4 Motivation
We have had 40 years of TCP CC research and the result is a complex collage of congestion control algorithms that partition the space into sets of topology motivated variants. We thought there might be a better way and thus we present our findings. §5 specifies the WarpRATE algorithm. §6 describes WarpSIM, §7 reports results. §8 discusses throughput collapse, §9 discusses impairment sources and §10 and §11 close.
5 WarpRATE Detailed Design
The WarpRATE design uses three independent controls. ALLOW bounds the bytes that may be in flight; RATE governs the inter-packet delay at the egress NIC; and LOSST decides when an unacknowledged segment has been lost. Each control has its update cadence and in most cases uses a mix of raw and derived signals (§3.1). Figure 1 outlines the design: raw signals enter, computational modules consume them, and the three decisions that govern packet transmission drive state machine transitions.
5.1 Epochs
An epoch is a measurement interval of one , the path’s round trip including its own noise:
where is the RTT spread, defined as the mean deviation of the RTT samples [8] maintained as a decaying maximum that loses an eighth per epoch. Jitter vibrates a path’s length: the RTT never falls below , but it is stretched by an amount that has nothing to do with queueing. A control law that reads every millisecond above as a queue would mischaracterise a path that is merely noisy. We observe that on a clean path and . Conversely, on noisy paths grows to approximately one sixth of and the growth is transient and sporadic whereas a self inflicted queue raises SRTT smoothly over time, with a spread near 1% of the excess, and it remains visible as growth in .
A rate control law is constructed from four inputs: , loss marks per packet delivered, net of retransmissions a DSACK reports as duplicates; , CE echoes per packet; , the ratio of SRTT to ; and , the delivered volume rate spanning at least 8 epochs or 200 ms, whichever is longer. Epoch timing begins at first transmit, with the resulting SYN/SYN-ACK handshake seeding .
5.2 Control Signals
Two update cadences drive WarpRATE’s signals. The per-ACK signals — jitter CV and the SACK-gap-age — are updated immediately so that loss decisions are timely, and
the per-epoch inputs , , , and receive updates at epoch boundaries which limits the influence of intra-epoch transient noise on pacing decisions.
Both cadences observe the offload-granularity principle: namely, that a timing-derived signal
must be measured above the quantum background noise that TSO segmentation, GRO coalescing, and link-layer ACK
schedulers impose on the packet stream. If we were to measure at the background, the
timing measurements would measure the mechanisms that perturb the jitter schedule rather than
an overall characteristic of the path. Prior to WarpRATE, the lone deployed acknowledgment of this
phenomenon is BBR’s extra_acked aggregation estimator [17], added after
BBRv1 read wireless ACK batches as missing capacity and underperformed on WiFi and cellular.
Any actionable rate evidence must not be derived solely from per-ACK signals which is why we use
as bytes delivered over a span of at least eight epochs; a measure that integrates the quantum
by construction. Finally, steady-state pacing is
anchored to and to , never to inter-ACK cadence. LOSST derrives its elasticity from
from per-ACK CV estimates that track jitter noise such that aggregation-induced clumping is part of the signal.
5.2.1 NIC Wire Speed and the Gap Range
The egress NIC’s wire speed, , is the rate ceiling, the fastest rate at which packets can leave the sender. The constraint is physical and known to the sender at connection setup. WarpRATE paces by the gap between packets rather than by a rate, so it inverts the ceiling into the smallest gap it will ever pace at5,
is constant for the duration of the connection. We also set a rate floor at 100 kbit/s, and its gap, , is the largest gap the sender will ever pace at, so a flow on a heavily loaded path keeps sending and keeps receiving ACKs. Every gap the rate law sets (§5.2.3) stays within . Within that interval a gap is never a ceiling or floor; gaps are smallest and largest. Next, we compute the physical BDP as:
Computing BDP against rather than SRTT severs the queue-RTT positive feedback loop described in [1]. This physical BDP represents the maximum amount of data the flow’s path can keep in flight, and it sets the ALLOW floor until the delivered volume is known (§5.2.3).
5.2.2 Per-ACK: Jitter CV, LOSST, and NACK
WarpRATE measures path noise through the coefficient of variation of ACK inter-arrival times, , computed using the Bollinger Band form familiar from financial signal processing. On every ACK, the inter-arrival sample updates an EWMA of the mean and variance with :
The ratio is the instantaneous CV, and a slowly decaying peak retains memory of recent jitter spikes through a 0.995-per-epoch decay (about a 200-epoch half-life). The CV multiplied by a 3.0 gain and clamped to the interval produces the jitter multiplier J. CV thus self-normalizes against the path’s ACK spacing: 100 µs of jitter on a 10 ms ACK interval () is negligible, while the same 100 µs on a 200 µs interval () is severe.
The computed is then used to set the LOSST interval time-based reorder threshold :
On clean paths , and the interval is . Under heavy jitter approaches 4, widening the interval to thereby giving reordered packets time to arrive before being declared lost and eligible for retransmission.
Any three or more concurrent gaps that age past the interval — that is, three gaps each older than — that are still all simultaneously unacknowledged at the same SACK-bearing ACK cause the sender to emit a NACK. The decision to emit is based on the count of concurrent aged gaps, not the total number of losses. Random per-packet loss produces isolated, temporally dispersed gaps that rarely age together; whereas congestion loss produces clustered gaps that share a common drop event and therefore age together. A wider LOSST under jitter gives the reorder-versus-loss test more time to resolve before the threshold is reached.
A DSACK settles the same question after the fact: the receiver reports that a retransmission arrived as a duplicate, so the original was late rather than lost. WarpRATE removes that retransmission from and opens the kernel’s RACK reorder window to SRTT, so a path that reorders, through jitter or through multipath, stops reading as lossy. Clustered non-congestive loss, such as a deep fade that outlasts link-layer retry or a handover freeze, can mimic the congestion signature; the burst-loss models utilized herein constrain but do not eliminate a false positive in that case.
5.2.3 The Per-Epoch Control Law and ALLOW
In addition to those identified in §5.1 the control law also maintains and . is the smallest gap that the path has shown it can deliver. It is always greater than , the smallest gap that the network interface supports. The implied rate, , is the proven rate. Next we introduce DELAY as extra gap added to while the path shows distress. Now we can define as:
| Input | Condition | Epoch signals | DELAY target term |
|---|---|---|---|
| DISTRESS | |||
| DISTRESS | |||
| , overdriving | |||
| , overdriving | DISTRESS | (same term) | |
| , not overdriving | HOLD | none | |
| sender idle | app-limited | HOLD | none |
which tracks the sender’s effective pacing rate as . The gaps are thus ordered:
Since the law works in gaps, values are inverted: rises when shrinks toward , and the rate falls when DELAY grows. DELAY is used in distressed path situation to clamp the sending rate and is capped at , so distress can cut the pace to at most; below that, only a lower slows the pace further, and never slower than the rate floor implied by .
Table 1 lists each epoch input and its function, with defined as the gain of R: each unit of R above 1.5 adds one IPD_min of DELAY, and the term reaches the cap at . A fourth input, , is used to detect overdrives. An overdrive is a pace exceeding 6. measures a queue buildup that only an overdriving sender builds. counts against the sender only when a corresponding flow is overdriven; a queue that is constant while the pace matches is assumed to belong to other traffic, and in that case the decision signals HOLD. An epoch that matches a DISTRESS row signals DISTRESS, and one that does not match any row is considered normal and signals CLEAN.
The law starts in a growth phase at the seed (§5.4). While the path keeps up, growth doubles : the first epoch that delivers any data doubles it, and after a one-epoch wait, so that delivery can reflect the new pace, each epoch that delivers at least the best so far with doubles it again, up to eight times. When a test fails, growth ends with at the larger of the seed and the best rate delivered, never above the pace.
A seed can also overestimate the path, as a 500 Mbps seed does for a Wi-Fi link policed down to 5 Mbps. In this case the path pushes back (SRTT above , or or over threshold) and delivery stays below 80% of the pace. As a result, growth bisects. The best rate delivered is the floor and the pace is the ceiling. Each step paces at its geometric mean, waits one epoch, and lowers the ceiling to that pace if delivery fell short of 80% of it; the floor rises to the best rate delivered. Bisection stops when the ceiling is within of the floor, or after six steps, and then sets to the floor.
| Decile | 0 – 2 | 3 – 5 | 6 – 8 | 9 |
|---|---|---|---|---|
| .50 | .35 | .25 | .15 |
On the simulated and live policed links the pace falls from 500 to about 5.7 Mbps in five steps, 1.6 s into the flow, cutting median SRTT from 960 to 110 ms. After growth, every epoch expiry runs five steps in order:
- Classify the epoch by Table 1. An epoch that signals HOLD stops here and changes nothing; otherwise the epoch continues to steps 2-5.
- Set the DELAY target to the sum of the table’s terms, capped at . The term starts at 1.5, below the 2.0 DISTRESS threshold, so a growing queue raises the target before the epoch signals DISTRESS.
- Update DELAY. A target above DELAY sets DELAY to the target at once and starts a temporary hold that lasts as many epochs as the run of consecutive epochs signaling DISTRESS that led to the rise, at most 16. During the hold a DELAY may fall but may not rise again. This is a debounce that ensures one congestion event raises DELAY once. Otherwise, DELAY decays toward the target, , where is the decile of , the pace as a fraction of , and a DELAY below is set to zero. A standing queue holds DELAY at its proportional value; a transient one decays out within a few epochs.
- Reset under a standing DELAY. After sixteen consecutive overdriving epochs with DELAY above zero, and . The pace does not change; the rate the path has sustained for sixteen epochs becomes the new , and recovery starts from it instead of from the old .
- Re-anchor or climb. An epoch that signals DISTRESS outside a hold consults the distress ring discussed below. An epoch that signals CLEAN with DELAY at zero climbs: , with the decile of , limited so that never exceeds the larger of and the last two epochs’ delivery. The limit can slow or stop a climb but never raises . Furthermore, because cannot exceed the pace, the 25% margin is the steady-state probe. The climb also runs when DELAY holds only the term below 2.0, so a path whose SRTT sits at to by nature still climbs.
Steps 3 and 5 use a common recovery curve (Table 2), the fraction of the remaining distance closed per epoch: DELAY toward zero, and toward . The decile says how close the quantity already sits to that end point, so the step is large when it is far away and small when it is near, and because each step is a fraction of the remaining distance it cannot
overshoot. The climb is thus a self-attenuating probe that pushes less the closer gets to the desired target7.
A distress ring holds up to five entries and records epochs that signaled DISTRESS outside a HOLD with zero DELAY. It records the rate, and the pace. An epoch in which fell below half its previous value is a collapse and is not recorded. The ring then allows an epoch that signals DISTRESS outside a hold to re-anchor if three or more entries are younger than five seconds and lie within 15% of their median, and the newer half of those entries averages at least 70% of the older half. If true, is set to that median. As a result, then starts from the level the path has repeatedly carried instead of waiting for DELAY to find it. Intuitively, a newer half that carries less than 70% indicates contention with other flows rather than a fixed capacity, and is left unchanged.
ALLOW caps unacknowledged bytes in flight. It does not engage while the path shows no queue, and it is never set below a floor of , which is the volume the path has carried over a round trip with variance flexibility; until is valid, the floor uses the physical BDP. Additionally, when a queue is present, and , ALLOW is capped at:
with the retransmit headroom , where is the retransmitted fraction of the previous ALLOW. The headroom is largest on a mostly healthy path and falls to zero when retransmissions reach half the in-flight budget. This prevents compounding of queue buildup and subsequent RTT increase. ALLOW counts every transmitted and unacknowledged byte, retransmissions included. Pacing never uses ALLOW, so a large in-flight permission cannot raise the send rate, and actual in-flight stays bounded by the paced rate times the round trip.
5.3 Phase Machine
The phase machine orchestrates behavior using seven phases, with transitions between every pair (Figure 2). HANDSHAKE is the entry state, DEAD is the terminal state, and the five core phases between them carry the flow through its life cycle. RETREAT controls actions when DELAY is above zero; PROBE and CRUISE are the states in which DELAY is zero, PROBE looks for four consecutive CLEAN epochs and then transitions to CRUISE. Finally, data starvation exits any state to DRAIN.
5.4 Phase Transitions
Phase transitions fire on one of two transition triggers: conditional or time derived. A condition-driven transition is evaluated at every epoch boundary, while a timer-driven transition is armed for a count of epoch boundaries and fires when the count expires. Additionally, two wall-clock timers are used to detect conditions where epoch counting would fail due to ACK starvation. The above dichotomy is not strictly absolute: an ACK arriving in NOPULSE or an application write during DRAIN behaves like a condition-driven transition even though the condition occurs between epoch boundaries. Similarly, a timer that fires must fire in the phase in which it was started. If not, it is considered stale and is ignored.
5.4.1 HANDSHAKE
HANDSHAKE runs from connection setup to the first epoch. Instead of slow start or a discovery probe, the pace is seeded at , or at 60% of if the handshake RTT is under 1 ms. The control law (§5.2.3) runs immediately post seeding. Simulated and live validations have shown the chosen approach to be both effective and stable. When the seed is above the path, the overshoot lasts only until growth ends, bisecting down if the path pushes back. On a 170 Mbps satellite path the seed sends 3× over for one round trip, and the live retransmit rate across three media stayed under 0.05% of packets (§7). Exit is to PROBE at the first epoch.
5.4.2 PROBE
PROBE runs the growth phase and exits to CRUISE after growth ends and four consecutive epochs signal CLEAN. It exits to RETREAT when DELAY rises above zero.
5.4.3 CRUISE
CRUISE is the steady-state phase. Each epoch that signals CLEAN runs the climb of step 5 (§5.2.3), and the headroom re-probe of §5.5.1 runs from here. CRUISE exits to RETREAT when DELAY rises above zero.
5.4.4 RETREAT
RETREAT runs while DELAY is above zero as per §5.2.3. A rising target sets DELAY at once and starts a hold, a falling one lets DELAY decay by the recovery curve, and the cap of bounds every rise. RETREAT exits to PROBE when DELAY returns to zero.
5.4.5 DRAIN, NOPULSE, and DEAD
The final three phases manage life-cycle termination: DRAIN holds a sender with no more application data, either recovering an unacknowledged tail (pacing continues, so retransmits use the existing rate
clock) or idling fully acknowledged; NOPULSE is the pre-death state signaling that ACK activity has stopped with unacked data still held; DEAD emits RST and tears the connection down, and is terminal.
Every exit from DRAIN or NOPULSE is rate-preserving and is triggered by receipt of an ACK or by an application write. The liveness timeouts8 run if unacked data exists: half of without an ACK moves DRAIN to NOPULSE, where TLPs continue at a slower cadence, and the remaining half moves NOPULSE to DEAD. An idle, fully-acknowledged connection is healthy rather than blacked out, so it ages against a separate . Both timeouts are operator-meaningful wall-clock budgets rather than exponential backoff sequences, with set high enough to allow for network reconfiguration.
5.5 Optimizations
We have implemented a number of optimizations; three are important – the headroom re-probe §5.5.1, TLP-Only recovery §5.5.2, and Continuous Transmit §5.5.3.
5.5.1 Headroom Re-Probe
A flow in stable cruise may be pacing below a ceiling the path could carry. Rather than raise the rate and wait for DISTRESS, WarpRATE launches one paced train at 1.25× and reads it as a single super-packet of known length: capacity is taken from the train’s arrival span, never from per-packet dispersion inside it, which is the offload-granularity principle applied to a probe. The train is data-gated so a thin flow never launches one, its verdict either raises to the rate the train carried or leaves unchanged, and the cadence backs off from 16 to 64 epochs while verdicts come back unchanged.
5.5.2 TLP-Only Recovery
WarpRATE has no RTO. The Tail Loss Probe [18] is the sole recovery mechanism, armed at . On a 2 ms link the timer fires at ~4 ms, fifty times faster than the 200 ms RTO minimum. Eliminating the RTO removes both the 200 ms floor and the backoff spiral from the recovery path.
Dead-link detection is decoupled from loss detection. Rather than counting TLP probes, WarpRATE uses the wall-clock budget. The effective probe count adapts automatically: on a 2 ms link the 10-minute budget allows on the order of 150,000 probes; on a 200 ms satellite link the same budget allows about 1,500. Dropping the backoff does not drop pacing: probes stay spaced at , thereby rate-limiting the retry stream, and the budget bounds its duration on a black-holed path.
A kernel expert may object that mainline already mitigates the RTO’s harm: F-RTO [19] detects a spurious timeout and undoes the window damage. The objection understates the issue. F-RTO is repair after the fact: the timer fired, the spurious retransmission was sent, and the undo restores window state WarpRATE does not use. In WarpRATE the jitter that would cause spurious timeouts is absorbed by LOSST’s CV-widened interval and no timer decision is required. The engineering economics also run one way: TLP must be implemented regardless, because it is the kernel’s solution for tail loss; mainline then stacks RTO, F-RTO, and the undo machinery behind it, four interacting mechanisms where WarpRATE relies solely on the first, re-armed forever. The comparisons in §7 test this directly: the kernel-faithful CUBIC and BBR baselines there run with F-RTO and RACK enabled, and WarpRATE’s margins still hold.
5.5.3 Continuous Transmit
We observe that the last few packets of a bulk transfer are disproportionately expensive. Once the application’s data is exhausted, traditional TCP enters serial recovery rounds: retransmit, wait an RTT for ACKs, retransmit the re-dropped subset, wait again. WarpRATE instead pretends the file is longer. When real data runs out, unconfirmed segments feed back through the same pacing loop in place of new data. Both TLP and NACK-driven retransmits use a circular retransmit buddy that walks the lost-segment set up to a budget of 10% of BDP per activation. Below that threshold the buddy retransmits exactly as much as was lost, and the 10% cap only applies at loss rates above 10%. On paths of 2 to 25 ms RTT at 0.5% to 5% loss the retransmit overhead is at most equal to the loss rate.
5.5.4 Deviations from Normative CCs
Three further departures deserve brief mention. Jitter is measured twice, for two decisions: the Bollinger-band CV of ACK inter-arrival times sets LOSST’s reorder interval, because it tracks the per-packet displacement that produces reordering, while the RTT spread sets the law’s baseline, because jitter stretches the round trip as a whole. Jitter tolerance comes from the baseline and LOSST, not from an inflated ALLOW: an earlier design increased ALLOW to under heavy jitter and achieved its tolerance but produced large standing queues; the current design widens the reorder interval up to and measures and ALLOW against , so ALLOW stays at twice the delay product of the path’s actual round trip. There is no bandwidth estimator: rate evidence is delivered volume over a span of epochs, never a per-ACK or per-epoch rate sample — as those are simply no longer reliable.
6 WarpSIM
Every simulated artifact in this paper comes from WarpSIM, a purpose-built discrete-event
simulator in which WarpRATE runs against the same path model as implementations of CUBIC [10],
BBR (v1 and a v3 build tracking the March 2024 kernel module), and DCTCP [14].
Each is fully implemented from its published specification driven via a harness mirroring
the Linux kernel’s tcp_congestion_ops interface. Logical time is an integer
count of picoseconds and a run is fully specified by an RNG seed and
| Medium | Date | n | WR | CUBIC | BBR |
|---|---|---|---|---|---|
| Wired | 9/21 | 5 | 594 | ||
| LTE | 9/18 | 9 | 272 | ||
| Starlink | 9/18 | 10 | 169 |
a JSON topology. Any trace is thus 100% reproducible. A link carries a per-direction loss and jitter model covering wired, WiFi TXOP, and cellular slot-scheduling behavior; routers attach any of six queueing disciplines including DualPI2 and PFQD [20]. Every simulated receiver advertises a 50 MB window, so the receive window never constrains the senders being compared.
7 Evaluation
7.1 Calibration Against Live Paths
Six paths — Amsterdam, Phoenix, Singapore, LTE, WiFi, and Starlink — were captured between
client endpoints and a common server whose egress ran fq, fq_codel,
and pfifo_fast in separate runs, contributing five 10 MB downloads per region × qdisc cell with
per-millisecond TCP_INFO samples and a client-side pcap as an independent cross-check on deduced
bandwidth. Each path’s bandwidth, propagation, jitter model, and loss model were deduced from its
capture and used to configure the simulator, spanning Gaussian jitter from 93 µs on Amsterdam to
7.27 ms on LTE and bernoulli_train loss where the retrans counter moved. Sim BBR’s 5-trial mean
goodput then agrees with real BBR’s to within 16%.
7.2 WarpRATE on Live Paths
However, the strongest evidence for WarpRATE’s margins is live and simulator-independent. Production AccurateSpeedTest nodes ran sweeps of 240 MB downloads with WarpRATE, CUBIC, and BBR from the same server through a host-mode PFQD egress [20] over three different data paths: a 35 ms wired ISP path, an 80 ms LTE cell, and a 44 ms Starlink satellite. Table 3 gives the per-medium medians of the effective rate, the bytes delivered over the transfer’s wall time.
The difference is smallest where the ACK clock is regular and grows as it degrades. On the wired path WarpRATE finishes 240 MB in 3.2 s against 4.4 for either stock CC, on LTE in 6.5 s against 7.8 and 8.0, and on Starlink in 10.3 s against CUBIC’s 22.3. BBR, which does not treat every loss as congestion, achieves parity on Starlink where CUBIC, which does, falls to a quarter. Notably, jittery Starlink shows little packet loss, and retransmissions ran under 0.05% of packets on every medium.
7.3 Synthesized Sweeps (Simulator)
The companion paper [1] evaluates each impairment dimension in isolation using WarpSIM. On clean, uncontested paths the sweeps show near-parity: on the 1 Gbps baseline
| Topo | CC | goodput (Mbps) | compl. (ms) |
|---|---|---|---|
| p2p | CUBIC | 23.7 [8.5–32.2] | 4628 |
| p2p | WR | 43.6 [39.3–47.2] | 1883 |
| core | CUBIC | 31.1 [24.4–40.9] | 2713 |
| core | WR | 36.7 [23.9–45.6] | 2373 |
| eNodeB | CUBIC | 33.2 [24.1–42.2] | 2622 |
| eNodeB | WR | 36.1 [28.4–42.8] | 2331 |
WarpRATE’s 903 Mbps sits 2% above kernel-faithful CUBIC’s 883 and 3% above BBR’s 879. Separation appears when the path is impaired. Under random loss WarpRATE maintains 651 Mbps at 10% Bernoulli loss where CUBIC delivers 3.0 and BBR 68. Under jitter, goodput declines gracefully to 91 Mbps at σ = 200 ms where CUBIC and BBR, even with F-RTO and RACK, retain 12 and 1.7 Mbps. When jitter and loss combine at cell-edge severity, 5% loss under σ = 10 ms of jitter on a 30 ms WAN, WarpRATE delivers 65 Mbps against CUBIC’s 1.3 and BBR’s 25.
7.4 WarpRATE Proxy at Last-Acre Boundary (Simulated)
In most wireless deployments the impaired segment is the last acre9: the backhaul behind the access point is usually well-behaved and the sender CC runs on a server instance in a 3rd-party datacenter. In LTE networks the mobile operator controls the core network and the eNodeB cell edge, but not the origin server whose CC determines the end-user observed data transfer rate. We placed a proxy node running WarpRATE at positions modeling: a location in a core network, 15 ms of RTT from the client, and at the eNodeB itself, 5 ms out. The proxy terminates the sender’s TCP on the WAN side and re-opens a fresh connection on the last-acre side. Each leg’s CC instance sees only its RTT and impairment profile — an established edge pattern (RFC 3135 [21], WiFox [22]).
Table 4 shows a 10 MB download over the calibrated LTE profile (60 ms RTT), five seeds per cell. A proxy at either position shortens the lossy leg’s local recovery loop and lifts the unmodified sender: CUBIC rises from 23.7 Mbps end-to-end to 31.1 behind a core-network proxy and 33.2 at the eNodeB, finishing in 2.6 to 2.7 s instead of 4.6 s and cutting the radio on-time behind the device energy budget of §2 by about 40%. Placing the proxy at the antenna rather than in the core gains little at the modeled RTT’s.
Running the same test using a crowded 5G 500 Mbps production cell with 7 ms jitter and 1.5% loss at 40 ms RTT collapsed CUBIC to 2.3 Mbps and held BBR to 86 where WarpRATE end-to-end delivered 210 Mbps, and a core-placed WarpRATE proxy lifts the unmodified clients to 198–206 Mbps, a 2.3× (BBR) to 90× (CUBIC) uplift.
8 CC Failure Studies
It is instructive to understand where, in traditional CCs, the failure is coming from.
Random loss misread as congestion. On a 1 Gbps path carrying 5% Bernoulli loss, the top of the
1–5% range reported for production cellular last-acres [2], CUBIC delivers 22
Mbps and BBR 426 against WarpRATE’s 618, and applying the same loss to both directions leaves them
at 2.7 and 210 against 574. CUBIC cuts CWND on every loss event and cannot rebuild inside a 2 MB
transfer. BBRv3, with the kernel’s RACK recovery and inflight_hi handling, trails WarpRATE by
1.45× while the loss is one-way, then halves when the ACK direction loses also and trails by 2.7×
as each loss round clamps the inflight ceiling while the delivery-rate model waits out recovery.
The slow-start hole. The live captures show it best: 114 ms of RTT on calibrated Amsterdam constrains BBR to 68 Mbps against WarpRATE’s 178, STARTUP’s three to four stabilization RTTs consuming much of a 10 MB transfer. Adding 1% loss and jitter to the WAN leaves CUBIC at 6 Mbps and BBR at 31 against WarpRATE’s 127.
The socket-buffer ceiling. On a clean 10 Gbps path moving 1 GB, CUBIC delivers 1,298 Mbps and BBR 1,264 against WarpRATE’s 7,190. A sender must keep at most the minimum of its congestion window, the receiver’s advertised window, and its send buffer; the kernel’s default 4 MB send buffer represents a hard constraint on high-data-rate non-datacenter RTT throughput. A 10 Gbps × 25 ms path has a 32 MB BDP; a 4 MB send buffer will pin in-flight data at 12.5% of capacity on a path with no loss, jitter, or queueing. The defaults are rarely tuned and when they are they track memory pressure, never path capacity; WarpRATE sizes its in-flight from the measured path-delay product and requests a send buffer to match; the mechanism is described in [23].
9 Impairment Insights
Packet flow visibility surfaces two results end-to-end goodput hides; the CC-agnostic analysis of both can be found in [1].
Impairment direction is not symmetric. Under 5% Bernoulli loss on a 1 Gbps × 2 ms path, loss confined to the ACK direction is cheap for every CC, 633 to 745 Mbps, since the receiver already holds what the lost ACKs described and cumulative acknowledgment is self-healing. Conversely, the same loss on the data path separates the algorithms; WarpRATE delivers 618 Mbps against 426 for BBR and 22 for CUBIC. Loss in both directions then splits the field by architecture: rate-based WarpRATE holds most of its data-path figure (574 Mbps), model-based BBR halves to 210, and window-based CUBIC falls an order of magnitude to 2.7.
ACK-path jitter is the inverse case. Adding 10 ms of Gaussian jitter over 1% data loss on a 30 ms WAN reverses the picture. The algorithms that delivered 633 to 648 Mbps under ACK-path loss deliver 5 to 30 Mbps under ACK-path jitter, because a thinned ACK clock still tells the truth while a jittered one lies to every RTT-based and delivery-rate-based estimator. For WarpRATE the asymmetry runs the other way and mildly so: ACK-path jitter is its gentlest case (159 Mbps), the CV tracker existing precisely to absorb ACK-timing noise, against 127 Mbps when the jitter rides the data path and perturbs the delivery being measured. Raising data-path loss to 5% costs WarpRATE 16 to 49% (65–97 Mbps across the three directions); it costs CUBIC three-quarters of an already small number and BBR 9 to 50%.
Buffer depth isolates the probe mechanism. Holding the clean 1 Gbps path fixed and changing only the bottleneck queue from 1× to 4× BDP changes almost nothing: CUBIC delivers 882.8 Mbps in both test cells, BBR moves from 861 to 879, and WarpRATE reports 903.1 Mbps. The invariance is structural: the sender never bursts, pacing from its first packet at a rate bounded by , and ALLOW caps in-flight at twice the rate-delay product, so the queue a shallow buffer sees is the seed’s first round trip and no more.
10 Related Work
The ontology of §3 positioned the production CCs by how they answer the three per-packet questions, and the companion paper [1] surveys the refinement literature in full. Our observation is that, for each thread reviewed here, modifying the design toward WarpRATE-level behavior ends up requiring WarpRATE’s mechanisms.
Window-based CC and its refinements. RFC 9438 [10] codified CUBIC’s fast-convergence and
W_est refinements, yet every detected loss still cuts CWND by 30% whether it came from a queue
overflow or a wireless drop, and BBRv3’s [11] 2% inflight_hi bound is that same uniform
response one level up. Kumar et al. [12] showed where it leads on millimeter-wave
paths: jitter depresses the windowed-minimum RTprop, BDP shrinks, CWND exhausts, and BtlBw
collapses, which is the immediate motivation for WarpRATE’s acyclic dependency graph. The 2000–2007
reorder-tolerance lineage — DSACK [9], dynamic DUPTHRESH [24], and RR-TCP
[25] — tuned the
loss-versus-reorder classifier for gains near 10% while staying window-based and ACK-clocked
(§3.2), where WarpRATE generalizes the same intuition into a
time-and-jitter-scaled LOSST horizon (§5.2). HyStart and HyStart++ (RFC 9406)
exit slow start on a delay signal that jitter erodes.
Alternative primary signals. Vegas [13], Copa [15], DCTCP [14], and PCC [16] substitute implied queue depth, a delay-target utility, the CE-mark fraction, or online utility probing for loss-as-congestion. Each is correct in its intended environment, none escapes the ACK-derived measurement — or, for DCTCP, the universally tuned ECN — that this work finds fundamental.
Edge proxies. RFC 3135 [21] formalized Performance-Enhancing Proxies, and WiFox [22] measured 400–700% downlink gain from AP-side termination on a 45-node 802.11 testbed. Those works establish the topology that the WarpRATE proxy results of §7.4 inherit, and the contribution here is the CC inside the proxy: a PEP running stock TCP moves the feedback loop closer to the lossy link without changing its loss or jitter response.
Medium-specific CC. CLAW [26] infers a CWND from RSRQ, MCS, and resource-block allocation read off the LTE diagnostic interface, requiring a PHY-aware sender, root on the client, and a fallback to CUBIC once the bottleneck moves to the backhaul. Against Starlink’s ~15 s handovers, SaTCP [27] freezes CWND on relayed handover notices and SatPipe [28] patches BBR with a learned handover schedule for up to 38% mean and 127% p10 gains. All are medium- or schedule-specific.
Grafting mechanisms onto deployed CCs. Several WarpRATE parts graft cleanly onto a BBR or CUBIC
deployment: LOSST can replace the three-dupACK threshold or the inflight_hi bound, NIC-anchored
pacing would bound STARTUP and slow-start overshoot, a multi-epoch volume damps BtlBw collapse on
transient outages, and a Bollinger CV tracker scales jitter tolerance with measured jitter. None
breaks the cycle that matters. WarpRATE’s stability rests on an acyclic relationship among EFIPD,
ALLOW, LOSST, and the volume register in which no estimator feeds its input, while BBR and CUBIC each close a
positive loop through CWND or BtlBw, so even a fully grafted BBR keeps its PROBE_RTT dips — and
removing PROBE_RTT is where BBR stops being BBR.
11 Conclusions
WarpRATE rests on one architectural commitment: the send clock, the in-flight ceiling, and the loss-detection threshold must not be driven by the same signal. Traditional CC derives all three from ACK-timing arithmetic over a congestion window, and that arithmetic degrades on every modern path examined here: wireless last-acres whose loss is not congestion, virtualized infrastructure whose jitter is not noise, and high-BDP links whose default socket buffers are too small to fill.
What the measurements establish is an envelope rather than a tuning win. One control loop, unchanged and unprofiled, covers wired fiber, WiFi, busy LTE, Starlink, and high-BDP WANs with no fallback CC when the access medium changes; covering that range today means switching CCs, adding per-medium fallbacks, or hand-tuning queues. Each collapse WarpRATE avoids traces to an architectural decision in CUBIC or BBR (§8), not a parameter, which is why we argue refining those designs is unlikely to reach the same envelope.
The implications are practical. An operator deploys the improvement once, at the sender against a PFQD-equipped egress [20] or as a proxy at the last-acre boundary for the client base no one controls, with one deployment and no per-link or per-medium profile. Subscribers see the lift as user experience: transfers that complete quickly every time rather than at the mercy of a per-connection lottery, which is what carriers actually sell at P95 and P99. Furthermore, a faster transfer keeps the radio awake for less and the same deployment yields battery life. A rising tide that lifts all ships is possible: operator economics, user experience, and handset battery alike. Demonstrating that is this paper’s central contribution.
It is also becoming necessary. Access infrastructure is moving to 10 Gbit [20], and the companion study [1] shows the impairments that defeat ACK-clocked CC are structural, not tunable; without an improved algorithm the shortfall between provisioned and delivered bandwidth widens with every infrastructure upgrade.
12 Statement on AI Use
AI, specifically models and tools provided by Anthropic, were used to create simulation harnesses, organize data sets, and validate implementations against specifications.
References
- [1] D. Vadura, “The ACK Stream No Longer Keeps Time: Jitter and the Erosion of TCP's Congestion Signal,” technical report, 2026.
- [2] 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.
- [3] Ericsson, “Ericsson Mobility Report,” technical report, Jun. 2025.
- [4] 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.
- [5] 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.
- [6] ACSI, “Telecommunications, Cell Phone, and Smartwatch Study 2025,” technical report, May 2025.
- [7] 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.
- [8] V. Paxson, M. Allman, J. Chu, and M. Sargent, “Computing TCP's Retransmission Timer.” RFC Editor, Jun. 2011. doi: 10.17487/RFC6298.
- [9] 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.
- [10] 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.
- [11] 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.
- [12] 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.
- [13] 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.
- [14] 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.
- [15] 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.
- [16] 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.
- [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] 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.
- [19] P. Sarolahti, M. Kojo, K. Yamamoto, and M. Hata, “Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP.” RFC Editor, Sep. 2009.
- [20] D. Vadura, “Practically Fair Queueing: A Per-Flow Scheduling Discipline for Shared Internet Links,” technical report, 2026.
- [21] 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.
- [22] 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.
- [23] D. Vadura, “WarpRATE: Implementation, Deployment, and Validation on Live Networks,” technical report, 2026.
- [24] 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.
- [25] 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.
- [26] 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.
- [27] X. Cao and X. Zhang, “SaTCP: Link-Layer Informed TCP Adaptation for Highly Dynamic LEO Satellite Networks,” in IEEE INFOCOM 2023 – IEEE Conference on Computer Communications, IEEE, 2023, pp. 1–10.
- [28] 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.