Accelerated Bottleneck Bandwidth Adaptation (ABBA) for CUBIC and Cuback

[kazuho]

Problem

Radio paths violate an assumption CUBIC depends on: that available bandwidth is roughly stable. Radio quality varies, and handover between stations or satellites moves capacity in steps. When capacity drops the queue overflows; when it recovers the flow is left well under the pipe, and CUBIC's cubic-curve recovery is too slow to climb back before the next disturbance.

What's needed is to increase CWND faster whenever the flow is demonstrably below the pipe.

The same condition — an empty queue while the flow is not the constraint — is what random loss also produces, so the mechanism additionally mitigates underutilization on lossy paths. On a lossy Corporate_WiFi profile CUBIC holds 46.7% of link goodput at 5% loss-per-RTT and 34.3% at 10%.

Approach

ABBA combines two ideas.

1. Increase rapidly while RTT sits at the floor. When the latest RTT is at its minimum and being driven down, the bottleneck queue is empty and the flow is not the constraint. ABBA adds a second growth term alongside the CUBIC/Cuback curve and takes the larger of the two, at max(2ms / rtt_threshold, 2.5%) per RTT — about 2 ms of additional queue per round. RTT feedback lags a round, so this self-limits near 4.5 ms of standing queue and stops. The threshold adapts: (minRTT + previous_period_min) / 2, floored at minRTT + 2ms, capped at current_period_min + 2ms.

2. Gate on confirmed queue existence. Acceleration requires prior evidence that this path has a queue to refill: full_rtt — the smoothed RTT captured when the first recovery exits — must exceed minRTT + 10ms and sit more than 5% above the latest RTT.

The gate is not only a safety guard. Because full_rtt is a live estimate of what a full queue looks like, it also drives the second recovery mechanism: if smoothed RTT stays below (minRTT + full_rtt) / 2 for twice the time a non-losing CUBIC flow would need to rebuild the queue, the path characteristics may have changed. The controller retains CWND, discards the CA trajectory, and re-enters slow start to re-learn full_rtt.

That second path is what carries the design under frequent loss, where the flow never rebuilds a queue on its own and the RTT gate alone has nothing to work with. It is directly visible in the policy comparison: LTE CUBIC standalone at 10% loss/RTT reaches 90.6% with recalibration enabled and 80.6% without.

ECN-CE counts as a high-queue observation, including marks received inside a recovery period.

Safety: increase-side only

ABBA never suppresses, defers, or scales a congestion response. Every loss and every CE mark produces the same multiplicative decrease as stock CUBIC/Cuback. beta is derived solely from the controller type and whether the signal was ECN; nothing on the reduction path is conditioned on ABBA state or policy.

This is deliberately not a random-loss classifier. A classifier decides a loss was non-congestive and withholds the reduction, which stakes correctness on the classification being right — and it is wrong precisely when real congestion resembles random loss. ABBA declines that trade: it buys recovery entirely on the increase side and pays full price on every signal. The consequence is that a misfiring RTT gate on some path nobody simulated costs one round of over-growth followed by a normal decrease, rather than a missed congestion response. The bound holds by construction, not by calibration.

The same invariant covers the capacity drop described above: the reduction path is untouched, so the resulting queue overflow produces the standard response, with ABBA contributing at most its ~4.5 ms of extra queue at the moment of the drop.

Recalibration re-enters slow start from a large CWND, which needs its own argument. It is gated on the absence of queue pressure from any source: last_high_queue_at is refreshed whenever smoothed RTT reaches the midpoint between minRTT and full_rtt, and whenever a CE mark arrives, so the timer matures only after sustained evidence that neither the flow itself nor any competitor is queueing at the bottleneck. The wait is measured in CUBIC's own units — high_rtt_interval is how long a flow at this window scale takes to climb back from a reduction and refill the queue — and recalibration needs twice that to pass untouched. CUBIC would have filled the pipe twice over; nothing did.

Design criteria and results

Simulator, 18 network profiles × {tail-drop, CoDel}. Loss probability is set so a full pipe sees at least one loss per RTT with the stated probability. Standalone: 7×100 s runs measuring the last 50 s. Competition: 7×160 s per flow order measuring the last 80 s. Self-competition: 5×320 s, final 40 s window. Full tables are in the commit messages of 2766165 (0x2) and 2a2cde1 (0x1).

On par with stock when the network is stable and lossless. Clean-path competition against stock sits at parity on every profile; the widest deviations are Corporate_WiFi 58.1/44.1 and WiFi@Office 53.3/45.3, both inside the stock-vs-stock baseline spread. On the shallow synthetic queues the gate correctly keeps acceleration off entirely: queue5ms 49.6/49.6, queue2.5ms 51.0/50.8.

Recovers quickly under random loss (standalone goodput, stock → ABBA, tail-drop):

Profile	CUBIC 5%	CUBIC 10%	Cuback 5%	Cuback 10%
Corporate_WiFi	46.7 → 97.5	34.3 → 97.1	55.1 → 97.6	34.4 → 97.3
WiFi@Office	72.5 → 97.7	51.6 → 97.7	72.4 → 97.7	50.0 → 97.7
5G	60.6 → 95.0	39.9 → 90.7	64.7 → 96.7	43.3 → 93.5
Home_WiFi	51.7 → 93.8	36.5 → 88.4	51.9 → 95.6	35.9 → 91.0
LTE	89.0 → 95.1	62.9 → 90.6	89.6 → 97.3	67.6 → 94.4
LEO	80.1 → 95.8	53.4 → 91.3	75.3 → 97.5	56.9 → 94.7

Stays below a competing stock flow that is not experiencing loss. This was a design criterion, and it is met with margin: a lossy ABBA flow against a clean stock flow takes 17–49% across all profiles — never parity. Ten clean CUBIC flows against one ABBA flow on DSL (15 repetitions, mean of flow-order medians): the ABBA flow takes 10.21% with no loss and 9.62% at 5% loss/RTT, against a 10% fair share.

Self-converges. When loss is rare the gates stay shut and behavior reduces to stock, which converges; acceleration is additionally self-limiting, since a flow that opens its gate builds queue and closes it again. When loss is frequent, recalibration is the convergence driver — both flows re-probe symmetrically. Self-competition at 5% loss gives medians near 50% with 85–98% utilization across all profiles.

Policy flags

quicly_context_t::accel_adaptation replaces the earlier boolean. Default is 0 (off).

Flag	Value	Behavior
QUICLY_CC_ACCEL_ADAPTATION_INCREASE_ALWAYS	0x1	Bypasses the full_rtt guard; adaptive RTT gate still applies
QUICLY_CC_ACCEL_ADAPTATION_RECALIBRATE	0x2	Observes full_rtt, enables recalibration, and (unless 0x1) uses full_rtt as the increase guard
QUICLY_CC_ACCEL_ADAPTATION_ON	= 0x2	Recommended setting; what simulator -T selects

full_rtt and high-queue observations are maintained regardless of policy; the flags govern only how they are consumed. 0x1 drops both roles of the gate at once — it is weaker standalone under heavy loss (LTE CUBIC 80.6% vs 90.6% at 10%/RTT, for the reason above) and on the synthetic queue5ms/queue2.5ms profiles takes 63–77% share against stock. Those profiles are stress cases rather than representative access-network queues, but they show what the gate is buying.

Open items

• All results are from the simulator, which is not a real network. Its bottleneck rate is fixed, so the bandwidth-step case that motivates the design is argued from mechanism rather than demonstrated; beyond that it does not model correlated radio loss, ACK aggregation, or real cross traffic. Real-network validation is pending.
• 0x3 has unit coverage but no benchmark run.
• -T takes no argument, so 0x1/0x3 aren't selectable from the simulator; the 0x1 figures come from a separate always-increase build.
• Competition between lossy ABBA flows at different RTTs is untested. The increase rate targets an absolute queue depth (2 ms per round), so in wall-clock terms a short-RTT flow builds queue faster than a long-RTT one; whether this compounds CUBIC's existing RTT bias is an open question. Flows not experiencing non-congestive loss are unaffected, the gates keeping them on the stock trajectory.
• If the path's idle RTT rises during a connection, ABBA as implemented becomes less effective: the increase gate cannot rise above (rtt->minimum + min_rtt_previous_period) / 2, and rtt->minimum only ever moves down.
• All competition data is against stock CUBIC/Cuback. Behavior against BBR — a realistic peer on these paths, and one that deliberately drains the queue — is untested.

Closes #687.

[kazuho]

• If the path's idle RTT rises during a connection, ABBA as implemented becomes less effective: the increase gate cannot rise above (rtt->minimum + min_rtt_previous_period) / 2, and rtt->minimum only ever moves down.

FWIW, as to this point, I think tracking the EMEA of per-epoch minimum and using its (smoothed - variance / 2) + 2ms as a gate could make sense, though I'm not sure how much that'd be an improvement for HTTP when most connections are short-lived. I'm inclined to test this as-is in prod first, and then try the EMEA variant using the same traffic to confirm that EMEA is no more aggressive.