QUIC separates stream positions from connection paths

QUIC runs over UDP while implementing its own reliable transport, congestion control, and cryptographic protection. A connection can contain many streams, each with its own byte offsets and ordered delivery. Packet numbers identify transmissions within their packet-number space; stream offsets identify application bytes. When information from a lost packet needs retransmission, it can be sent in a new packet with a new packet number. Reusing stream offsets avoids delivering duplicate stream positions, while distinct packet numbers make it possible to distinguish acknowledgment of different transmissions more clearly than TCP's reused sequence positions alone.

A receiver can acknowledge a valid packet after processing its frames without the application having consumed all resulting stream data. Each stream's contiguous bytes determine what that stream can deliver in order. Stream-level receive credit and connection-level receive credit protect buffering at different scopes. Multiple streams still share congestion-control resources on a path, and a packet can contain frames for several streams. Losing such a packet can delay every included stream. Independent stream numbering removes a particular cross-stream ordering dependency; it does not isolate CPU time, memory, packet loss, or every application dependency.

Connection IDs allow an endpoint to associate packets with connection state even when addressing changes, subject to negotiated and protocol rules. They are not a general permission for arbitrary server migration or an automatic bypass of endpoint policy. Active migration is constrained by the handshake state and transport parameters; NAT rebinding can also change the observed address without an intentional client move. A load balancer and server deployment must preserve the routing and state needed for the chosen connection-ID scheme. Otherwise a protocol feature supported by both endpoints can still fail at an operational boundary.

A new peer address needs path validation because sending large responses toward an unverified address could amplify spoofed traffic. PATH_CHALLENGE and a matching PATH_RESPONSE provide return-path evidence. Merely observing an ACK for a packet carrying a challenge is insufficient. Before validating a peer address, an endpoint responding to that address is generally constrained to three times the data received from it. Successful validation does not prove unlimited capacity or preserve the old path's RTT and congestion state. A newly usable path can have different bottlenecks, loss, and packet-size limits, so migration includes measurement and controller considerations.

A connection surviving an address change preserves protocol state that would otherwise need rebuilding, but outstanding work can still stall while a new path is tested or while feedback is absent. Server work and application retry policy continue to matter. QUIC's encrypted transport also changes what a passive network capture can reveal; endpoint logs may be necessary for stream and recovery details. Preserve connection identifiers, path transitions, validation events, packet-number spaces, and application request identifiers in the diagnostic story without treating any single one as a complete correlation key for every deployment.

Use the queue lab for shared capacity in separate constant-rate experiments. Reset, explicitly set both λ=4 and μ=3, predict growth from backlog four at t=0, then Play or Step. Reset again and re-set BOTH λ=2 and μ=3; predict zero at t=4 seconds before playback. Rate edits retain elapsed t and recompute from the original four rather than continuing prior work. These aggregate runs have no stream identities, cryptography, migration, or validation. They challenge independent-capacity claims, not QUIC correctness. Identify which stream and path measurements could distinguish a stream gap from congestion after a move.