Skip to content

CONCEPT Cited by 1 source

QUIC connection migration

Definition

QUIC connection migration is the QUIC-specific primitive that lets a client change network path — e.g. hand over from Wi-Fi to cellular, or change IP address after a NAT rebinding — without resetting the connection. The QUIC connection identity is a connection ID, not the 4-tuple (src-ip, src-port, dst-ip, dst-port) that TCP uses.

As a result, mobile clients can move between networks with zero re-handshake cost. In TCP-land this is impossible — a 4-tuple change is, by definition, a new connection, requiring a fresh TCP handshake + TLS handshake.

Canonical framing

Zalando (2024-06) is explicit about the comparison:

"QUIC connections are not strictly bound to a single network path. The protocol supports the connection transfer to a new network path, ensuring a low-latency experience when consumers switch from mobile to WiFi. In the case of HTTP, it always requires a 'cold' start." (Source: sources/2024-06-17-zalando-next-level-customer-experience-with-http3-traffic-engineering)

How it works (sketch)

  1. Server issues multiple connection IDs during the handshake; the client can use any of them to identify the connection.
  2. When the client moves to a new network and its packets arrive from a new 4-tuple, the server sees a familiar connection ID and continues the same session — same TLS keys, same stream state, same flow-control windows.
  3. Path validation — before the server commits to the new path, it may require a probe exchange (a PATH_CHALLENGE / PATH_RESPONSE handshake) to confirm the new 4-tuple is reachable, guarding against off-path attackers redirecting traffic.

Why TCP cannot do this

TCP uses the 4-tuple as connection identity, baked into the kernel socket. Any change to the tuple is a different socket, requiring a new SYN/SYN-ACK/ACK cycle (see concepts/tcp-three-way-handshake) plus TLS re-handshake (1–3 RTTs depending on TLS version + resumption state). For a mobile client switching Wi-Fi ↔ cellular every few minutes, this manifests as a noticeable stall.

Proposals like MP-TCP and SCTP tried to address this at the transport layer over the years but didn't achieve broad adoption — Zalando's post cites this as part of the pattern of "focusing on the transport layer only, avoiding end-to- end Web perspective."

Operational impact

  • Streaming media resilience. Video / audio streams over QUIC survive handover without a visible buffering event — important for mobile users whose network is frequently in flux.
  • Push / long-poll connections. Any server-push-style connection (Server-Sent Events, WebSockets-over-HTTP/3) benefits directly: a mobile user's notifications keep flowing across network changes.
  • Session cookies and auth tokens. A re-handshake in TCP- land implies a new TLS session; renewing auth state and rebinding per-connection server state (sticky-session routing, per-connection caches) becomes unnecessary with QUIC migration.

Limitations

  • Server support required. Migration works only if both peers implement the path-validation handshake; some QUIC deployments disable migration for security reasons.
  • Load balancers must route by connection ID. An L4 LB that hashes on 4-tuple sends the migrated packet to the wrong backend. Production QUIC deployments use connection-ID-aware LBs (e.g. hashing a server- generated routing prefix inside the connection ID).
  • NAT rebinding timers. Even without an explicit network change, a NAT may rebind the client's external port; QUIC handles this transparently, which is a sub-feature of the same migration primitive.

Seen in

Last updated · 501 distilled / 1,218 read