Co-author of multiple QUIC libraries here: Even though QUIC uses a connectionless protocol (UDP) and QUIC allows client IP addresses to change during a lifetime

Co-author of multiple QUIC libraries here: Even though QUIC uses a connectionless protocol (UDP) and QUIC allows client IP addresses to change during a lifetime of a connection, a QUIC connection is actually extremely stateful - a lot more than TCP. There's lots of state for each stream (including potentially very fragmented send and receive buffers) and the overall connection. You could potentially serialize that, but it would be even more work than for TCP. Normal applications would typically just make sure the client can reconnect as fast as possible (and QUIC can do it with 0 to 1RTT), and then have suitable application level semantics that limit any availability issues when a reconnect happens (e.g. for large downloads you can restart using a ranged request. For persistent connection the server can tell the client with a GOAWAY that it might shut down and the client can reconnect early to avoid running into the availability issue). My understanding is that for [1], their frontend proxy still is a single QUIC peer which contains all state of the actual connection - otherwise they also couldn't do connection level flow control and overall connection congestion control. That layer now just instructs another server about packet layouts to send, but doesn't make the other layer handle QUIC transmission completely on its own.