Computer NetworksQUIC Protocol

QUIC Protocol: The Next Generation Transport

LevelAdvanced

Duration75 mins

TopicQUIC Protocol

3 / 5

Connection Migration

Connections That Follow You

Imagine watching a video while walking from your home to a café. Your phone transitions from home Wi-Fi to cellular data to the café's Wi-Fi. With TCP, each network change forces all your connections to restart—the video buffers, your SSH session dies, your file download begins again from scratch. With QUIC, the connection silently migrates across networks, and you never notice the transition.

Connection migration is one of QUIC's most transformative features. By identifying connections via Connection IDs rather than the traditional IP address and port 4-tuple, QUIC decouples connection identity from network topology. A connection is no longer "this IP:port talking to that IP:port"—it's an abstract relationship that can traverse the network layer.

What You Will Learn

By the end of this page, you will understand why TCP connections are fundamentally bound to IP addresses and ports, how QUIC's Connection ID mechanism enables migration, the security challenges of migration and how path validation addresses them, active versus passive migration scenarios, and real-world performance benefits on mobile networks.

TCP's Address-Bound Problem

To appreciate connection migration, we must first understand why TCP connections cannot survive address changes.

The TCP 4-Tuple:

A TCP connection is uniquely identified by four values:

Source IP address
Source port
Destination IP address
Destination port

This 4-tuple is used everywhere: by the kernel to route incoming packets to the correct socket, by NATs to maintain translation state, by firewalls to track allowed connections, and by load balancers to route traffic consistently.

When any element of this 4-tuple changes, the connection ceases to exist from the perspective of every network device. There is no mechanism in TCP to signal "this is the same connection with a different address."

TCP Connection Identifiers
Component	Example	What Happens on Change
Source IP	192.168.1.5	Packets from new IP are ignored; connection times out
Source Port	49152	Return packets cannot be delivered; connection hangs
Destination IP	93.184.216.34	Packets routed to wrong server; connection fails
Destination Port	443	Wrong service receives packets; connection rejected

Scenarios That Break TCP Connections:

Common TCP Connection Killers

•Wi-Fi to Cellular handoff — Phone switches from home Wi-Fi (192.168.1.5) to cellular (carrier-assigned IP). Source IP changes; all TCP connections die.
•NAT rebinding — Carrier performs NAT; after idle period, NAT mapping expires. Return packets can't be delivered; connection appears frozen.
•Load balancer failover — Backend server fails; load balancer routes to different server. Connection state doesn't exist on new server; client must reconnect.
•VPN connect/disconnect — Enabling VPN changes source IP. All non-VPN connections break; VPN tunnel itself is disrupted on underlying IP change.
•IPv4/IPv6 preference change — OS prefers IPv6, switches from IPv4. Different IP family means different source IP; connections don't survive.
•Roaming between access points — Moving between Wi-Fi access points in enterprise network. If VLANs differ, IP address changes; connections break.

Multipath TCP: A Partial Solution

Multipath TCP (MPTCP) was designed to address this problem by adding multiple IP addresses to a single connection. However, MPTCP requires kernel support, suffers from middlebox interference, and hasn't achieved broad deployment. QUIC's connection migration works without kernel changes and is deployed at scale today.

Connection IDs: QUIC's Solution

QUIC's fundamental innovation is separating connection identity from network addresses. Instead of the 4-tuple, QUIC connections are identified by Connection IDs (CIDs)—opaque byte sequences chosen by each endpoint.

How Connection IDs Work:

Each QUIC endpoint selects its own Connection ID(s) that the peer must use when sending packets to it. These IDs are:

Endpoint-chosen: The server chooses IDs that the client puts in packets to the server; the client chooses IDs that the server puts in packets to the client.
Routing-oriented: IDs can encode routing information (load balancer hash, server identity) to ensure packets reach the right endpoint.
Collision-resistant: IDs are typically 8+ bytes of random data, making conflicts astronomically unlikely.
Multiple per connection: Each endpoint can issue multiple IDs for the same connection, allowing rotation for privacy or routing flexibility.

Connection ID in Packet Headers
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
QUIC Packet with Connection ID:
================================
 
Short Header Packet (post-handshake):
┌──────────────────────────────────────────────────┐
│ Flags (1 byte)                                   │
│   0: Header Form = 0 (short header)              │
│   1: Fixed Bit = 1                               │
│   2: Spin Bit                                    │
│   3-4: Reserved                                  │
│   5: Key Phase                                   │
│   6-7: Packet Number Length                      │
├──────────────────────────────────────────────────┤
│ Destination Connection ID (variable, 0-20 bytes)│
│   Example: 0x1a2b3c4d5e6f7a8b                    │
│   (placed here by sender; chosen by receiver)   │
├──────────────────────────────────────────────────┤
│ Packet Number (encrypted, 1-4 bytes)             │
├──────────────────────────────────────────────────┤
│ Encrypted Payload                                │
│   (frames: STREAM, ACK, etc.)                    │
└──────────────────────────────────────────────────┘
 
Key insight: The Destination Connection ID identifies the connection
regardless of what source IP:port the packet arrived from.
 
When client's network changes:
  Old path: 192.168.1.5:54321 → 93.184.216.34:443  
  New path: 10.0.0.17:61234 → 93.184.216.34:443
  
  Same CID: 0x1a2b3c4d5e6f7a8b
  Server recognizes: This is the same connection!

Converting Mermaid diagram...

Connection ID Negotiation:

During the handshake, each endpoint tells the other which Connection ID to use:

Client generates an initial random CID for the server (used in first packet)
Server responds with its chosen CID (may differ from client's initial choice)
Both endpoints can issue additional CIDs via NEW_CONNECTION_ID frames
Either endpoint can request the peer retire old CIDs via RETIRE_CONNECTION_ID frames

This flexibility supports various deployment patterns:

Load balancers can encode server identity in CIDs for routing
Privacy-conscious deployments can rotate CIDs frequently
Migration-heavy scenarios can pre-provision multiple CIDs

Path Validation: Securing Migration

Connection migration introduces a serious security concern: an attacker could send packets with a valid Connection ID but from a different source address, potentially hijacking the connection or launching amplification attacks. QUIC addresses this through path validation.

The Attack Scenario:

Without path validation, an attacker who observes your Connection ID could:

Send packets to the server claiming to be from a victim's IP address
Server, seeing a valid CID, would "migrate" the connection to the victim
Server sends all response traffic to the victim (amplification attack)
Legitimate client is disconnected; victim is flooded

QUIC's Defense: PATH_CHALLENGE and PATH_RESPONSE:

When a QUIC endpoint receives a packet from a new source address, it doesn't immediately trust the migration. Instead, it validates that the peer actually controls the new address:

Path Validation Protocol
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
Path Validation Process:
========================
 
Step 1: Server detects potential migration
  - Receives packet with valid CID from new source 10.45.2.100:62000
  - Previous source was 192.168.1.5:50000
  - Server does NOT immediately switch to new path
 
Step 2: Server sends PATH_CHALLENGE to new address
  PATH_CHALLENGE Frame {
    Type: 0x1a
    Data: <8 random bytes, e.g., 0x7f82a3b4c5d6e7f8>
  }
  
  This packet is sent to 10.45.2.100:62000
  Server keeps using old path for other traffic
 
Step 3: Client proves it can receive at new address
  - Client receives PATH_CHALLENGE at 10.45.2.100
  - This proves client actually has that address
  - Client responds with PATH_RESPONSE:
  
  PATH_RESPONSE Frame {
    Type: 0x1b
    Data: 0x7f82a3b4c5d6e7f8  (echo of challenge)
  }
 
Step 4: Server validates and migrates
  - PATH_RESPONSE echoes correct challenge data
  - Server now trusts the new path
  - Server updates path to 10.45.2.100:62000
  - Congestion control may be reset for new path
 
Security properties:
- Attacker cannot receive PATH_CHALLENGE at spoofed address
- Without PATH_RESPONSE, migration doesn't complete
- Amplification limited: only challenge packets go to new address
- Existing connection continues on old path until validation succeeds

Path Validation Properties

•Non-amplifying — During validation, the server sends only one PATH_CHALLENGE (small) in response to the suspicious packet. No amplification is possible.
•Unpredictable — The 8-byte challenge data is random. An attacker cannot guess the correct PATH_RESPONSE.
•Authenticating — Only the legitimate client (who has the connection's encryption keys) can decrypt the packet and read the challenge.
•Non-blocking — Existing traffic continues on the old path. Migration completes in the background without stalling the connection.
•Bidirectional — Both endpoints validate new paths. If the server's address changes, the client performs the same validation.

NAT Rebinding vs Attack

A legitimate NAT rebinding (where the NAT assigns the client a new external port) looks similar to an attack—same client IP, different port. QUIC treats both the same way: validate before trusting. This adds ~1 RTT latency to NAT rebinding recovery, but ensures security. The client continues sending from the new path while awaiting validation.

Proactive Connection Migration

Migration isn't always reactive (responding to network changes). QUIC supports proactive migration, where an endpoint deliberately moves a connection to a different network path. This enables sophisticated multi-path and failover scenarios.

Use Cases for Proactive Migration:

Proactive Migration Scenarios

•Preferred network available — Device switches from metered cellular to free Wi-Fi. Client proactively migrates to save data costs.
•Better path detected — Client measures lower latency on cellular than on congested Wi-Fi. Proactive migration improves performance.
•Battery optimization — Wi-Fi typically uses less power than cellular. Device can migrate long-lived connections to Wi-Fi when available.
•Anticipatory handoff — Mobile OS predicts upcoming network loss (leaving Wi-Fi range). Proactive migration before disconnection prevents stall.
•Load balancing — Server-side, a load balancer might migrate connections to different backend servers (with coordinated CID management).
•IPv4/IPv6 preference — Client prefers IPv6 but connected via IPv4. Once IPv6 resolves, client migrates.

Proactive Migration Protocol:

When an endpoint wants to proactively migrate:

Client-Initiated Proactive Migration
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
Proactive Migration Flow (Client → New Network):
================================================
 
Initial state:
  Connection established on Wi-Fi (192.168.1.5)
  Server CID: 0xABCD...
  Client CID: 0x1234...
 
Client detects cellular is preferred:
  - Wi-Fi congested, cellular has lower RTT
  - Client decides to migrate proactively
 
Step 1: Client prepares new path
  - Binds new socket on cellular interface (10.45.2.100)
  - May request new Connection ID from server if privacy desired:
    Send NEW_CONNECTION_ID to request more CIDs
    Receive NEW_CONNECTION_ID frames with fresh CIDs
 
Step 2: Client initiates migration
  - Sends packet from new address (10.45.2.100:62000)
  - Uses same (or fresh) server CID: 0xABCD...
  - Packet contains PATH_CHALLENGE (client wants bidirectional validation)
 
Step 3: Server receives from new address
  - Detects: valid CID, new source address
  - Enters path validation for new address
  - Sends PATH_RESPONSE (for client's challenge)
  - Sends PATH_CHALLENGE (server's own validation)
 
Step 4: Mutual validation completes
  - Client sends PATH_RESPONSE from 10.45.2.100
  - Server confirms: new path is valid
  - Both endpoints update preferred path
  - Congestion state may be reset for fair competition on new path
 
Step 5: Connection continues on new path
  - Old path can be probed occasionally (backup)
  - No interruption visible to application

Connection ID Rotation for Privacy

When migrating, using the same Connection ID links the old and new paths to a network observer. For privacy-sensitive scenarios, clients can request new CIDs before migration and use a fresh CID on the new path. This prevents passive correlation of migration events. The NEW_CONNECTION_ID frame supports this pre-provisioning.

Connection ID Management

Managing Connection IDs is more complex than it first appears. Multiple CIDs may be active for a single connection, CIDs must be rotated for privacy, and load balancers may encode routing information in CIDs. QUIC provides a complete CID lifecycle management system.

NEW_CONNECTION_ID Frame:

Endpoints issue new Connection IDs using the NEW_CONNECTION_ID frame. This allows:

Pre-provisioning CIDs for future migrations
Replacing CIDs that might be compromised (observed by attacker)
Rotating CIDs for location privacy
Issuing CIDs with different routing properties

NEW_CONNECTION_ID Frame Structure
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
NEW_CONNECTION_ID Frame:
========================
 
NEW_CONNECTION_ID {
  Type: 0x18
  
  Sequence Number (variable):
    # Unique sequence for each issued CID
    # Used for ordering and retirement
    # Example: 0x0004 (this is the 5th CID issued: 0,1,2,3,4)
  
  Retire Prior To (variable):
    # All CIDs with sequence < this should be retired
    # Example: 0x0002 (retire CIDs 0 and 1)
  
  Length (8 bits):
    # Length of Connection ID in bytes
    # Example: 0x08 (8-byte CID)
  
  Connection ID (variable):
    # The actual Connection ID bytes
    # Example: 0x1a2b3c4d5e6f7a8b
  
  Stateless Reset Token (128 bits):
    # Token to trigger stateless reset if endpoint
    # loses connection state but receives this CID
    # Example: 0x000102030405060708090a0b0c0d0e0f
}
 
Example sequence of NEW_CONNECTION_ID frames:
 
Frame 1: Seq=0, Retire=0, CID=0xAAAA..., Token=...
Frame 2: Seq=1, Retire=0, CID=0xBBBB..., Token=...
Frame 3: Seq=2, Retire=0, CID=0xCCCC..., Token=...
Frame 4: Seq=3, Retire=2, CID=0xDDDD..., Token=...
  # This frame says: here's CID 3, and please stop using CIDs 0 and 1
 
After Frame 4:
  Active CIDs: 0xCCCC... (seq 2), 0xDDDD... (seq 3)
  Retired CIDs: 0xAAAA... (seq 0), 0xBBBB... (seq 1)

RETIRE_CONNECTION_ID Frame:

The peer can also request retirement of specific CIDs it no longer needs:

Connection ID Lifecycle
State	Description	Transition Event
Issued	CID created, sent in NEW_CONNECTION_ID	Endpoint generates new CID
Active	Peer is using this CID in packets	Peer starts sending with this CID
Pending Retirement	Retire Prior To covers this CID	Newer CID with higher Retire Prior To received
Retired	CID no longer valid for incoming packets	RETIRE_CONNECTION_ID received or Retire Prior To passed
Stateless Reset	Connection state lost; CID triggers reset	Endpoint receives CID without state, returns reset token

CID Management Best Practices

•Provision ahead — Issue multiple CIDs early in the connection so migrations don't require round trips for new CIDs.
•Rotate for privacy — When migrating networks, use a fresh CID to prevent correlating old and new paths.
•Honor retirement — When Retire Prior To advances or RETIRE_CONNECTION_ID arrives, stop accepting packets with old CIDs after a brief grace period.
•Limit active CIDs — Don't issue unlimited CIDs (memory consumption). The active_connection_id_limit transport parameter bounds this.
•Stateless reset tokens — Always include reset tokens so endpoints can recover from state loss without waiting for timeout.

Migration and Congestion Control

When a connection migrates to a new network path, the congestion control state becomes problematic. Parameters like CWND, ssthresh, and RTT estimates were learned for the old path—a different network with potentially different characteristics.

The Dilemma:

Keep old parameters: Risk congesting the new path if it has lower capacity than the old path.
Reset completely: Suffer slow start again, even if the new path is better than the old one.

QUIC's Approach:

QUIC recommends resetting congestion control state on path migration, treating the new path as a fresh connection. This is conservative but safe—it ensures QUIC doesn't overload an unknown path.

Specifically, RFC 9002 recommends:

Reset CWND to initial window (typically ~14KB)
Preserve RTT estimate initially (may be updated)
Begin slow start on new path
Old path's congestion state can be saved (for potential return)

Congestion State on Migration
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
Congestion Control Migration Behavior:
======================================
 
Before migration (Old path: Wi-Fi, 50ms RTT, 10 Mbps):
  CWND: 150,000 bytes (grew during connection)
  ssthresh: 80,000 bytes
  Smoothed RTT: 52ms
  RTT Variance: 8ms
  
Migration occurs to new path (Cellular, 80ms RTT, 5 Mbps):
  
Option 1: Full Reset (Recommended for safety)
  CWND: 14,720 bytes (initial window)
  ssthresh: infinity (start fresh slow start)
  Smoothed RTT: keep or reset to old value
  RTT Variance: reset
 
Option 2: Careful Preservation (Some implementations)
  CWND: min(old_cwnd, initial_window * 2)
  Goal: Don't congest new path, but don't start at zero
  
Option 3: Path-aware (Advanced)
  If returning to previous path, restore saved state
  If new path, probe capacity before ramping up
 
Path validation adds ~1 RTT before normal data flow:
  T=0:    Migration detected
  T=1RTT: PATH_CHALLENGE/RESPONSE complete
  T=1RTT+: Normal data with reset congestion control
  
Recovery timeline (example):
  T=0:      CWND = 14,720 bytes
  T=1RTT:   CWND = 29,440 bytes (slow start, 2×)
  T=2RTT:   CWND = 58,880 bytes
  T=3RTT:   CWND = 117,760 bytes
  T=4RTT:   Back to pre-migration capacity (~150KB)
 
Impact: ~4 RTTs to recover capacity (~320ms on cellular)
Better than TCP: Connection survives vs full restart (~1sec+)

Multi-Path Considerations

If an endpoint maintains multiple active paths (probing the old path while using the new), it may preserve per-path congestion state. This enables scenarios like: "prefer Wi-Fi when available, but keep cellular path warm for instant failover." The QUIC specification doesn't mandate specific multi-path logic, leaving this to implementation.

Load Balancer Considerations

In production deployments, QUIC connections often terminate at servers behind load balancers. Connection IDs become critical for routing: how does a load balancer route packets to the correct backend server, especially after client migration?

The Challenge:

Unlike TCP, where load balancers can make routing decisions based on the persistent 4-tuple, QUIC's 4-tuple changes on migration. The only stable identifier across migration is the Connection ID.

QUIC Load Balancer Draft (draft-ietf-quic-load-balancers):

The IETF is developing standards for QUIC-aware load balancing. The key insight: encode routing information in Connection IDs.

Load Balancer CID Encoding Strategies

•Plaintext Server ID — First N bytes of CID contain server identifier. Simple but reveals backend topology to network observers.
•Encrypted Server ID — Server ID encrypted with key shared between LB and backends. Load balancer decrypts to route; observers see random bytes.
•Server-generated CID — Each server generates CIDs with consistent prefix/pattern the LB recognizes. Load balancer routes based on pattern matching.
•Consistent Hashing Fallback — If CID doesn't match known pattern, fall back to hashing remaining aspects (destination IP). Useful for initial packets.

Load Balancer CID Encoding Example
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
QUIC Load Balancer CID Structure (example):
============================================
 
Connection ID format with encrypted server routing:
 
┌──────────────────────────────────────────────────────┐
│                   Connection ID                       │
├───────────────┬───────────────┬──────────────────────┤
│ Config ID (1B)│ Server ID (2B)│ Random Nonce (5B)    │
│   (plaintext) │  (encrypted)  │   (plaintext)        │
├───────────────┼───────────────┼──────────────────────┤
│    0x01       │  E(srv47)     │  0x7a8b9c0d1e       │
└───────────────┴───────────────┴──────────────────────┘
 
Config ID (1 byte):
  - Identifies which encryption key/config is in use
  - Allows key rotation without breaking routing
  - 0x01 = current production config
 
Server ID (2 bytes, encrypted):
  - Encrypted identifier of backend server
  - Load balancer decrypts: E(srv47) → 0x002F → Server #47
  - Attacker sees random bytes, can't identify backend
 
Random Nonce (5 bytes):
  - Ensures CID uniqueness even with same server ID
  - Provides entropy for encryption
 
Routing flow:
1. Client sends packet with CID 0x01 XX XX 7a 8b 9c 0d 1e
2. Load balancer extracts Config ID: 0x01
3. Uses config 1's key to decrypt bytes 2-3
4. Decryption yields server ID: 47
5. Routes packet to backend server 47
6. After client migration: same CID, same routing, different source IP

Stateless Resets and Load Balancers

If a backend server restarts and loses connection state, it can send a Stateless Reset using the reset token associated with the CID. The load balancer doesn't need to track this—the token is CID-derived, and any server knowing the derivation secret can generate valid resets. This enables graceful handling of server failures.

Real-World Migration Performance

Connection migration isn't just a theoretical feature—it delivers measurable benefits in production. Let's examine the real-world impact through measurements and case studies.

Google's Measurements:

Google, operating QUIC at scale across YouTube, Search, and other services, has reported significant improvements for mobile users:

Network handoff events reduced video rebuffering by 30%+ on mobile
Wi-Fi to cellular transitions complete in <100ms vs. multi-second TCP reconnects
Mean time to first byte improved on networks with NAT rebinding

Quantifying the Benefit:

Connection Migration Timing Comparison
Scenario	TCP Behavior	QUIC Behavior	Improvement
Wi-Fi → Cellular	Reconnect: ~1000-3000ms (handshake + TLS)	Migration: ~80-150ms (path validation)	~10-20× faster
NAT Rebinding	Connection hangs → timeout: 30-60s	Migration: ~1 RTT (~50-100ms)	~300-600× faster
Cellular → Wi-Fi	App must detect and reconnect: variable	Proactive migration: ~100ms	Seamless vs disruptive
Roaming AP handoff	DHCP + reconnect: 1-5s	Migration (same IP): 0ms	Completely hidden
VPN disconnect	All connections drop	Can migrate if path exists	Depends on scenario

Case Study: Video Streaming

Consider a user watching a video on their phone while walking:

Without QUIC:

Phone leaves Wi-Fi range
TCP connections timeout after 30-60 seconds (or detect faster via keepalive)
App detects disconnection, attempts reconnect
New TCP handshake + TLS: 2-3 RTTs
Application-level session resumption: variable
Video rebuffers, position may be lost
Total disruption: 5-60+ seconds

With QUIC:

Phone leaves Wi-Fi range
First packet from cellular address detected by server
Path validation: 1 RTT (~80ms)
Connection continues with reset congestion control
Video may briefly pause (congestion ramp-up)
Total disruption: <1 second, no rebuffering if buffer remains

User Experience Impact

The difference is qualitative, not just quantitative. TCP network changes are disruptive events users notice and complain about. QUIC migrations are silent transitions users don't perceive. This transforms mobile application usability, especially for real-time applications like video calls, gaming, and live streaming.

Summary: Connection Migration

We've explored QUIC's connection migration capability in depth. Let's consolidate the key concepts:

Key Takeaways

•TCP is bound to addresses — The 4-tuple (src IP, src port, dst IP, dst port) defines TCP connections. Any change terminates the connection.
•Connection IDs decouple identity from topology — QUIC connections are identified by Connection IDs chosen by endpoints, not network addresses.
•Path validation ensures security — PATH_CHALLENGE and PATH_RESPONSE prevent attackers from hijacking connections or launching amplification attacks via spoofed migration.
•Migration can be reactive or proactive — Connections can respond to network changes or proactively move to preferred networks for cost, performance, or power reasons.
•CID management enables privacy and routing — Multiple CIDs per connection support rotation for privacy and encoding for load balancer routing.
•Congestion control resets on migration — New paths are treated conservatively with fresh slow start, preventing congestion on unknown paths.
•Real-world benefits are substantial — Migration reduces handoff disruption from seconds to milliseconds, transforming mobile user experience.

What's next:

With connection migration understood, we'll explore another transformative QUIC feature: 0-RTT Connection Establishment. This capability allows clients to send application data in their very first packet to a previously-visited server, eliminating the round-trip latency that even 1-RTT QUIC handshakes require.

Page Complete

You now understand how QUIC's Connection ID mechanism enables connections to survive network changes that would terminate any TCP connection. You've learned the security measures that protect against migration-based attacks, the lifecycle of Connection IDs, and the real-world performance benefits for mobile users. Next, we'll explore 0-RTT connection establishment and its implications.

3 / 5

Loading learning content...

Computer NetworksQUIC Protocol

QUIC Protocol: The Next Generation Transport

LevelAdvanced

Duration75 mins

TopicQUIC Protocol

3 / 5

Connection Migration

Connections That Follow You

What You Will Learn

TCP's Address-Bound Problem

To appreciate connection migration, we must first understand why TCP connections cannot survive address changes.

The TCP 4-Tuple:

A TCP connection is uniquely identified by four values:

Source IP address
Source port
Destination IP address
Destination port

TCP Connection Identifiers
Component	Example	What Happens on Change
Source IP	192.168.1.5	Packets from new IP are ignored; connection times out
Source Port	49152	Return packets cannot be delivered; connection hangs
Destination IP	93.184.216.34	Packets routed to wrong server; connection fails
Destination Port	443	Wrong service receives packets; connection rejected

Scenarios That Break TCP Connections:

Common TCP Connection Killers

•Wi-Fi to Cellular handoff — Phone switches from home Wi-Fi (192.168.1.5) to cellular (carrier-assigned IP). Source IP changes; all TCP connections die.
•NAT rebinding — Carrier performs NAT; after idle period, NAT mapping expires. Return packets can't be delivered; connection appears frozen.
•Load balancer failover — Backend server fails; load balancer routes to different server. Connection state doesn't exist on new server; client must reconnect.
•VPN connect/disconnect — Enabling VPN changes source IP. All non-VPN connections break; VPN tunnel itself is disrupted on underlying IP change.
•IPv4/IPv6 preference change — OS prefers IPv6, switches from IPv4. Different IP family means different source IP; connections don't survive.
•Roaming between access points — Moving between Wi-Fi access points in enterprise network. If VLANs differ, IP address changes; connections break.

Multipath TCP: A Partial Solution

Connection IDs: QUIC's Solution

How Connection IDs Work:

Each QUIC endpoint selects its own Connection ID(s) that the peer must use when sending packets to it. These IDs are:

Endpoint-chosen: The server chooses IDs that the client puts in packets to the server; the client chooses IDs that the server puts in packets to the client.
Routing-oriented: IDs can encode routing information (load balancer hash, server identity) to ensure packets reach the right endpoint.
Collision-resistant: IDs are typically 8+ bytes of random data, making conflicts astronomically unlikely.
Multiple per connection: Each endpoint can issue multiple IDs for the same connection, allowing rotation for privacy or routing flexibility.

Connection ID in Packet Headers
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
QUIC Packet with Connection ID:
================================
 
Short Header Packet (post-handshake):
┌──────────────────────────────────────────────────┐
│ Flags (1 byte)                                   │
│   0: Header Form = 0 (short header)              │
│   1: Fixed Bit = 1                               │
│   2: Spin Bit                                    │
│   3-4: Reserved                                  │
│   5: Key Phase                                   │
│   6-7: Packet Number Length                      │
├──────────────────────────────────────────────────┤
│ Destination Connection ID (variable, 0-20 bytes)│
│   Example: 0x1a2b3c4d5e6f7a8b                    │
│   (placed here by sender; chosen by receiver)   │
├──────────────────────────────────────────────────┤
│ Packet Number (encrypted, 1-4 bytes)             │
├──────────────────────────────────────────────────┤
│ Encrypted Payload                                │
│   (frames: STREAM, ACK, etc.)                    │
└──────────────────────────────────────────────────┘
 
Key insight: The Destination Connection ID identifies the connection
regardless of what source IP:port the packet arrived from.
 
When client's network changes:
  Old path: 192.168.1.5:54321 → 93.184.216.34:443  
  New path: 10.0.0.17:61234 → 93.184.216.34:443
  
  Same CID: 0x1a2b3c4d5e6f7a8b
  Server recognizes: This is the same connection!

Converting Mermaid diagram...

Connection ID Negotiation:

During the handshake, each endpoint tells the other which Connection ID to use:

Client generates an initial random CID for the server (used in first packet)
Server responds with its chosen CID (may differ from client's initial choice)
Both endpoints can issue additional CIDs via NEW_CONNECTION_ID frames
Either endpoint can request the peer retire old CIDs via RETIRE_CONNECTION_ID frames

This flexibility supports various deployment patterns:

Load balancers can encode server identity in CIDs for routing
Privacy-conscious deployments can rotate CIDs frequently
Migration-heavy scenarios can pre-provision multiple CIDs

Path Validation: Securing Migration

The Attack Scenario:

Without path validation, an attacker who observes your Connection ID could:

Send packets to the server claiming to be from a victim's IP address
Server, seeing a valid CID, would "migrate" the connection to the victim
Server sends all response traffic to the victim (amplification attack)
Legitimate client is disconnected; victim is flooded

QUIC's Defense: PATH_CHALLENGE and PATH_RESPONSE:

When a QUIC endpoint receives a packet from a new source address, it doesn't immediately trust the migration. Instead, it validates that the peer actually controls the new address:

Path Validation Protocol
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
Path Validation Process:
========================
 
Step 1: Server detects potential migration
  - Receives packet with valid CID from new source 10.45.2.100:62000
  - Previous source was 192.168.1.5:50000
  - Server does NOT immediately switch to new path
 
Step 2: Server sends PATH_CHALLENGE to new address
  PATH_CHALLENGE Frame {
    Type: 0x1a
    Data: <8 random bytes, e.g., 0x7f82a3b4c5d6e7f8>
  }
  
  This packet is sent to 10.45.2.100:62000
  Server keeps using old path for other traffic
 
Step 3: Client proves it can receive at new address
  - Client receives PATH_CHALLENGE at 10.45.2.100
  - This proves client actually has that address
  - Client responds with PATH_RESPONSE:
  
  PATH_RESPONSE Frame {
    Type: 0x1b
    Data: 0x7f82a3b4c5d6e7f8  (echo of challenge)
  }
 
Step 4: Server validates and migrates
  - PATH_RESPONSE echoes correct challenge data
  - Server now trusts the new path
  - Server updates path to 10.45.2.100:62000
  - Congestion control may be reset for new path
 
Security properties:
- Attacker cannot receive PATH_CHALLENGE at spoofed address
- Without PATH_RESPONSE, migration doesn't complete
- Amplification limited: only challenge packets go to new address
- Existing connection continues on old path until validation succeeds

Path Validation Properties

•Non-amplifying — During validation, the server sends only one PATH_CHALLENGE (small) in response to the suspicious packet. No amplification is possible.
•Unpredictable — The 8-byte challenge data is random. An attacker cannot guess the correct PATH_RESPONSE.
•Authenticating — Only the legitimate client (who has the connection's encryption keys) can decrypt the packet and read the challenge.
•Non-blocking — Existing traffic continues on the old path. Migration completes in the background without stalling the connection.
•Bidirectional — Both endpoints validate new paths. If the server's address changes, the client performs the same validation.

NAT Rebinding vs Attack

Proactive Connection Migration

Use Cases for Proactive Migration:

Proactive Migration Scenarios

•Preferred network available — Device switches from metered cellular to free Wi-Fi. Client proactively migrates to save data costs.
•Better path detected — Client measures lower latency on cellular than on congested Wi-Fi. Proactive migration improves performance.
•Battery optimization — Wi-Fi typically uses less power than cellular. Device can migrate long-lived connections to Wi-Fi when available.
•Anticipatory handoff — Mobile OS predicts upcoming network loss (leaving Wi-Fi range). Proactive migration before disconnection prevents stall.
•Load balancing — Server-side, a load balancer might migrate connections to different backend servers (with coordinated CID management).
•IPv4/IPv6 preference — Client prefers IPv6 but connected via IPv4. Once IPv6 resolves, client migrates.

Proactive Migration Protocol:

When an endpoint wants to proactively migrate:

Client-Initiated Proactive Migration
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
Proactive Migration Flow (Client → New Network):
================================================
 
Initial state:
  Connection established on Wi-Fi (192.168.1.5)
  Server CID: 0xABCD...
  Client CID: 0x1234...
 
Client detects cellular is preferred:
  - Wi-Fi congested, cellular has lower RTT
  - Client decides to migrate proactively
 
Step 1: Client prepares new path
  - Binds new socket on cellular interface (10.45.2.100)
  - May request new Connection ID from server if privacy desired:
    Send NEW_CONNECTION_ID to request more CIDs
    Receive NEW_CONNECTION_ID frames with fresh CIDs
 
Step 2: Client initiates migration
  - Sends packet from new address (10.45.2.100:62000)
  - Uses same (or fresh) server CID: 0xABCD...
  - Packet contains PATH_CHALLENGE (client wants bidirectional validation)
 
Step 3: Server receives from new address
  - Detects: valid CID, new source address
  - Enters path validation for new address
  - Sends PATH_RESPONSE (for client's challenge)
  - Sends PATH_CHALLENGE (server's own validation)
 
Step 4: Mutual validation completes
  - Client sends PATH_RESPONSE from 10.45.2.100
  - Server confirms: new path is valid
  - Both endpoints update preferred path
  - Congestion state may be reset for fair competition on new path
 
Step 5: Connection continues on new path
  - Old path can be probed occasionally (backup)
  - No interruption visible to application

Connection ID Rotation for Privacy

Connection ID Management

NEW_CONNECTION_ID Frame:

Endpoints issue new Connection IDs using the NEW_CONNECTION_ID frame. This allows:

Pre-provisioning CIDs for future migrations
Replacing CIDs that might be compromised (observed by attacker)
Rotating CIDs for location privacy
Issuing CIDs with different routing properties

NEW_CONNECTION_ID Frame Structure
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
NEW_CONNECTION_ID Frame:
========================
 
NEW_CONNECTION_ID {
  Type: 0x18
  
  Sequence Number (variable):
    # Unique sequence for each issued CID
    # Used for ordering and retirement
    # Example: 0x0004 (this is the 5th CID issued: 0,1,2,3,4)
  
  Retire Prior To (variable):
    # All CIDs with sequence < this should be retired
    # Example: 0x0002 (retire CIDs 0 and 1)
  
  Length (8 bits):
    # Length of Connection ID in bytes
    # Example: 0x08 (8-byte CID)
  
  Connection ID (variable):
    # The actual Connection ID bytes
    # Example: 0x1a2b3c4d5e6f7a8b
  
  Stateless Reset Token (128 bits):
    # Token to trigger stateless reset if endpoint
    # loses connection state but receives this CID
    # Example: 0x000102030405060708090a0b0c0d0e0f
}
 
Example sequence of NEW_CONNECTION_ID frames:
 
Frame 1: Seq=0, Retire=0, CID=0xAAAA..., Token=...
Frame 2: Seq=1, Retire=0, CID=0xBBBB..., Token=...
Frame 3: Seq=2, Retire=0, CID=0xCCCC..., Token=...
Frame 4: Seq=3, Retire=2, CID=0xDDDD..., Token=...
  # This frame says: here's CID 3, and please stop using CIDs 0 and 1
 
After Frame 4:
  Active CIDs: 0xCCCC... (seq 2), 0xDDDD... (seq 3)
  Retired CIDs: 0xAAAA... (seq 0), 0xBBBB... (seq 1)

RETIRE_CONNECTION_ID Frame:

The peer can also request retirement of specific CIDs it no longer needs:

Connection ID Lifecycle
State	Description	Transition Event
Issued	CID created, sent in NEW_CONNECTION_ID	Endpoint generates new CID
Active	Peer is using this CID in packets	Peer starts sending with this CID
Pending Retirement	Retire Prior To covers this CID	Newer CID with higher Retire Prior To received
Retired	CID no longer valid for incoming packets	RETIRE_CONNECTION_ID received or Retire Prior To passed
Stateless Reset	Connection state lost; CID triggers reset	Endpoint receives CID without state, returns reset token

CID Management Best Practices

•Provision ahead — Issue multiple CIDs early in the connection so migrations don't require round trips for new CIDs.
•Rotate for privacy — When migrating networks, use a fresh CID to prevent correlating old and new paths.
•Honor retirement — When Retire Prior To advances or RETIRE_CONNECTION_ID arrives, stop accepting packets with old CIDs after a brief grace period.
•Limit active CIDs — Don't issue unlimited CIDs (memory consumption). The active_connection_id_limit transport parameter bounds this.
•Stateless reset tokens — Always include reset tokens so endpoints can recover from state loss without waiting for timeout.

Migration and Congestion Control

The Dilemma:

Keep old parameters: Risk congesting the new path if it has lower capacity than the old path.
Reset completely: Suffer slow start again, even if the new path is better than the old one.

QUIC's Approach:

QUIC recommends resetting congestion control state on path migration, treating the new path as a fresh connection. This is conservative but safe—it ensures QUIC doesn't overload an unknown path.

Specifically, RFC 9002 recommends:

Reset CWND to initial window (typically ~14KB)
Preserve RTT estimate initially (may be updated)
Begin slow start on new path
Old path's congestion state can be saved (for potential return)

Congestion State on Migration
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
Congestion Control Migration Behavior:
======================================
 
Before migration (Old path: Wi-Fi, 50ms RTT, 10 Mbps):
  CWND: 150,000 bytes (grew during connection)
  ssthresh: 80,000 bytes
  Smoothed RTT: 52ms
  RTT Variance: 8ms
  
Migration occurs to new path (Cellular, 80ms RTT, 5 Mbps):
  
Option 1: Full Reset (Recommended for safety)
  CWND: 14,720 bytes (initial window)
  ssthresh: infinity (start fresh slow start)
  Smoothed RTT: keep or reset to old value
  RTT Variance: reset
 
Option 2: Careful Preservation (Some implementations)
  CWND: min(old_cwnd, initial_window * 2)
  Goal: Don't congest new path, but don't start at zero
  
Option 3: Path-aware (Advanced)
  If returning to previous path, restore saved state
  If new path, probe capacity before ramping up
 
Path validation adds ~1 RTT before normal data flow:
  T=0:    Migration detected
  T=1RTT: PATH_CHALLENGE/RESPONSE complete
  T=1RTT+: Normal data with reset congestion control
  
Recovery timeline (example):
  T=0:      CWND = 14,720 bytes
  T=1RTT:   CWND = 29,440 bytes (slow start, 2×)
  T=2RTT:   CWND = 58,880 bytes
  T=3RTT:   CWND = 117,760 bytes
  T=4RTT:   Back to pre-migration capacity (~150KB)
 
Impact: ~4 RTTs to recover capacity (~320ms on cellular)
Better than TCP: Connection survives vs full restart (~1sec+)

Multi-Path Considerations

Load Balancer Considerations

The Challenge:

Unlike TCP, where load balancers can make routing decisions based on the persistent 4-tuple, QUIC's 4-tuple changes on migration. The only stable identifier across migration is the Connection ID.

QUIC Load Balancer Draft (draft-ietf-quic-load-balancers):

The IETF is developing standards for QUIC-aware load balancing. The key insight: encode routing information in Connection IDs.

Load Balancer CID Encoding Strategies

•Plaintext Server ID — First N bytes of CID contain server identifier. Simple but reveals backend topology to network observers.
•Encrypted Server ID — Server ID encrypted with key shared between LB and backends. Load balancer decrypts to route; observers see random bytes.
•Server-generated CID — Each server generates CIDs with consistent prefix/pattern the LB recognizes. Load balancer routes based on pattern matching.
•Consistent Hashing Fallback — If CID doesn't match known pattern, fall back to hashing remaining aspects (destination IP). Useful for initial packets.

Load Balancer CID Encoding Example
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
QUIC Load Balancer CID Structure (example):
============================================
 
Connection ID format with encrypted server routing:
 
┌──────────────────────────────────────────────────────┐
│                   Connection ID                       │
├───────────────┬───────────────┬──────────────────────┤
│ Config ID (1B)│ Server ID (2B)│ Random Nonce (5B)    │
│   (plaintext) │  (encrypted)  │   (plaintext)        │
├───────────────┼───────────────┼──────────────────────┤
│    0x01       │  E(srv47)     │  0x7a8b9c0d1e       │
└───────────────┴───────────────┴──────────────────────┘
 
Config ID (1 byte):
  - Identifies which encryption key/config is in use
  - Allows key rotation without breaking routing
  - 0x01 = current production config
 
Server ID (2 bytes, encrypted):
  - Encrypted identifier of backend server
  - Load balancer decrypts: E(srv47) → 0x002F → Server #47
  - Attacker sees random bytes, can't identify backend
 
Random Nonce (5 bytes):
  - Ensures CID uniqueness even with same server ID
  - Provides entropy for encryption
 
Routing flow:
1. Client sends packet with CID 0x01 XX XX 7a 8b 9c 0d 1e
2. Load balancer extracts Config ID: 0x01
3. Uses config 1's key to decrypt bytes 2-3
4. Decryption yields server ID: 47
5. Routes packet to backend server 47
6. After client migration: same CID, same routing, different source IP

Stateless Resets and Load Balancers

Real-World Migration Performance

Connection migration isn't just a theoretical feature—it delivers measurable benefits in production. Let's examine the real-world impact through measurements and case studies.

Google's Measurements:

Google, operating QUIC at scale across YouTube, Search, and other services, has reported significant improvements for mobile users:

Network handoff events reduced video rebuffering by 30%+ on mobile
Wi-Fi to cellular transitions complete in <100ms vs. multi-second TCP reconnects
Mean time to first byte improved on networks with NAT rebinding

Quantifying the Benefit:

Connection Migration Timing Comparison
Scenario	TCP Behavior	QUIC Behavior	Improvement
Wi-Fi → Cellular	Reconnect: ~1000-3000ms (handshake + TLS)	Migration: ~80-150ms (path validation)	~10-20× faster
NAT Rebinding	Connection hangs → timeout: 30-60s	Migration: ~1 RTT (~50-100ms)	~300-600× faster
Cellular → Wi-Fi	App must detect and reconnect: variable	Proactive migration: ~100ms	Seamless vs disruptive
Roaming AP handoff	DHCP + reconnect: 1-5s	Migration (same IP): 0ms	Completely hidden
VPN disconnect	All connections drop	Can migrate if path exists	Depends on scenario

Case Study: Video Streaming

Consider a user watching a video on their phone while walking:

Without QUIC:

Phone leaves Wi-Fi range
TCP connections timeout after 30-60 seconds (or detect faster via keepalive)
App detects disconnection, attempts reconnect
New TCP handshake + TLS: 2-3 RTTs
Application-level session resumption: variable
Video rebuffers, position may be lost
Total disruption: 5-60+ seconds

With QUIC:

Phone leaves Wi-Fi range
First packet from cellular address detected by server
Path validation: 1 RTT (~80ms)
Connection continues with reset congestion control
Video may briefly pause (congestion ramp-up)
Total disruption: <1 second, no rebuffering if buffer remains

User Experience Impact

Summary: Connection Migration

We've explored QUIC's connection migration capability in depth. Let's consolidate the key concepts:

Key Takeaways

•TCP is bound to addresses — The 4-tuple (src IP, src port, dst IP, dst port) defines TCP connections. Any change terminates the connection.
•Connection IDs decouple identity from topology — QUIC connections are identified by Connection IDs chosen by endpoints, not network addresses.
•Path validation ensures security — PATH_CHALLENGE and PATH_RESPONSE prevent attackers from hijacking connections or launching amplification attacks via spoofed migration.
•Migration can be reactive or proactive — Connections can respond to network changes or proactively move to preferred networks for cost, performance, or power reasons.
•CID management enables privacy and routing — Multiple CIDs per connection support rotation for privacy and encoding for load balancer routing.
•Congestion control resets on migration — New paths are treated conservatively with fresh slow start, preventing congestion on unknown paths.
•Real-world benefits are substantial — Migration reduces handoff disruption from seconds to milliseconds, transforming mobile user experience.

What's next:

Page Complete

3 / 5