ACE Journal

QUIC Tuning for High-Latency Mobile Networks

Who this is for: backend and mobile platform engineers who already run QUIC or HTTP/3 in production (via a library like Cloudflare’s quiche, Microsoft’s MSQUIC, Google’s quiche, or ngtcp2) and have noticed that mobile clients see worse throughput and slower recovery than the same servers deliver to broadband. The assumption is that you can set transport parameters and congestion-control options in your stack, read QLOG output, and run a controlled test with a network emulator. If you have never touched the congestion controller or the initial window, this is where to start.

The deploy that looked fine until it hit a train

The pattern is familiar to anyone who has shipped a QUIC migration. You move from HTTP/2 over TCP to HTTP/3 over QUIC, benchmark it on the office network and a few cloud regions, and the numbers are clean: faster handshakes, lower tail latency, fewer stalls when a single object is slow. You ship. Then the field telemetry comes back and the mobile cohort, the users on a phone, on a train, in a parking garage, did not get the win. Some got a regression.

The reason is not a bug in QUIC. It is that QUIC’s defaults were chosen for the environment its authors measured most: data centers and home broadband, where round-trip times sit in single or low double-digit milliseconds, packet loss is rare and usually means a full queue, and the path does not change identity mid-download. A high-latency mobile link breaks all three assumptions at once. RTTs of 150 to 300 ms are routine on a congested cell or a satellite-backhauled rural tower. Loss is frequent and bursty, caused by radio fades, handovers, and scheduler hiccups rather than congestion. And the path itself changes when the device roams between towers or hops from cellular to Wi-Fi.

Figure 1 shows where the default assumptions diverge from mobile reality, which is the map for everything that follows.

flowchart TB
    subgraph Defaults[QUIC default assumptions]
        D1[low, stable RTT]
        D2[loss equals congestion]
        D3[stable path / IP]
    end
    subgraph Mobile[high-latency mobile reality]
        M1[high, variable RTT 150-300ms]
        M2[loss is often radio-induced, bursty]
        M3[path changes on roam / handoff]
    end
    D1 -. inflated PTO, slow start dominates .-> M1
    D2 -. loss-based CC backs off needlessly .-> M2
    D3 -. connection drops without migration .-> M3

Figure 1. The three default assumptions QUIC carries from the data center and how each one inverts on a mobile link. Look at the dotted arrows: each broken assumption maps directly to one of the four tuning areas in this article.

The good news is that QUIC was designed to be tuned. Unlike TCP, where the congestion controller lives in the kernel and the knobs are global sysctls, QUIC runs in user space and exposes congestion control, the initial window, timeouts, and loss-recovery behavior as per-connection configuration [1]. That means you can detect a mobile client and hand it a different transport profile than a broadband one, on the same server, without a kernel change. The rest of this article walks the four areas worth tuning, with the configuration for each, then the operational reality of validating them.

Mechanics: the four knobs and why they move

QUIC’s transport behavior on a given path is dominated by four interacting subsystems. Figure 2 shows them as a pipeline from connection establishment through steady-state transfer to recovery, because the order matters: a change to one shifts the load on the next.

flowchart LR
    Handshake[handshake<br/>1-RTT / 0-RTT] --> CC[congestion control<br/>Cubic vs BBRv2]
    CC --> IW[initial window<br/>+ pacing]
    IW --> Steady[steady-state<br/>transfer]
    Steady --> Loss[loss recovery<br/>PTO / RTO]
    Steady --> Mig[idle timeout<br/>+ migration]
    Loss -. retransmit .-> Steady
    Mig -. survive handoff .-> Steady

Figure 2. The four tunable subsystems in the order a connection exercises them. Look at the two feedback arrows into steady state: loss recovery and migration are the subsystems that decide whether a transfer survives the rough parts of a mobile link.

The first knob, congestion control, decides how aggressively to send. The second, the initial window and pacing, decides how much you can send before the first feedback arrives, which on a long-RTT path is a large fraction of a short transfer. The third, idle timeout and migration, decides whether the connection survives the link changing underneath it. The fourth, loss recovery, decides how fast you retransmit when a packet goes missing. Each has a default that is reasonable for broadband and wrong for a 250 ms lossy link. We take them in turn, each anchored by the config that changes it.

Worked example: tuning the four knobs

The examples below use Cloudflare’s quiche [2], because its Rust configuration API is compact and the parameter names map cleanly onto the QUIC RFCs. The same concepts exist in MSQUIC [3], ngtcp2, and Google’s quiche under different names. Everything here is steady-state transport configuration set before the connection is created.

Congestion control: prefer a model-based controller

This is the single highest-leverage change. The default congestion controller in most QUIC stacks is Cubic or a QUIC-native variant of it, inherited from the TCP world. Cubic is loss-based: it treats packet loss as the primary signal of congestion and backs off when it sees loss. That logic is correct in a data center, where a dropped packet almost always means a queue filled up. It is actively harmful on a mobile link, where a large fraction of losses are radio fades, handover gaps, and scheduler drops that have nothing to do with congestion. A loss-based controller reduces its sending rate every time the radio hiccups, so it spends the transfer in an unnecessarily throttled state.

BBRv2 models the path differently. It estimates the available bandwidth and the minimum RTT independently and paces to that estimate, rather than ramping until it sees loss [4][5]. Because it does not equate loss with congestion, a burst of radio-induced loss does not collapse its sending rate the way it collapses Cubic’s. On high-latency, lossy links this is consistently the better default. In quiche it is one setting:

let mut config = quiche::Config::new(quiche::PROTOCOL_VERSION)?;

// Default is CcAlgorithm::CUBIC. BBRv2 models bandwidth and RTT
// independently instead of treating loss as the congestion signal,
// which matches mobile links where loss is often not congestion.
config.set_cc_algorithm(quiche::CongestionControlAlgorithm::BBR2);

The caveat is not subtle: BBRv2 is not a free lunch. It can be less fair to coexisting loss-based flows on a shared bottleneck, and a misconfigured BBR can overshoot a small buffer. The point is not “BBR2 everywhere,” it is “do not let a loss-based controller treat your mobile link’s radio losses as a reason to crawl.” Validate the choice with synthetic loss injection at 2 to 5 percent before you deploy, not just on a clean link, because a clean link will not reveal the behavior that motivated the switch.

Initial window and pacing: fill the long pipe, but pace it

The initial congestion window (initcwnd) is how much data QUIC sends before it has received any acknowledgment. The default is 10 segments in most stacks, roughly 14 KB, a value carried over from TCP convention [6]. On a 250 ms RTT link, that 14 KB is everything you can have in flight for the first quarter-second, because the first ACK does not come back until a full round trip later. For a short transfer, an API response, a small image, the whole exchange can finish in slow start, and a 14 KB opening window means the transfer is RTT-bound rather than bandwidth-bound. The link could have carried far more in that first quarter-second.

Raising the initial window to 20 to 32 segments for detected mobile endpoints lets the first burst do real work before the slow-start ramp begins. The detection itself is a product decision: a network-type hint from the client, a user-agent heuristic, or a connection from a known mobile gateway range. The transport change is small:

// Default initial window is ~10 segments. On a 250ms link the first
// ACK is a quarter-second away, so a larger opening window lets a
// short transfer make progress instead of waiting a full RTT.
config.set_initial_congestion_window_packets(32);

// Pace the larger window. Bursting all 32 packets at once invites
// buffer bloat at the radio scheduler; pacing spreads them at the
// estimated bandwidth so they do not pile up in the RAN buffer.
config.enable_pacing(true);

The pacing line is not optional, and this is where engineers get burned. A larger initial window without pacing means you fire all 32 packets back to back. On an LTE or 5G NR path the radio scheduler has a deep buffer, and an unpaced burst piles into it, inflating the very RTT you are trying to keep low. That is self-inflicted bufferbloat: you made the link slower by trying to use it harder. Pacing spreads the burst at the measured bandwidth estimate so the packets arrive at the scheduler at the rate it can drain them. The larger window and pacing are a pair; ship them together or not at all.

Idle timeout and connection migration: survive the handoff

Mobile connections change paths. A device roams between cell towers, hands off from cellular to Wi-Fi, or loses the radio for a few seconds in an elevator. QUIC’s connection migration is built for exactly this: because a QUIC connection is identified by a connection ID rather than the four-tuple of source and destination IP and port, an in-flight transfer can survive a change of client IP without a new handshake [7]. But migration only helps if the connection is still alive when the path comes back, and that is governed by the idle timeout.

The idle timeout is negotiated as the minimum of what each side advertises [1]. Too short and a brief radio gap kills a connection that migration could have rescued; too long and a dead client holds server resources indefinitely. A common shape is a server that bounds its own exposure at around 10 seconds while still long enough to ride out a typical handoff gap, paired with explicit migration support:

// Negotiated idle timeout is the min of both peers' values.
// Long enough to survive a brief radio gap or handoff, short
// enough that a truly dead client frees server resources.
config.set_max_idle_timeout(10_000); // milliseconds

// Permit the client's address to change mid-connection.
// Without this, a roam to a new IP looks like a different
// connection and the transfer dies instead of migrating.
config.set_active_connection_id_limit(4);
config.set_disable_active_migration(false);

The non-obvious failure here is not in your stack, it is in the network between you and the client. Connection migration changes the source IP of inbound packets, and not every middlebox handles that gracefully. Some carrier-grade NATs and stateful firewalls drop the post-migration packets because they do not match the flow state established at handshake. You can configure migration perfectly and still see it fail in the field on certain carriers. Test it explicitly against real mobile networks, do not assume the spec-compliant behavior survives the path.

Loss recovery: bound the PTO for high RTT variance

When a packet goes missing and there is no later packet to trigger fast retransmit, QUIC falls back to a timer: the Probe Timeout (PTO). The PTO is computed from the smoothed RTT plus a multiple of the RTT variance, with a floor [8]. On a stable broadband path RTT variance is small, so the PTO is tight and retransmits are prompt. On a mobile link RTT variance is large and spiky, so the variance term inflates the PTO, and a lost packet waits a long time before the timer fires. Worse, the default PTO floor of around 1 second is an eternity on an interactive transfer.

Bounding the PTO, both lowering the floor toward 200 to 300 ms and capping how high the variance term can push it, makes recovery prompt on spotty links without making it trigger spuriously on every RTT wobble. Not every library exposes these as direct setters, so the realistic worked example is the calculation you tune and then verify against QLOG, expressed here in Python for clarity:

# RFC 9002 PTO: smoothed_rtt + max(4*rttvar, granularity) + max_ack_delay.
# On mobile, rttvar is large and spiky, so the raw PTO inflates and a
# lost packet waits too long. Bound the floor and cap the variance term.
def pto(smoothed_rtt, rttvar, max_ack_delay,
        granularity=0.001, floor=0.20, cap=2.0):
    base = smoothed_rtt + max(4 * rttvar, granularity) + max_ack_delay
    return min(max(base, floor), cap)  # floor 200ms, cap 2s

# Example: 250ms RTT, high variance. Raw PTO would push well past
# the default ~1s floor; the cap keeps recovery from stalling.
print(pto(0.250, 0.180, 0.025))  # -> 0.995 here, but cap protects spikes

The lesson is to treat these timers as something you calibrate against your own traffic, not a constant you guess. The QLOG events to watch are packet_lost, recovery:loss_timer_updated, and the PTO-driven retransmits; if you see the loss timer expiring far more often than packets are genuinely lost, your floor is too low and you are wasting bandwidth on spurious retransmits. If recovery feels sluggish on lossy links, your floor or cap is too high. There is no universal right value, only the value that fits your RTT distribution.

The hard part: the lab lies, so inject the impairment

Every default in QUIC is validated against a clean link, and so, by reflex, is most of the tuning that engineers do on top of it. That is the trap. The clean link is precisely the environment where none of these changes matter, because on a clean link Cubic does not see spurious loss, the PTO never inflates, and the path never changes. You can tune all four knobs, benchmark them on a good network, see a modest improvement, and ship settings whose entire purpose, surviving bad conditions, was never exercised.

The discipline that separates tuning that works in the field from tuning that works in the demo is impairment injection. Before you trust any of these values, run the connection through a network emulator that reproduces the conditions you are tuning for: high RTT, bursty loss, jitter, and a mid-transfer path change. On Linux, the tc traffic-control subsystem with netem does most of this with no extra software:

# Emulate a high-latency mobile link on the egress interface:
# 250ms one-way delay with 50ms of jitter, and 3% loss arriving
# in bursts (correlation) rather than independently, which is how
# radio loss actually behaves. Clean-link tests never see this.
sudo tc qdisc add dev eth0 root netem \
    delay 250ms 50ms distribution normal \
    loss 3% 25%

# Tear it down after the test run.
sudo tc qdisc del dev eth0 root netem

The loss 3% 25% form is the part that matters and the part people omit. Plain loss 3% drops packets independently, which is the random loss model QUIC’s defaults already assume and the one mobile links do not exhibit. The trailing 25% adds correlation, so losses cluster into bursts, which is what a radio fade or a handover gap actually produces. Tuning that you validate only against independent loss will mis-predict behavior under the bursty loss your users see. Migration you cannot exercise with netem alone; the cleanest way to test it is to actually change the client’s source address mid-transfer (rebind the socket, or move between two interfaces) and confirm the transfer continues. Pair the emulator with QLOG capture on both ends and you can see, rather than guess, whether BBRv2 held its rate through the loss bursts and whether the PTO fired when it should have.

Integration: a mobile transport profile, not a global flip

None of this argues for changing your defaults globally. The broadband cohort is well served by the stock parameters, and BBRv2 fairness concerns and the larger initial window are not obviously wins on a clean fast link. The integration that fits a real service is a per-connection mobile profile, selected at connection time from a hint, that diverges from the broadband default only where the link demands it. QUIC’s user-space, per-connection configuration is what makes this practical, and it is the structural advantage over TCP, where the equivalent would be global kernel sysctls.

fn config_for(profile: LinkProfile) -> quiche::Config {
    let mut c = quiche::Config::new(quiche::PROTOCOL_VERSION).unwrap();
    match profile {
        LinkProfile::Mobile => {
            c.set_cc_algorithm(quiche::CongestionControlAlgorithm::BBR2);
            c.set_initial_congestion_window_packets(32);
            c.enable_pacing(true);
            c.set_max_idle_timeout(10_000);
        }
        LinkProfile::Broadband => {
            // Stock defaults are fine here; do not pay the BBR2
            // fairness cost or the wider window on a clean link.
            c.enable_pacing(true);
        }
    }
    c
}

Selecting the profile is the integration work. A client network-type API, a connection from a known mobile carrier IP range, or a coarse user-agent heuristic each get you most of the way; getting it slightly wrong is low-risk, because the mobile profile is not harmful on broadband, just unnecessary. Wire the QLOG-derived metrics (PTO firings, loss-timer expirations, BBR bandwidth estimate) into the same observability you already run, segmented by profile, so you can see whether the mobile profile is actually helping the cohort it targets. The day-to-day rhythm is: ship the profile to a fraction of mobile traffic, watch the segmented metrics against the broadband control, widen the rollout when the mobile cohort’s tail latency and stall rate improve.

The choices here sit against a few obvious alternatives, and being honest about them matters.

Stay on TCP with BBR and tune the kernel. TCP plus BBR in the Linux kernel is a mature, well-understood path, and for a server talking mostly to broadband it may be the simpler choice. What you give up is exactly the mobile-relevant part: TCP has no connection migration, so a roam or a Wi-Fi-to-cellular handoff resets the connection, and TCP’s congestion control is global to the kernel rather than per-connection, so you cannot hand mobile and broadband clients different profiles on the same box. For a workload dominated by mobile clients on changing paths, that is the gap QUIC was built to close.

Use QUIC but leave the defaults alone. This is the most common real-world position, and it is defensible as a starting point: the defaults are safe and the handshake and head-of-line-blocking wins are real even untuned. The argument of this article is only that on a heavily mobile workload the defaults leave measurable headroom in throughput and recovery, and the cost of capturing it is a per-connection profile plus a disciplined validation pass, not a rewrite.

Reach for a different congestion controller entirely. BBRv2 is not the only model-based option. Earlier BBR versions exist, and there is active research on controllers built specifically for cellular and satellite links [4][9]. The reason to default to BBRv2 here is availability and maturity: it ships in the mainstream QUIC stacks today, and it captures most of the loss-versus-congestion benefit without bespoke code. If you have a controlled environment and the appetite, a cellular-specific controller may do better, but it is a larger commitment than flipping one config value.

None of these substitutes for the validation discipline. Whichever transport and controller you pick, the impairment-injection step is what tells you it works under the conditions you care about, and skipping it is how every one of these options ends up shipping a lab result that does not survive contact with a train.

Where it breaks

The tuning above has honest failure modes, and knowing them up front is most of avoiding them.

BBRv2 unfairness on a shared bottleneck. Model-based controllers can be aggressive against coexisting loss-based flows sharing the same bottleneck. If your traffic competes with a lot of Cubic on a constrained link, BBRv2 may take more than its share, or behave unexpectedly against a shallow buffer. This is a measure-it situation, not a never-use-it one, but it is the reason “BBR2 globally” is the wrong conclusion.

A large initial window without pacing. Covered above and worth repeating because it is the most common self-inflicted wound: a wider initcwnd fired as an unpaced burst inflates RTT at the radio scheduler and can make the link slower than the default would have been. The window and pacing are a single change, never ship one without the other.

Migration killed by middleboxes. A spec-perfect migration configuration still fails on carriers whose NATs or firewalls drop packets after a source-IP change. You will not see this in the lab, only in field telemetry segmented by carrier. Build the observability to detect it, and be ready to fall back to a fresh connection on networks where migration does not survive.

PTO floor set too low. Push the PTO floor down too far and the loss timer fires on ordinary RTT variance, triggering retransmits of packets that were merely late, not lost. That wastes bandwidth and can worsen congestion on the very link you were trying to help. The QLOG loss-timer events are the signal; if they fire far more often than real losses, raise the floor.

Tuning validated only on a clean link. The meta-failure that contains the others. Every value here is invisible on a good network, so a tuning pass that never injects loss, jitter, and a path change measures nothing that matters and ships false confidence. If you take one thing from this article, make it the impairment-injection step.

Over-tuning for one network’s quirks. The opposite trap: chasing the impairment profile of a single carrier or test device so precisely that the settings regress on the broad population. The fix is to validate against a distribution of conditions, not one emulated link, and to keep the broadband profile stock so the changes are scoped to the cohort that needs them.

Further reading

Start with the two core QUIC RFCs: the transport specification [1] for connection IDs, transport parameters, and idle timeout, and the loss-detection and congestion-control RFC [8] for the PTO calculation and the recovery state machine. For the congestion-control choice, the BBR documentation and the IETF congestion-control draft [4][5] explain why a model-based controller behaves differently from a loss-based one under non-congestion loss. The quiche [2] and MSQUIC [3] configuration references show the concrete knobs in two mainstream stacks. For validation, the QLOG schema [10] is what makes the recovery and congestion events legible, and the tc/netem documentation [11] is the standard way to reproduce a bad link on Linux. The initial-window background traces back to the TCP IW10 work [6], and ongoing transport-over-cellular research [9] is the best running source for where this is headed.

Written with AI assistance, editorially reviewed.

References

[1] J. Iyengar and M. Thomson, Eds., “RFC 9000: QUIC, A UDP-Based Multiplexed and Secure Transport.” https://www.rfc-editor.org/rfc/rfc9000.html

[2] Cloudflare, “quiche: Savoury implementation of the QUIC transport protocol.” https://github.com/cloudflare/quiche

[3] Microsoft, “MSQUIC Settings and Configuration.” https://github.com/microsoft/msquic/blob/main/docs/Settings.md

[4] N. Cardwell et al., “BBR Congestion Control (IETF Draft).” https://datatracker.ietf.org/doc/draft-cardwell-iccrg-bbr-congestion-control/

[5] Google, “BBR: Congestion-Based Congestion Control.” https://github.com/google/bbr/blob/master/Documentation/bbr-faq.md

[6] N. Dukkipati et al., “RFC 6928: Increasing TCP’s Initial Window.” https://www.rfc-editor.org/rfc/rfc6928.html

[7] M. Thomson and S. Turner, Eds., “RFC 9001: Using TLS to Secure QUIC.” https://www.rfc-editor.org/rfc/rfc9001.html

[8] J. Iyengar and I. Swett, Eds., “RFC 9002: QUIC Loss Detection and Congestion Control.” https://www.rfc-editor.org/rfc/rfc9002.html

[9] IRTF Congestion Control Research Group, “ICCRG Documents and Cellular Transport Work.” https://datatracker.ietf.org/rg/iccrg/documents/

[10] R. Marx et al., “qlog: Main Logging Schema for QUIC (IETF Draft).” https://datatracker.ietf.org/doc/draft-ietf-quic-qlog-main-schema/

[11] Linux Foundation, “tc-netem: Network Emulator (man page).” https://man7.org/linux/man-pages/man8/tc-netem.8.html