Chapter 04 · Stream Multiplexing and Flow Control for Performance
Check your understanding
14 questionsself-scored · offline
Answer to check your grasp of Chapter 04. Multiple-choice and true/false questions score themselves and reveal an explanation; short-answer questions reveal a model answer. Nothing leaves your browser.
- Q1multiple choiceWhat do the two least-significant bits of a QUIC stream ID encode?WhyBit 0x01 is the initiator (client/server) and bit 0x02 is directionality (bidi/uni), giving the four stream types. [§4.1, RFC 9000 §2.1]
- Q2multiple choiceA receiver no longer wants the data a peer is sending on a stream. What does it send?WhySTOP_SENDING (0x05) asks the sender to stop; a well-behaved sender then abandons its sending part with RESET_STREAM (0x04). [§4.1, RFC 9000 §3.5]
- Q3true / falseA bidirectional stream is tracked as two independent parts, a sending part and a receiving part, each with its own state.WhyThe halves progress independently, so one direction can finish or reset while the other keeps flowing. [§4.1, RFC 9000 §3]
- Q4multiple choiceQUIC flow control operates at which levels simultaneously?WhyMAX_STREAM_DATA caps one stream's absolute offset; MAX_DATA caps the sum across all streams. A sender must respect whichever binds first. [§4.2, RFC 9000 §4.1]
- Q5multiple choiceA stream's sustained throughput is fundamentally bounded by:WhyAfter filling the window the sender waits ~1 RTT for a MAX_STREAM_DATA update, so throughput <= window / RTT. To fill the pipe the window must cover the bandwidth-delay product. [§4.2]
- Q6multiple choiceA sender that has hit a stream's flow-control limit announces it with:WhySTREAM_DATA_BLOCKED signals a per-stream limit (DATA_BLOCKED is the connection-level analogue, STREAMS_BLOCKED is for the stream-count limit). [§4.2]
- Q7multiple choiceIn RFC 9218 prioritization, the urgency parameter:WhyUrgency is an integer 0-7 (default 3); smaller means send sooner, and 7 is reserved for background tasks. [§4.3, RFC 9218 §4.1]
- Q8true / falseHTTP/3 priority values are strict commands the server must obey exactly.WhyThey are signals. The server is responsible for scheduling the shared connection and SHOULD honor urgency, but it decides the actual send order subject to flow and congestion control. [§4.3, RFC 9218 §10]
- Q9multiple choiceTwo non-incremental responses at the same urgency should be sent:WhyNon-incremental means a partial response is useless, so finishing one makes it usable sooner; interleaving would leave both unusable longer. Incremental responses, by contrast, are round-robined. [§4.3]
- Q10true / falseA single lost QUIC packet blocks delivery of every stream on the connection.WhyEach stream has its own ordered byte space, so a loss is confined to the stream(s) whose data the packet carried; other streams are delivered immediately. [§4.4, RFC 9000 §2]
- Q11multiple choice"QUIC has no head-of-line blocking" is precise at which scope?WhyQUIC removes cross-stream transport HoL but keeps per-stream ordering; residual blocking can still arise in QPACK decompression (§6.3) and the shared connection flow-control window (§4.2). [§4.4]
- Q12multiple choiceFor disposable real-time data such as position updates, the best primitive is:WhyDATAGRAM frames are unreliable and unordered, so a stale update is never retransmitted and can never head-of-line-block a real request — exactly right for data where freshness beats completeness. [§4.5, §3.4]
- Q13short answerQUIC has per-stream flow control, yet a single stalled reader can throttle other streams on the same connection. Why?Model answerFlow control has a connection-level window (MAX_DATA) shared by all streams, in addition to the per-stream windows. A stream whose application has stopped reading still holds its buffered, unread bytes against that shared connection window, shrinking the credit available to every other stream — so one stalled reader can starve unrelated transfers. It is a flow-control coupling, distinct from the transport head-of-line blocking QUIC removes. [§4.2, §4.4]
- Q14short answerWhen designing a stream plan, what four decisions do you make for each traffic class?Model answer(1) Reliable stream vs unreliable DATAGRAM — does a late/lost copy still have value? (2) Per-object vs shared stream — one stream per object isolates loss and enables per-object priority. (3) Urgency (0-7) — how much it should win the shared pipe. (4) Incremental or not — whether a partial response is useful, which decides round-robin vs sequential scheduling. [§4.5]