Chapter 07 · Transport Parameterization and Negotiation
Check your understanding
16 questionsself-scored · offline
Answer to check your grasp of Chapter 07. Multiple-choice and true/false questions score themselves and reveal an explanation; short-answer questions reveal a model answer. Nothing leaves your browser.
- Q1multiple choiceTransport parameters are best described as:WhyEach endpoint chooses its own parameter values independently and declares them; those values are limits on the peer. There is no negotiation. [§7.1, RFC 9000 §7.4]
- Q2multiple choiceEach transport parameter is encoded on the wire as:WhyParameters are a flat sequence of (ID, Length, Value) triples in the quic_transport_parameters TLS extension; unknown IDs are skipped by reading Length. [§7.1, RFC 9000 §18]
- Q3true / falseBecause transport parameters travel inside the TLS handshake, they are authenticated once the handshake completes.WhyBoth endpoints make authenticated declarations; an attacker can't tamper with them without breaking the handshake. This is what lets the connection-ID parameters prevent injection attacks. [§7.1, RFC 9000 §7.4, §7.3]
- Q4multiple choiceA client receives a stateless_reset_token transport parameter... wait — which side may send it?Whyoriginal_destination_connection_id, stateless_reset_token, preferred_address, and retry_source_connection_id are server-only; a server that receives any of them from a client closes with TRANSPORT_PARAMETER_ERROR. [§7.1, RFC 9000 §18.2]
- Q5multiple choiceQUIC flow control operates at:WhyStream flow control keeps one stream from monopolizing the buffer; connection flow control caps the sum across all streams. A sender must respect both. [§7.2, RFC 9000 §4.1]
- Q6multiple choiceOn a server, which parameter sets the initial flow-control limit for a client's request-body upload on a bidirectional stream the client opened?Why_local governs streams YOU open; _remote/_uni govern streams the peer opens toward you. The client opens the request stream, so from the server's view it is 'remote'. Mis-set this and uploads stall while downloads are fine. [§7.2, RFC 9000 §18.2]
- Q7multiple choiceA sender has hit the connection-wide data limit. What does it send, and what raises the limit?WhyThe connection-level limit is initial_max_data; a blocked sender signals DATA_BLOCKED and the receiver raises it with MAX_DATA. (STREAM_DATA_BLOCKED/MAX_STREAM_DATA are the per-stream analogues.) [§7.2, RFC 9000 §4.1]
- Q8multiple choiceYou want throughput not to be capped by flow control. The floor for initial_max_data is roughly:WhyIf the peer's available credit isn't kept above the BDP, receive throughput is flow-control limited regardless of congestion control. Size initial_max_data above the BDP and enable autotuning. [§7.2, RFC 9000 §4.3]
- Q9true / falseA receiver should wait for a DATA_BLOCKED frame before sending more flow-control credit.WhyThe opposite: a receiver MUST NOT wait for a blocked frame before extending credit — waiting guarantees a stall. Autotuning advertises more credit proactively from an RTT estimate and the drain rate. [§7.2, RFC 9000 §4.2]
- Q10multiple choiceEndpoint A advertises max_idle_timeout=30s, B advertises 10s. The effective idle timeout on each is:WhyThe effective value is the minimum of the two advertised (non-zero) values — 10 s for both — floored at 3×PTO. [§7.3, RFC 9000 §10.1]
- Q11multiple choiceHow does an endpoint keep an otherwise-idle QUIC connection alive?WhyQUIC has no keepalive frame. Sending a PING (or any ack-eliciting packet) makes the peer restart its idle timer. Space it under both the effective timeout and the ~30 s middlebox horizon. [§7.3, RFC 9000 §10.1.2, §19.2]
- Q12true / falseWhen a connection reaches its idle timeout, the endpoint sends a CONNECTION_CLOSE frame to notify the peer.WhyIdle timeout is a SILENT close — the state is simply discarded, no packet is sent; the peer discovers it when its own timer fires. Only an immediate close sends CONNECTION_CLOSE. [§7.3, RFC 9000 §10.1, §10.2]
- Q13multiple choiceA Version Negotiation packet is identified by, and characterized as:WhyThe VN packet has its Version field set to 0. It is stateless (server keeps no state) and therefore unauthenticated — which is why it has no built-in downgrade protection. [§7.4, RFC 8999 §6, RFC 9000 §6]
- Q14multiple choiceCompatible version negotiation (RFC 9368) avoids an extra round trip by:WhyThe version_information parameter (chosen_version + available_versions) lets a server continue the handshake in a compatible preferred version without a VN round trip, and — being authenticated — also blocks downgrades via VERSION_NEGOTIATION_ERROR. [§7.4, RFC 9368 §2.3, §3, §4]
- Q15short answerExplain why the three initial_max_stream_data_* parameters exist and give the rule for telling them apart.Model answerA stream's initial flow-control limit depends on who opened it and its directionality, so there are three parameters. The rule: _local (bidi_local) governs bidirectional streams the sender of the parameter opens itself; _remote (bidi_remote) governs bidirectional streams the peer opens toward the sender; _uni governs unidirectional streams the peer opens. Mnemonic: _local = streams you open, _remote/_uni = streams the peer opens toward you. So a server's initial_max_stream_data_bidi_remote is the limit on each client request stream's upload. [§7.2, RFC 9000 §18.2]
- Q16short answerYou're choosing transport parameters for a long-lived mobile client behind NATs. Which parameters get special attention and why?Model answermax_idle_timeout set long enough to persist across lulls, paired with a keepalive interval under the ~30 s middlebox horizon so NATs don't drop the flow (a long idle timeout without keepalive is a trap). active_connection_id_limit raised above the default 2 so the connection can migrate across Wi-Fi/cellular changes without a fresh handshake. Flow-control windows (initial_max_data and the relevant initial_max_stream_data_*) sized above the path's bandwidth-delay product, with autotuning to adapt. Each is a declaration that limits the peer. [§7.3, §7.5, RFC 9000 §10.1, §18.2]