Thread by @programmingart

Day 4 of our deep dive into the freshly standardized #QUIC protocol is about one of its most innovative aspects: connection migration!

This is intended to allow #QUIC connections to survive network changes that are disruptive in TCP.

1/12 #RFC9000

Take the "parking lot problem": you have WiFi on your phone inside, but switch to 4G when going to your car.
This switches networks and client IP/port, so all TCP connections are dropped and re-started, since they're only identified based on client+server IP+port (4-tuple). 2/12

QUIC instead assigns each connection a unique Connection ID (CID) of 1-20 bytes.

By using the same CID even after switching networks, the server knows it's actually the same connection, even though the 4-tuple has changed. 3/12

However, using the same CID across networks would make it a fantastic user (location) tracking vector for outside observers!

Instead, encrypted QUIC connections negotiate a set of CIDs (usually 8) and switch to a new one when migrating networks, to prevent "linkability". 4/12

In practice it's more complex, as QUIC clients and servers actually choose their own CIDs individually (called "source" and "destination" CIDs in the specification).

As such, each QUIC connection typically has 16+ CIDs associated with it at a given time. 5/12

This is mainly done to allow servers to encode routing/load balancing information directly into the CID, which is one of the few unencrypted parts of a QUIC packet header (and thus can be read/used by those intermediaries).

See datatracker.ietf.org/doc/html/draft… for more info. 6/12

Without this extra encoded information/cooperation between QUIC servers and load balancers, it is difficult to ensure that migrated connections end up at the same backend server.

A big part of QUIC's deployment challenge is in how to handle CIDs in the distributed system. 7/12

There are other aspects, such as the ability to use "0-length" CIDs (to reduce overhead), the need for path challenges/responses when migrating, active vs passive migration and the server's "preferred address".

See the specification for more info: rfc-editor.org/rfc/rfc9000.ht…. 8/12

How useful is connection migration though? You eliminate the need to setup a new connection, but with QUIC 0-RTT data you can easily setup a new connection without RTT overhead anyway... 9/12

It's also not the case that the persistent connection will be "faster"/keep its speed: since we're on a new network, we don't know how much bandwidth we can safely/fairly use.

As such, we have to reset congestion control logic anyway, just as if it were a new connection. 10/12

The main benefit is that both client and server can keep any other associated connection state intact.

This is useful when e.g., downloading large files, having a video conference or playing a game. I'd argue it's not so much for typical HTTP/3 web browsing though... 11/12

In conclusion, #QUIC connection migration can be very useful, mainly for long-running, stateful connections.

It does come with considerable privacy gotcha's which in turn require custom load-balacing and routing logic for practical deployment. 12/12