Multipath QUIC (MPQUIC) Overview

• Multipath QUIC (MPQUIC) is an extension of QUIC that enables simultaneous use of multiple network interfaces for enhanced mobility, resilience, and bandwidth aggregation.
• It incorporates per-path congestion control, RTT measurement, and advanced packet scheduling to optimize performance for delay-sensitive and hybrid access applications.
• Design choices in MPQUIC, such as the trade-offs between single and multiple packet number spaces and selective redundancy, illustrate practical challenges in fairness and loss recovery.

Multipath QUIC (MPQUIC) is a multipath extension of QUIC that allows a single logical connection to use multiple network interfaces or validated paths concurrently. It combines QUIC’s UDP-based transport, built-in stream multiplexing, and per-connection encryption with per-path congestion control, RTT measurement, loss recovery, and packet scheduling. In the literature, MPQUIC is motivated by bandwidth aggregation, resilience against path failures, mobility, hybrid access, and delay-sensitive applications, while its concrete behavior is shaped by design choices in packet numbering, acknowledgment semantics, scheduling, redundancy, and fairness control (Noroozi et al., 2023, Coninck, 2021).

1. Protocol model and architectural scope

MPQUIC extends QUIC’s single-path data transmission model by maintaining per-path state for a single connection. The reported implementations track, per path, a congestion window, RTT and loss estimates, and send queues, while continuing to expose QUIC streams to the application (Noroozi et al., 2023). QUIC stream offsets remain absolute, and the transport continues to acknowledge packets rather than byte sequence numbers, which makes multipath design materially different from MPTCP and CMT-SCTP (Coninck, 2021).

A recurring architectural distinction in the MPQUIC literature is the separation between stream scheduling and path scheduling. In the implementation evaluated for congestion window reservation, a stream scheduler decides which stream’s frames to emit next, while a path scheduler selects the path for each outgoing packet (Noroozi et al., 2023). That work reports a default round-robin stream scheduler and adds a priority FIFO stream scheduler that serves retransmissions first, then priority streams in FIFO order, then best-effort streams in FIFO order. It also states that packets carry at most one STREAM frame plus any number of control frames, because mixing multiple streams in one packet is discouraged: a loss would otherwise affect multiple streams (Noroozi et al., 2023).

The protocol’s intended operating environments are broad. The packet-numbering study explicitly positions MPQUIC as a mechanism for mobility for delay-sensitive applications, high-speed train handovers, and hybrid access networks, and argues that QUIC’s built-in encryption mitigates deployment obstacles that affected MPTCP and CMT-SCTP (Coninck, 2021). In Alibaba’s deployment context, the XLINK system was used in Taobao short video, where multipath was reported to reduce tail latency and rebuffering (Tang et al., 2022). This operational diversity helps explain why the MPQUIC literature spans core transport semantics, low-latency scheduling, shared-bottleneck fairness, FEC, and path-aware networking.

2. Packet number spaces, ACK semantics, and recovery logic

One of the central MPQUIC design debates concerns packet number spaces. A single packet number space (SPNS) uses one global application packet number sequence across all paths, whereas multiple packet number spaces (MPNS) maintain one packet number space per path (Coninck, 2021, Tang et al., 2022). In QUIC, packet numbers are not merely identifiers: they feed AEAD nonce computation and underlie ACK generation, RTT estimation, and loss detection. The packet-numbering choice therefore changes the entire control loop.

Under SPNS, packets sent on different paths interleave in one global space. When paths have different RTTs or bandwidths, this produces cross-path reordering at the receiver, inflates ACK ranges, and complicates time-based and reordering-based loss detection (Coninck, 2021). The study based on ns-3 simulations reports that single PNS often accumulates many ACK ranges, and that if implementations cap the number of ACK Blocks, some delivered packets can be acknowledged very late or not at all, causing spurious retransmissions. In a severe heterogeneous two-path case, single-PNS picoquic with Cubic and only 4 ACK Blocks retransmitted more than 70% of application data, with some pieces retransmitted up to 8 times (Coninck, 2021).

MPNS localizes numbering, ACK generation, RTT estimation, and loss detection to each path. ACK_MP frames carry the path identifier alongside acknowledged ranges, and the experiments suggest that this makes performance less dependent on the receiver’s acknowledgment strategy (Coninck, 2021). The same paper notes the main trade-offs: MPNS requires non-zero-length Connection IDs and a nonce construction that incorporates the path identifier as well as the packet number to prevent AEAD nonce reuse across the connection (Coninck, 2021).

Alibaba’s XQUIC technical report provides implementation-level evidence for the same trade-off. In its real-world A/B test over more than 1.5 million request samples, SPNS increased average network time by 0.8% compared to MPNS, while the one-second completion rate showed negligible difference (Tang et al., 2022). For those RPC workloads, SPNS ACK frames averaged 12 Bytes, or about 4.5 ACK ranges, whereas MPNS ACK frames averaged 9 Bytes, or about 2.5 ACK ranges; in controlled emulation, unconstrained SPNS ACK frames could be about 50% larger than MPNS because heterogeneous-path reordering created more ACK holes (Tang et al., 2022). When SPNS ACK suppression was applied with a default limit of 4 ACK ranges, average network time increased by more than 2% versus MPNS and the one-second completion rate dropped by 0.1%, even though SPNS ACK size fell to 6.8 Bytes, 21% smaller than MPNS (Tang et al., 2022).

A common misconception is that the simpler-looking SPNS design is automatically preferable. The reported evidence is more conditional. SPNS preserves compatibility with zero-length Connection IDs and does not require nonce changes, but MPNS keeps per-path recovery logic closer to standard QUIC and is experimentally more resilient to ACK-range limits and heterogeneous-path reordering (Coninck, 2021, Tang et al., 2022).

3. Scheduling, prioritization, and congestion-window reservation

The path scheduler is the main locus of MPQUIC performance differentiation. Common baselines include LowRTT or minRTT scheduling, round-robin striping across paths, and duplication-based schedulers for selected traffic (Noroozi et al., 2023). These choices become more consequential when a connection mixes latency-sensitive and best-effort traffic.

The congestion window reservation (CWR) model addresses precisely that mixed-traffic case. Its key idea is to reserve a portion of a path’s congestion window for priority traffic so that periodically generated, time-critical packets can be sent immediately rather than waiting for ACKs to free window space (Noroozi et al., 2023). For each path $i$, the model defines a total congestion window $cwnd_i$, a reserved portion $c_i^{(r)}$, and a best-effort portion $c_i^{(be)} = cwnd_i - c_i^{(r)}$, with reservation fraction $\alpha_i = c_i^{(r)} / cwnd_i$. In-flight accounting is separated into $inflight_i^{(r)}$ and $inflight_i^{(be)}$. The reservation objective is $c_i^{(r)} \ge B_i^{(r)}$, where $B_i^{(r)}$ is the in-flight budget needed for the next priority batch (Noroozi et al., 2023).

CWR does not alter congestion-control growth rules. It leaves part of the congestion window unused by best-effort traffic, which reduces window growth relative to LowRTT because ACK-triggered additive increase is lower when the window is intentionally not fully utilized (Noroozi et al., 2023). In the reported experiments with RTT $= 50$ ms, one priority source, and priority message sizes of 10 kB, 25 kB, and 50 kB at 50 ms inter-arrival, LowRTT achieved approximately 1333–1350 bytes/RTT growth on both paths, CWR reduced that to approximately 1111–1294 bytes/RTT, and CWR+RED reduced it further to approximately 738–1190 bytes/RTT (Noroozi et al., 2023).

The latency benefit is correspondingly direct. With one priority source at RTT $cwnd_i$0 ms, LowRTT often produced priority message completion times above one one-way delay because priority traffic competed with background traffic for congestion-window space, and losses triggered Early Retransmission. CWR kept priority message completion times clustered around one one-way delay, about 25 ms, whenever reservation succeeded, while CWR+RED further reduced tail latency by recovering some losses through duplication rather than retransmission (Noroozi et al., 2023). In the same setting, the paper notes that Early Retransmission was observed to cost at least $cwnd_i$1 RTT, about $cwnd_i$2 ms (Noroozi et al., 2023).

Selective redundancy formalizes the duplicate-transmission case. If $cwnd_i$3 is the duplication set, with per-path latency $cwnd_i$4 and success probability $cwnd_i$5, then the effective latency and reliability are

$cwnd_i$6

The same work emphasizes the associated costs: increased bandwidth consumption on the duplicated paths, possible fairness impact, and receiver-side reordering if duplicates arrive out of order (Noroozi et al., 2023). It also reports that duplicating all traffic degrades application-level performance and wastes capacity; redundancy is therefore applied only to priority flows or messages (Noroozi et al., 2023). When RTTs are highly asymmetric, such as $cwnd_i$7 ms and $cwnd_i$8 ms, redundancy offers limited benefit because loss on the fast path is often recovered by Early Retransmission before the slow duplicate arrives (Noroozi et al., 2023).

4. Reliability extensions, FEC, and shared-bottleneck adaptation

MPQUIC reliability research proceeds along at least two distinct lines: proactive redundancy or coding for loss recovery, and shared-bottleneck detection for fairness-preserving congestion control.

The FEC extension to QUIC adds a generic FEC frame and supports XOR, Reed–Solomon, and Convolutional Random Linear Codes, with packet-level coding in which whole QUIC packets are treated as source symbols (Michel et al., 2018). In MPQUIC, the paper proposes a HighRB packet scheduler based on remaining congestion-window bytes,

$cwnd_i$9

and weighted random selection over paths using these remaining-byte weights (Michel et al., 2018). The rationale is that lossy paths experience congestion-window reduction, which reduces their selection probability while preserving some probing.

The empirical findings distinguish coding schemes by loss process and latency budget. In single-path scenarios, QUIC-FEC with Reed–Solomon $c_i^{(r)}$0 received all data in more than 35% of cases, whereas UDP never reached 100%; reliable QUIC always received all data but incurred more than 2500 ms of total rebuffering in more than 50% of experiments, while QUIC-FEC had similar rebuffering in less than 10% (Michel et al., 2018). Under bursty losses, Reed–Solomon outperformed RLC for long bursts, while RLC outperformed RS for short bursts and with a 33 ms playback buffer (Michel et al., 2018). In multipath settings, the paper reports that round-robin interleaving can improve Reed–Solomon recovery on homogeneous paths, but HighRB outperforms both single-path and round-robin in most heterogeneous-path cases (Michel et al., 2018).

Shared-bottleneck detection addresses a different problem: whether multiple MPQUIC subflows should use coupled congestion control. The trend-line regression method derives from a TCP fluid model in which, during queue build-up at a bottleneck of capacity $c_i^{(r)}$1,

$c_i^{(r)}$2

so the RTT slope satisfies

$c_i^{(r)}$3

Flows sharing the same bottleneck therefore exhibit similar RTT slope trends during overlapping queue build-up epochs (Zhang et al., 2018).

The implemented algorithm smooths RTT with $c_i^{(r)}$4, groups monotonically nondecreasing RTT segments, merges adjacent groups when the time gap is less than $c_i^{(r)}$5 ms, runs every 5 s, and classifies two flows as sharing a bottleneck when their dominant slope groups overlap or are separated by less than $c_i^{(r)}$6 s and their relative slope difference is at most $c_i^{(r)}$7 (Zhang et al., 2018). The sender switches to coupled LIA when a shared bottleneck is detected and falls back to uncoupled control if no shared signal has been observed for 100 s (Zhang et al., 2018). The reported result is that, with two subflows, LIA combined with trend-line regression shared-bottleneck detection achieved an average 74% throughput gain compared with a single-path connection in non-shared bottlenecks while preserving fairness in shared-bottleneck scenarios (Zhang et al., 2018).

5. Measurement evidence and deployment environments

Measurement studies show that MPQUIC behavior is strongly environment-dependent. In SCIONLab, a four-week longitudinal campaign reports persistent control-plane churn, short path lifetimes, path discrepancy between forward and reverse directions, and a trade-off between aggregate throughput and per-path quality under concurrent multipath use (Herschbach et al., 4 Sep 2025).

For one destination, the study logged 557 path additions and 577 removals over approximately 26 days, or about 21 additions/day and 22 removals/day; for another, it logged 1254 additions and 1259 removals, or about 48 additions/day and 48 removals/day (Herschbach et al., 4 Sep 2025). Average path lifetimes were 15.7 hours and 8.6 hours, respectively (Herschbach et al., 4 Sep 2025). The same study reports path discrepancy such as 20 viable paths in one direction versus 18 in the reverse, and documents data-plane asymmetry: at the 100 Mbps tier, downstream throughput averaged about 87.09 Mbps, while upstream throughput averaged about 65.4 Mbps with approximately 34.6% packet loss (Herschbach et al., 4 Sep 2025). Concurrent multipath transmission consistently improved aggregate throughput relative to any single path, but slightly worsened per-path RTT, jitter, and loss (Herschbach et al., 4 Sep 2025).

The ScionPathML toolkit extends this path-aware perspective with an active-measurement pipeline for SCION. Its longitudinal measurements report that one-step-ahead RTT prediction achieved an MAE of 3.878 ms, bandwidth prediction with LightGBM achieved an MAE of 21.470 Mbps, a Random Forest classifier obtained an F1-score of 0.86 for predicting path unavailability at $c_i^{(r)}$8, and bottleneck localization from per-hop RTT vectors reached 99% accuracy (Rossi et al., 8 Sep 2025). The paper states that concurrent multipath transmissions can improve aggregate throughput but may degrade the latency and reliability of individual paths, and it argues that MPQUIC should explicitly account for high churn and path asymmetry (Rossi et al., 8 Sep 2025).

These observations materially affect transport design. A scheduler that assumes stable path sets or symmetric forward and reverse availability is mismatched to the measured behavior of SCION-like path-aware networks. The measurements suggest separate treatment of data and ACK paths, stability-aware path scoring, and more conservative striping when path skew is large or churn is high (Herschbach et al., 4 Sep 2025, Rossi et al., 8 Sep 2025).

6. Open design tensions and recent research directions

The current MPQUIC literature makes clear that scheduler optimality is not absolute. In a simulated path-aware environment, purely greedy Min-RTT selection produces herd effects under contention: packet loss rises from 2.44 Mbps at 10 agents to 454.24 Mbps at 500 agents, a rise of about 18,520%, while stability falls to $c_i^{(r)}$9 at 500 agents (Baumeister et al., 7 Sep 2025). In the same study, Epsilon-Greedy reaches the highest reported efficiency at high contention, 570.12 at $c_i^{(be)} = cwnd_i - c_i^{(r)}$0, whereas WRR reduces loss relative to Round-Robin and attains fairness $c_i^{(be)} = cwnd_i - c_i^{(r)}$1 with loss 313.57 at $c_i^{(be)} = cwnd_i - c_i^{(r)}$2 (Baumeister et al., 7 Sep 2025). This suggests that MinRTT, while a common MPQUIC baseline, is not a generally stable policy in path-aware environments with many competing agents.

A second tension concerns the relation between scheduling and congestion control. The SAGIN study argues that existing solutions often optimize these subsystems in isolation, which is suboptimal under high mobility, frequent handovers, and severe out-of-order delivery (Liu et al., 3 Mar 2026). Its GPR Hierarchical Synergistic Framework defines an out-of-order degree metric

$c_i^{(be)} = cwnd_i - c_i^{(r)}$3

and optimizes a goodput–OFO objective of the form $c_i^{(be)} = cwnd_i - c_i^{(r)}$4 (Liu et al., 3 Mar 2026). The framework couples a latent-state scheduler (GPASP), a handover-aware congestion controller (PHACC), and a low-latency preference estimator (NNPE). In ns-3, GPASP achieved about 12 Mbps throughput, 2.07% packet loss ratio, and an OFO rate of about 7.78%, while NNPE yielded about 100% improvement in per-decision CPU or wall-clock time relative to NNPE-disabled runs (Liu et al., 3 Mar 2026).

The broader research trajectory is therefore not simply toward “more paths” or “more aggressive striping.” It is toward MPQUIC controllers that reason jointly about packet-numbering semantics, ACK compression and pruning, per-path congestion state, selective redundancy, path similarity, shared bottlenecks, path lifetimes, and receiver reordering. The papers surveyed here collectively indicate that MPQUIC is best understood not as a single mechanism but as a transport framework whose observable properties depend on the interaction between transport semantics and path heterogeneity (Noroozi et al., 2023, Coninck, 2021).