Prompt and scope
A mobile client is downloading data or holding a long-lived connection while moving from Wi-Fi to cellular. Its source IP address and UDP port change. Explain how QUIC can recognize the same connection, validate the new path, and decide when to reconnect. Keep the scope at the QUIC v1 transport layer; discuss application retries, HTTP session recovery, and 0-RTT separately instead of calling them automatic migration.
What the interviewer evaluates
A strong answer separates the four-tuple from the QUIC Connection ID: an address change need not destroy connection state, but a new path must be validated. Expect questions about an unconfirmed handshake, disable_active_migration, NAT rebinding, connection-ID exhaustion, a server preferred address, and replay risk in 0-RTT. Saying “UDP is connectionless, so it can switch” misses QUIC’s state and security boundaries.
Clarifying questions before answering
- Is this an intentional client network switch or passive NAT rebinding? Their triggers and validation paths differ.
- Has the handshake been confirmed? QUIC v1 does not permit active migration before confirmation, so the original address remains in use.
- Did the peer disable active migration? After
disable_active_migration, a client cannot actively send from a new local address unless using a server-provided preferred address. - Is the connection ID zero length? A zero-length ID cannot isolate paths with a new ID, weakening routing and privacy options.
- Can the application tolerate a data gap? If the old path is gone and the new one cannot be validated, the endpoint waits, closes, or lets the application rebuild its session.
30-second answer framework
“QUIC does not bind a connection to the TCP four-tuple; it uses a Connection ID supplied by the peer. After the handshake is confirmed, a client probes from the new address. The server validates the path with PATHCHALLENGE and PATHRESPONSE before data moves there. NAT rebinding also requires validation. A Connection ID cannot be reused across different sending paths, and the peer can disable active migration. Migration failure does not immediately discard state if an old path remains; otherwise the endpoint waits or reconnects. 0-RTT is handshake resumption, not proof that a migration is safe, and the application must handle replay.”
Step-by-step explanation
QUIC state includes Connection IDs, cryptographic keys, stream state, and congestion control. A Connection ID lets a receiver map packets to the same connection after an IP or port change; it is not an authentication credential and does not by itself prove that a new address belongs to the original client.
After handshake confirmation, an endpoint can probe from a new local address. The new path sends PATHCHALLENGE and becomes usable only after PATHRESPONSE. Validation failure means that path is unusable; it does not require closing a connection that still has another valid path. A sudden peer-address change, such as NAT rebinding, also requires path validation so a spoofed source cannot redirect traffic or trigger amplification.
Each sending path should use a Destination Connection ID that has not been used on another path. This helps a multi-instance service route packets and reduces the chance that an observer links two paths. Endpoints should provide several IDs in advance; exhausting them prevents safe probing and migration. With a zero-length ID, the server must demultiplex using other information, which weakens migration and privacy boundaries.
Migration affects congestion control. An address change can cause the peer to reset congestion state, so the protocol recommends changing addresses infrequently. A server can provide a preferred address during the handshake, but the client still validates it first and keeps the original address if validation fails. disable_active_migration prevents a client from arbitrarily sending from a new address.
0-RTT allows application data during a resumed handshake, and the RFC gives it no replay protection. A network switch should use confirmed 1-RTT state; an application with non-idempotent retries still needs idempotency keys or server-side deduplication even when QUIC keeps the transport connection.
High-quality sample answer
“I would separate connection identity from network paths. QUIC uses a Connection ID, so an IP or port change during a Wi-Fi-to-cellular switch can preserve state. After handshake confirmation, the endpoint sends PATHCHALLENGE from the new address and uses the path only after PATHRESPONSE validates it; NAT rebinding follows the same rule. The endpoint must not reuse one ID across sending paths and must account for ID exhaustion and disable_active_migration. If validation fails, it keeps a working old path or waits and rebuilds the application session. I treat 0-RTT as replay-sensitive resumption, not as migration security.”
Common mistakes
- Mistake → claim UDP inherently supports migration; why it fails → UDP has no connection semantics, while QUIC still manages IDs, keys, and streams; fix → explain Connection IDs and path validation.
- Mistake → accept packets immediately after an address change; why it fails → spoofed addresses can cause amplification or misrouting; fix → require PATHCHALLENGE/PATHRESPONSE.
- Mistake → call 0-RTT migration; why it fails → 0-RTT sends early data without replay protection; fix → separate resumption from migration.
- Mistake → send one Connection ID on multiple paths; why it fails → it violates path association rules and harms privacy; fix → use an unused ID per sending path.
- Mistake → ignore
disable_active_migration; why it fails → the peer explicitly disallowed active local-address changes; fix → migrate only under protocol conditions such as a preferred address.
Follow-up responses
What happens if the new path never validates?
Only the new path is unusable. Keep sending on the old path while it remains valid. If no valid path exists, wait for another path, report unavailability and close, or rebuild the application session. A PATH_RESPONSE timeout is not automatically proof that application data was lost.
Why provide multiple Connection IDs?
Migration and probing need IDs that have not been used on another path. If the pool is exhausted, an endpoint cannot safely probe or respond to a peer migration. The server should replenish IDs within active_connection_id_limit.
How does migration reduce linkability?
Use a new Connection ID on the new path and header protection so packet numbers are not directly linkable. Timing and packet-size patterns can still correlate traffic, so migration is not anonymity.
Does migration preserve the congestion window?
An implementation may reset or adjust congestion control because the capacity of the new path is unknown. Change addresses sparingly and re-estimate available bandwidth after validation; applications should depend on eventual transport delivery, not unchanged instantaneous throughput.