All posts

QUIC Multipath: Simultaneous Network Paths via RFC 9443

7 min read quicnetworkingmultipathtransport-protocolmobile

QUIC Multipath: Simultaneous Network Paths via RFC 9443

Traditional transport protocols bind a connection to a single network path. When your phone switches from WiFi to cellular, TCP connections break. QUIC improved this with connection migration, allowing a connection to move between paths. But what if you could use both paths at once?

RFC 9443 (published 2024) introduces Multipath QUIC (MPQUIC), enabling a single QUIC connection to send and receive data over multiple network paths simultaneously. This is not merely failover; it is true path aggregation with independent congestion control per path.

The Problem with Single-Path Transport

Consider a mobile device with both WiFi and 5G connectivity. With standard QUIC, you pick one. Connection migration lets you switch between them, but there is a disruption window where in-flight packets on the old path must be retransmitted. You cannot aggregate bandwidth, and you cannot proactively prepare a backup path before the primary degrades.

Multipath TCP (MPTCP, RFC 8684) addressed this at the TCP layer, but adoption was limited by middlebox interference, NAT traversal complications, and the inability to encrypt subflow metadata. QUIC's encrypted transport headers and UDP encapsulation sidestep these problems entirely.

RFC 9443 Architecture

MPQUIC extends QUIC's existing connection ID mechanism. Each path is identified by a Path ID and carries its own set of connection IDs. The key protocol additions:

Path Establishment

A new path is opened by sending a PATH_CHALLENGE frame on a new local address/port combination. The peer responds with PATH_RESPONSE on the same 4-tuple. Once validated, both endpoints can schedule packets on this path.

Client (WiFi: 192.168.1.5:4433)  ──PATH_CHALLENGE──>  Server
Client (5G:   100.64.0.12:8821)  ──PATH_CHALLENGE──>  Server

Server ──PATH_RESPONSE──> Client (WiFi)
Server ──PATH_RESPONSE──> Client (5G)

# Both paths now active, data flows on either or both

New Frame Types

RFC 9443 introduces two critical frames:

PATH_ABANDON (type 0x15228c06): Signals that a path should be gracefully closed. Outstanding data is retransmitted on remaining paths.

PATH_STANDBY / PATH_AVAILABLE (type 0x15228c07/08): Allows endpoints to signal path preference. A standby path is validated but not actively used for new data unless the primary degrades.

Per-Path Packet Number Spaces

Each path maintains its own packet number space. This is crucial for loss detection: a gap in packet numbers on path 0 does not imply loss of packets sent on path 1. Without this separation, reordering across paths with different RTTs would trigger spurious retransmissions constantly.

Path 0 (WiFi, 20ms RTT):   PKT# 0, 1, 2, 3, 4 ...
Path 1 (5G, 45ms RTT):     PKT# 0, 1, 2, 3 ...

ACK frames are path-scoped: an ACK on path 0 acknowledges only packets sent on path 0.

Scheduling: The Hard Problem

Having multiple paths is easy. Deciding which data goes on which path is where complexity lives. The scheduler must balance several competing objectives:

  1. Minimize head-of-line blocking: If stream data is striped across paths with different RTTs, the receiver may stall waiting for the slower path's contribution.
  2. Maximize throughput: Use all available bandwidth.
  3. Respect congestion signals: Each path has independent congestion state.

Redundant vs. Non-Redundant Mode

MPQUIC supports two scheduling philosophies:

Non-redundant (bandwidth aggregation): Each QUIC frame is sent on exactly one path. Throughput approaches the sum of path bandwidths. Risk: if one path suddenly fails, data in flight on that path needs retransmission.

Redundant: Critical frames (especially initial data, connection control) are duplicated across paths. Latency approaches the minimum of path RTTs for duplicated data. Trades bandwidth for reliability.

A practical scheduler often uses a hybrid: duplicate small latency-sensitive frames, stripe bulk data.

MinRTT Scheduler Implementation

The simplest effective scheduler sends each frame on whichever path has the earliest estimated delivery time:

def schedule_frame(frame, paths):
    best_path = None
    best_delivery = float('inf')
    
    for path in paths:
        if path.congestion_window_available() < frame.size:
            continue
        # Estimated delivery = smoothed RTT + queuing delay
        delivery = path.srtt + (path.bytes_in_flight / path.cwnd) * path.srtt
        if delivery < best_delivery:
            best_delivery = delivery
            best_path = path
    
    if best_path is None:
        # All paths congested, queue for earliest availability
        return queue_for_next_available(frame, paths)
    
    return send_on_path(frame, best_path)

This works well when path RTTs are similar. When they diverge significantly (e.g., 10ms WiFi vs 80ms cellular), it degenerates to using only the fast path. More sophisticated schedulers like BLEST (Blocking Estimation-based Scheduler) account for stream-level head-of-line blocking.

Congestion Control Per Path

Each path runs an independent congestion controller. This is mandatory: applying a single congestion window across paths with different characteristics would either underutilize the fast path or overwhelm the slow one.

However, there is a coupled constraint: the aggregate sending rate across all paths for a given connection should not exceed what a single-path connection would achieve on the best path (the "fairness" principle from RFC 6356, adapted for QUIC). This prevents a multipath connection from starving single-path connections at a shared bottleneck.

The OLIA (Opportunistic Linked Increases Algorithm) coupled congestion control achieves this:

For each path i with loss event:
    cwnd_i = cwnd_i - cwnd_i / 2  # Standard multiplicative decrease

For each path i with ACK:
    # Coupled increase: favor paths with lower RTT and more capacity
    increase_i = (cwnd_i / rtt_i^2) / (sum(cwnd_j / rtt_j) for all j)
    cwnd_i = cwnd_i + increase_i / cwnd_i

This naturally shifts traffic toward lower-RTT, less-congested paths while maintaining aggregate fairness.

Real-World Deployment Patterns

Seamless Handoff (Standby Mode)

The most immediately deployable pattern: maintain a validated standby path on cellular while primarily using WiFi. When WiFi signal degrades (detected via increasing RTT or loss rate), promote cellular to active. The connection never breaks; packets already in flight on WiFi are retransmitted on cellular within one RTT.

Normal operation:
  WiFi (active):    ████████████ data flow
  Cellular (standby): ─── keepalive probes ───

WiFi degrading (RTT spike detected):
  WiFi (active):    ████░░░░ (losses increasing)
  Cellular (active): ░░████████ (absorbing load)

WiFi gone:
  Cellular (active): ████████████ full data flow

CDN Edge Aggregation

For large downloads, a CDN can establish paths to multiple edge PoPs simultaneously. A client in a region equidistant from two PoPs gets aggregated bandwidth from both. The CDN scheduler stripes chunks across PoPs based on measured capacity.

Data Center Multipathing

Within data centers, servers often have multiple NICs on different network fabrics. MPQUIC enables application-layer multipathing without ECMP hash collisions or MLAG complexity. Each QUIC path maps to a different physical NIC, and the transport layer handles load balancing with full visibility into congestion state.

Implementation Status (2025-2026)

Apple's Network.framework supports MPQUIC for iCloud Private Relay, aggregating WiFi and cellular for improved reliability. Cloudflare has experimental support in quiche. The picoquic reference implementation (by one of the RFC authors) provides a complete implementation for testing.

Linux kernel QUIC implementations are tracking RFC 9443, though userspace implementations (via io_uring for packet I/O) remain more agile for rapid iteration.

Limitations and Open Questions

NAT rebinding on idle paths: If a standby path goes idle, NAT mappings may expire. Periodic probes are needed but consume cellular radio budget.

Path quality estimation: Detecting path degradation quickly enough to migrate traffic proactively, without over-reacting to transient jitter, remains an active research problem. Machine-learned path quality predictors (based on RTT variance, loss patterns, signal strength) are being explored.

Receive buffer management: The receiver must buffer out-of-order data from faster paths while waiting for slower-path contributions to complete streams. Buffer pressure increases with RTT disparity.

Key Takeaway

MPQUIC transforms mobile transport from a fragile single-path abstraction into a resilient multi-path system. By leveraging QUIC's encrypted headers (defeating middlebox interference), connection IDs (enabling path multiplexing), and per-path packet numbering (enabling accurate loss detection), it achieves what MPTCP struggled to deploy for a decade. The protocol is standardized, implementations exist, and the primary remaining challenge is scheduler intelligence — choosing the right path for the right data at the right time.