CONCEPT Cited by 1 source
User-space congestion control¶
Definition¶
User-space congestion control is the QUIC-enabled architectural shift in which the TCP-era kernel-based congestion-control algorithm is relocated into the application library (QUIC implementation / browser / proxy). The congestion controller reads and adjusts the sender's pacing and window using per-packet ACK signals, but everything happens in user memory.
This is the underlying mechanism that lets Cloudflare, Google, Meta, and others deploy differentiated CC algorithms without patching the kernel — and that Zalando's post (2024-06) identifies as the ownership pivot from hardware / OS vendors to browser / library authors (Source: sources/2024-06-17-zalando-next-level-customer-experience-with-http3-traffic-engineering).
Canonical framing¶
"QUIC provides the open architecture for congestion control, whereas TCP implements it on the kernel side of the operating system. QUIC does not aim to standardise the congestion control algorithms, it provides generic signals for congestion control, and the sender is free to implement its own congestion control mechanisms."
"Historically, congestion control was owned by 'hardware' companies — those who developed networking equipment and operating systems. QUIC shifts the ownership, because of user-space implementation, towards 'software' companies — those who own Web-browsers." (Source: sources/2024-06-17-zalando-next-level-customer-experience-with-http3-traffic-engineering)
The three named algorithms on the wiki¶
Zalando's post names three points on the CC algorithm landscape:
- NewReno (1999) — QUIC spec proposes as default; Zalando calls this "confusing" because NewReno has not been the internet's dominant CC algorithm since CUBIC (2008).
- CUBIC (2008) — the actual dominant algorithm for broad internet traffic; Linux kernel default since 2006; window-based, bandwidth- probing.
- BBR (2016) — model- based (estimates bottleneck bandwidth + RTT rather than inferring loss); Zalando names it as the CC algorithm that "can satisfy the typical 5G requirements" and expects "it can be expected to become the dominant algorithm in the future."
The ownership shift enables rapid deployment of new algorithms: BBR's original rollout at Google was user-space; BBRv2/BBRv3 iterations land in browser/proxy releases rather than kernel releases; experimental Deep-RL CC algorithms (Aurora, Eagle, Orca, PQB) can be evaluated in production A/B tests without a kernel change.
Costs¶
User-space CC is not free:
- Per-packet kernel-crossing overhead. Every incoming
UDP datagram causes a syscall boundary cross unless the
stack uses batched APIs (
recvmmsg/sendmmsg) or kernel- bypass (DPDK / XDP). - User-space packet copies. ACK / segment data must be copied from kernel buffers into user memory for the CC controller to see; Zalando cites Facebook's published gotchas including a "Linux-kernel UDP-packet-processing bottleneck" on the receive path.
- No shared kernel telemetry. Kernel TCP on Linux
produces
tcp_infostatistics usable for fleet-level monitoring; user-space QUIC CC has to emit its own telemetry, and each implementation chooses its own schema.
Why "open architecture" matters¶
QUIC standardises only the signalling needed for a CC controller (ACK information, RTT samples, loss indicators). It deliberately does not mandate an algorithm. This is the protocol-level analogue of giving platform teams the freedom to run differentiated CC variants tuned to their workload:
- 5G-aware CC (Zalando's driving case) — NewReno and CUBIC misinterpret 5G-radio-layer noise as congestion; BBR does not.
- Low-RTT-datacenter CC — DCQCN / Swift / HPCC variants run inside datacentre fabrics.
- Video-streaming CC — latency-sensitive pacing (e.g. BBR-style with prioritisation) that prefers low queuing delay over throughput maximisation.
- Deep-RL CC — Deep Reinforcement Learning CC algorithms (Aurora, Eagle, Orca, PQB) learn a pacing policy from experience. User-space implementation is what makes these runnable in production.
Wiki framing¶
User-space CC is the property of QUIC that turns congestion control from a kernel feature into a competitive engineering surface. It is the infrastructural precondition for the CC algorithm diversity this wiki catalogues — without it, only what's in the kernel ships to clients.
Seen in¶
- sources/2024-06-17-zalando-next-level-customer-experience-with-http3-traffic-engineering — canonical wiki instance. Zalando frames user-space CC as the ownership pivot from hardware/OS vendors to software vendors, and positions it as the reason Deep-RL-for-CC research is economically feasible.
Related¶
- concepts/quic-transport — the transport whose user-space design makes CC mutable.
- concepts/cubic-congestion-control — the dominant internet CC algorithm.
- concepts/bbr-congestion-control — the 5G-ready CC algorithm.
- concepts/newreno-congestion-control — QUIC's formal default; Zalando calls this choice confusing.
- concepts/deep-reinforcement-learning-congestion-control — the innovation surface user-space CC unlocks.
- patterns/user-space-transport-over-kernel — the broader pattern user-space CC is an instance of.