Chapter 06 · QPACK Behavior and Header Compression Optimization
Check your understanding
16 questionsself-scored · offline
Answer to check your grasp of Chapter 06. Multiple-choice and true/false questions score themselves and reveal an explanation; short-answer questions reveal a model answer. Nothing leaves your browser.
- Q1multiple choiceWhich endpoint carries the burden of QPACK's optional state tracking?WhyQPACK deliberately places the state-tracking burden on the encoder, keeping decoders relatively simple. Each endpoint runs both an encoder (for headers it sends) and a decoder (for headers it receives). [§6.1, RFC 9204 §2.1]
- Q2multiple choiceThe QPACK encoder stream and decoder stream are, respectively:WhyThe encoder stream (uni, type 0x02) carries inserts encoder→decoder; the decoder stream (uni, type 0x03) carries feedback decoder→encoder. Both are critical streams. [§6.1, RFC 9204 §4.2, constants.md §9]
- Q3true / falseIn HPACK, table-modifying instructions were interleaved inside the header block, forcing strict in-order processing — the very thing QPACK avoids by moving inserts to a dedicated stream.WhyQPACK pulls table updates onto the encoder stream, so a HEADERS section merely references entries by index and can be parsed as soon as its referenced entries arrive, independent of other streams. [§6.1, RFC 9204 §2.2]
- Q4multiple choiceThe Known Received Count (KRC) tells the encoder:WhyAn entry whose absolute index is below the KRC has been confirmed by the decoder, so referencing it can never block. Advancing the KRC is the whole point of the decoder's feedback. [§6.2, RFC 9204 §2.1.4]
- Q5multiple choiceWhich decoder-stream instruction both confirms a request stream's decode AND can raise the Known Received Count?WhyA Section Acknowledgment releases that section's references and, if its Required Insert Count exceeds the current KRC, raises the KRC to it — so ordinary requests keep the KRC current for free. [§6.2, RFC 9204 §4.4.1, §2.1.4]
- Q6multiple choiceA decoder sends a Stream Cancellation instruction. What may the encoder conclude?WhyStream Cancellation retracts a reset stream's references (letting pinned entries become evictable) but implies nothing about received table state. [§6.2, RFC 9204 §4.4.2, §2.2.2.2]
- Q7true / falseA freshly inserted dynamic-table entry can be evicted immediately if it is never referenced.WhyAn entry becomes evictable only once its insertion is acknowledged (absolute index below the KRC) and it has no outstanding references in unacknowledged sections. A just-inserted, unacknowledged entry cannot be evicted yet. [§6.2, RFC 9204 §2.1.1]
- Q8multiple choiceA request stream becomes 'blocked' when:WhyThe section references a dynamic entry the decoder has not yet inserted; the decoder holds the section until the missing insertions arrive on the encoder stream, then unblocks. [§6.3, RFC 9204 §2.1.2, §2.2.1]
- Q9multiple choiceSETTINGS_QPACK_BLOCKED_STREAMS places what obligation on the encoder?WhyThe encoder must cap every potentially-blocking stream (those referencing unacknowledged entries) to the advertised limit. Exceeding it is a QPACK_DECOMPRESSION_FAILED connection error by the decoder. [§6.3, RFC 9204 §2.1.2]
- Q10true / falseWhile a stream is blocked, the decoder should release the section's bytes from the stream's flow-control window so other streams can proceed.WhyThe opposite: the decoder should keep the blocked section's bytes counted against flow control. Releasing early would let a peer pin unbounded decoder memory — a memory-exhaustion attack. Flow control is the backpressure that makes the blocked-stream budget safe. [§6.3, RFC 9204 §2.2.1]
- Q11multiple choiceWhy might an encoder emit a Duplicate instruction instead of referencing an existing dynamic entry?WhyAn encoder keeping a draining index avoids referencing near-eviction entries; Duplicate re-inserts the entry at a new absolute index so it can be referenced without pinning the old one. [§6.3, RFC 9204 §2.1.1.1, §4.3.4]
- Q12multiple choiceOn a 300 ms-RTT path, why does a strictly conservative encoder (reference only acknowledged entries) compress poorly at first?WhyThe acknowledgment loop that is nearly free locally becomes the dominant cost at high RTT: until the ack returns, the entry isn't 'safe', so the conservative encoder falls back to literals. [§6.4, RFC 9204 §2.1.2]
- Q13true / falseHigh round-trip time by itself causes QPACK blocking.WhyReordering and loss cause blocking, not latency alone. On a long but clean (ordered) path, an eager encoder's insert and reference travel together and rarely block. It is the long AND lossy path where a large blocked budget backfires. [§6.4]
- Q14multiple choiceIn the §6.5 lab, the decoder emits the byte 0x84 on its decoder stream after recovering. What is it?Why0x84 = 1000 0100: the leading 1 marks a Section Acknowledgment, and the 7-bit prefix integer is 4 — the stream just decoded. [§6.5, RFC 9204 §4.4.1]
- Q15short answerTwo settings govern the QPACK compression-versus-blocking trade-off. Name them and say what each controls.Model answerSETTINGS_QPACK_MAX_TABLE_CAPACITY (0x01) sets the size of the dynamic table the decoder will keep; zero disables the dynamic table entirely (static-only, never blocks). SETTINGS_QPACK_BLOCKED_STREAMS (0x07) caps how many streams the decoder will allow to be blocked at once; zero forbids the encoder from ever referencing an unacknowledged entry. Both are advertised by the decoder and bound what the encoder may do. [§6.1–6.4, RFC 9204 §5, constants.md §11]
- Q16short answerYou capture a stalled HTTP/3 request that later completes. Outline how you'd determine whether QPACK blocking was the cause.Model answerRead the Required Insert Count prefix of the stalled header block: zero means no dynamic dependency, so QPACK isn't the cause. Non-zero means it was waiting on a dynamic insertion — find the matching encoder-stream Insert; if it arrived after the block, that was normal recoverable blocking, and if it was lost/delayed by a reset or retransmission on a long path, the stream stayed stuck until it arrived. Also count concurrently blocked streams against the advertised SETTINGS_QPACK_BLOCKED_STREAMS (exceeding it is QPACK_DECOMPRESSION_FAILED), and check acknowledgment latency if the encoder never gets ahead enough to use dynamic entries. [§6.5, RFC 9204 §2.1.2, §4.5.1]