Chapter 10 · Connection Migration, Resilience, and Session Continuity
Check your understanding
16 questionsself-scored · offline
Answer to check your grasp of Chapter 10. Multiple-choice and true/false questions score themselves and reveal an explanation; short-answer questions reveal a model answer. Nothing leaves your browser.
- Q1multiple choiceWhy can a QUIC connection survive a client changing its IP address, when a TCP connection cannot?WhyThe connection ID decouples the connection's identity from the UDP/IP addressing, so an address change doesn't break it. The keys and open streams all continue. [§10.1, RFC 9000 §9, §5.1]
- Q2true / falseEither endpoint may initiate connection migration at any time.WhyOnly the client initiates migration, and only after the handshake is confirmed. Servers don't migrate (except by advertising a preferred_address, which the client then migrates to). [§10.1, RFC 9000 §9]
- Q3multiple choiceWhich of these is a PROBING packet (does NOT by itself signal migration)?WhyProbing frames are PATH_CHALLENGE, PATH_RESPONSE, NEW_CONNECTION_ID, and PADDING. A packet of only probing frames is a probing packet; a NON-probing packet (STREAM, ACK, …) from a new address is what signals migration. [§10.1, RFC 9000 §9.1]
- Q4multiple choiceHow does a server validate a peer's new address before trusting it?WhyPath validation: the challenger sends 8 random bytes; only an endpoint genuinely at the new address can receive and echo them, so a spoofed source can't complete it. [§10.1, RFC 9000 §8.2]
- Q5true / falseUntil a migrated-to address is validated, the server may send it unlimited data.WhyThe anti-amplification limit applies: until validated, an endpoint sends at most three times the bytes received from that address, so a spoofed migration can't turn the server into a reflector. [§10.1, RFC 9000 §8, §9.3.1]
- Q6multiple choiceOn confirming a genuine migration to a NEW network, what must an endpoint do to its congestion controller and RTT estimator?WhyA new path may have very different capacity, so CC and RTT are reset to initial values — except when only the port changed (usually a NAT rebinding on the same physical path), where they MAY be retained. [§10.1, §10.3, RFC 9000 §9.4]
- Q7multiple choiceWhich frame supplies a peer with additional connection IDs (plus a stateless reset token each)?WhyNEW_CONNECTION_ID (0x18) provides alternative connection IDs with increasing sequence numbers and a stateless reset token each, up to the peer's active_connection_id_limit. RETIRE_CONNECTION_ID (0x19) drains old ones. [§10.2, RFC 9000 §5.1.1, §19.15]
- Q8true / falseWhen migrating to a new path, an endpoint may keep using the same connection ID it used on the old path.WhyIt MUST NOT reuse a connection ID when sending from more than one local address — migrating means changing address AND connection ID together, so a passive observer can't link the two paths. [§10.2, RFC 9000 §9.5]
- Q9multiple choiceWhy must the connection-ID pool be provisioned BEFORE a migration is needed?WhyYou need a fresh, previously-unused CID to move to; since the network can change at any moment, endpoints SHOULD supply spare CIDs in advance. An exhausted pool means migration silently fails. [§10.2, RFC 9000 §9.5, §5.1.1]
- Q10multiple choiceWhat is the strongest heuristic distinguishing an intentional migration from an involuntary NAT rebinding?WhyA deliberate migration rotates the connection ID; a NAT rebinding leaves it unchanged because the client didn't initiate anything. Recent packets on the old path and IPv6 also make rebinding less likely. [§10.3, RFC 9000 §9.3.3]
- Q11multiple choiceThe anti-flapping rule says an endpoint only changes the address it sends to in response to:WhyBecause packet numbers strictly increase, a reordered stale packet from the old address carries a lower number and is ignored for path selection — so the endpoint settles on the newest path instead of oscillating. [§10.3, RFC 9000 §9.3]
- Q12true / falseConnection migration and session resumption both keep the SAME connection alive across a disruption.WhyMigration preserves one connection across a path change. Resumption starts a NEW connection (when the old one is gone) that inherits crypto/config state via a TLS session ticket — different objects, complementary tiers of continuity. [§10.4]
- Q13multiple choiceSession resumption with 0-RTT plus a stored NEW_TOKEN can remove how many round trips from a cold start?Why0-RTT carries the first request in the opening flight (saves the handshake RTT), and a NEW_TOKEN presented in the Initial pre-validates the address (skips a Retry RTT). Together, a cold start collapses toward one round trip. [§10.4, RFC 9000 §8.1, RFC 9001 §4.6]
- Q14multiple choiceIn the §10.5 lab, what proves the migrated-to path is genuinely reachable?WhyThe server logs a PATH_CHALLENGE with 8 random bytes and receives a PATH_RESPONSE with the identical bytes; only an endpoint actually at the new address could echo data it had to receive. [§10.5, RFC 9000 §8.2.3]
- Q15short answerA mobile client walks from Wi-Fi to cellular mid-download. Walk through what QUIC does to keep the connection alive.Model answerThe client's IP address changes but it keeps the same connection, drawing a previously-unused connection ID from its pool for the new path (never reusing the old one, for unlinkability). It sends a non-probing packet (e.g. STREAM data) from the new cellular address; the server, seeing a known connection ID from a new address, concludes the peer migrated. Before trusting it, the server validates the path with a PATH_CHALLENGE of 8 unpredictable bytes and limits itself to 3x the received bytes until the client echoes them in a PATH_RESPONSE. On success, because this is a real network change (not just a port), the server resets its congestion controller and RTT estimator to initial values for the cellular path, then resumes full data flow — the download never restarts. [§10.1, §10.2, RFC 9000 §9]
- Q16short answerName QUIC's three tiers of session continuity and when each applies.Model answer(1) Keep the connection warm: a keepalive PING under the idle-timeout and ~30s NAT horizons prevents the connection from being lost or rebound at all. (2) Migrate the connection: when the path changes (new network, NAT rebinding), connection migration keeps the same connection — keys and open streams intact — alive across the address change, no new handshake. (3) Resume the session: when the connection is entirely gone (app killed, long offline, idle timeout fired), there's nothing to migrate, so a new connection is made but a TLS session ticket (PSK) + 0-RTT + a stored NEW_TOKEN make it cheap — roughly one round trip. Prefer the earlier tiers; they preserve forward-secret, non-replayable state. [§10.4, RFC 9001 §4.6, RFC 9000 §9]