RFC 9204 Quiz

**Explanation:** **Context (why chosen):** The most important QPACK idea is not the bit layout. It is the transport mismatch that made HPACK unsafe to reuse as-is for HTTP/3. **Terms:** **HPACK** assumes ordered delivery suitable for HTTP/2 over a single ordered byte stream. **QPACK** adapts header compression for HTTP/3 over QUIC, where out-of-order delivery matters. **Real-world usage:** In practice this helps you explain why HTTP/3 performance tuning is not “HTTP/2 plus UDP,” and why header compression design changed. **Options:** - A (incorrect): TLS renegotiation is not the core reason QPACK exists. - B (correct): This is the architectural motivation for QPACK. - C (incorrect): HPACK works for header and trailer sections; the issue is ordering assumptions. **Related:** QPACK keeps HPACK ideas like static and dynamic tables, but redesigns how state is coordinated so implementations can choose their blocking risk.

**Explanation:** **Context (why chosen):** The best way to reason about QPACK is to separate “cheap and safe” references from “more efficient but potentially blocked” references. **Terms:** **static table** references are predefined. **literal** representations carry enough information directly. **dynamic table** references depend on shared evolving state. **Real-world usage:** This distinction drives encoder decisions when there is packet loss, reordering, or strict latency targets. **Options:** - A (incorrect): Unacknowledged dynamic references are exactly the kind that can block decoding. - B (correct): Static table references do not depend on decoder dynamic state. - C (correct): Literals are bigger on the wire but avoid state dependence. - D (incorrect): Post-Base is still a dynamic table reference and can block. **Related:** A practical encoder often mixes literals, static references, and dynamic references depending on latency tolerance and connection state.

**Explanation:** **Context (why chosen):** Engineers often hear “QPACK reduces head-of-line blocking” and mistakenly conclude that blocking is impossible. It is reduced, not eliminated. **Terms:** **Required Insert Count** says how much dynamic table state the decoder must have before it can decode the field section. **Insert Count** is how many entries the decoder currently knows. **Real-world usage:** This directly affects tail latency, debugging of header decode stalls, and why encoder choices matter under packet loss. **Options:** - A (incorrect): The decoder does not invent a fallback representation on its own. - B (incorrect): Path migration is a QUIC concern, unrelated to QPACK decode readiness. - C (correct): The field section is blocked until the needed dynamic state arrives. **Related:** QPACK moves the trade-off toward encoder choice. Better compression can still create blocking if the required state is not available in time.

**Explanation:** **Context (why chosen):** QPACK is as much about operational limits as about compression format. Blocked-stream limits are a key control surface. **Terms:** **SETTINGS_QPACK_BLOCKED_STREAMS** is a decoder-provided bound on how many streams can be blocked due to missing dynamic table state. **Real-world usage:** This setting matters when tuning encoder aggressiveness for mobile loss, prioritization, and latency-sensitive traffic. **Options:** - A (correct): This is the direct meaning of the setting. - B (incorrect): Packet sizing is unrelated. - C (incorrect): Trailers are not what this setting limits. **Related:** Lower blocked-stream tolerance pushes encoders toward safer but larger encodings, such as literals or acknowledged references only.

**Explanation:** **Context (why chosen):** QPACK is built around a real trade-off, not a single “best” encoding. The encoder has to choose between compression efficiency and latency risk. **Terms:** **acknowledged entries** are dynamic table entries known to be available at the decoder. **literals** are bigger but avoid dependency on dynamic state. **Real-world usage:** This shows up in CDN and browser stacks where a few bytes saved are not worth stalling request processing under loss or reordering. **Options:** - A (incorrect): This maximizes compression potential, but it also maximizes blocking risk. - B (correct): This is the safer strategy when latency matters more than squeezing every byte. - C (incorrect): Flow control is not the knob that solves QPACK blocking. **Related:** QPACK shifts complexity toward encoder policy. Tuning that policy is often more important than memorizing instruction formats.

**Explanation:** **Context (why chosen):** QPACK introduces dedicated coordination streams, and understanding their role is more useful than memorizing stream type numbers. **Terms:** The **encoder stream** is a unidirectional stream that carries encoder instructions from encoder to decoder. Those instructions update the dynamic table state. **Real-world usage:** If this stream is mismanaged, header decoding can fail even when the application logic looks correct. **Options:** - A (incorrect): HTTP bodies travel on request or response streams, not the QPACK encoder stream. - B (incorrect): QPACK streams are specialized, not replacements for all HTTP/3 control traffic. - C (correct): This is the essential job of the encoder stream. **Related:** QPACK also has a decoder stream in the opposite direction so the encoder can learn what the decoder has processed.

**Explanation:** **Context (why chosen):** QPACK is intentionally designed so the encoder can track decoder readiness. The decoder stream is central to that feedback loop. **Terms:** The **decoder stream** carries feedback from decoder to encoder, including acknowledgments and related instructions that inform future encoding decisions. **Real-world usage:** This matters when tuning whether the encoder can safely reference newer dynamic entries without creating blocked streams. **Options:** - A (correct): This feedback lets the encoder know which dynamic state is safe to depend on. - B (incorrect): Application payloads do not travel on the decoder stream. - C (incorrect): The stream is not limited to trailers. **Related:** QPACK works because the encoder can trade compression ratio against the decoder's confirmed state instead of assuming global ordering.

**Explanation:** **Context (why chosen):** Security concerns in QPACK are not about breaking encryption directly. They are about what compression reveals under adversarial influence. **Terms:** A **compression side channel** exists when output size or encoding behavior leaks information about hidden values. Shared compression context makes that more plausible. **Real-world usage:** Browsers, intermediaries, and shared upstream connections need to reason about whether different parties can affect or observe the same compression state. **Options:** - A (incorrect): DNS trust is unrelated to the QPACK security model here. - B (correct): This is the actual concern described in the RFC. - C (incorrect): HTTP/3 does not forbid all such reuse in this simplistic way. **Related:** High-entropy secrets are harder to recover than low-entropy values, but the safe lesson is still to treat sensitive fields cautiously in shared compression contexts.

**Explanation:** **Context (why chosen):** QPACK performance is constrained by memory as well as latency. Table-capacity limits are part of that resource contract. **Terms:** **dynamic table capacity** is the amount of space available for entries used in indexed compression on a connection. **Real-world usage:** This matters for memory budgeting, endpoint hardening, and deciding how much dynamic compression state is worth maintaining. **Options:** - A (incorrect): Stream count is a different transport concern. - B (incorrect): Body size is unrelated to this QPACK setting. - C (correct): This setting bounds dynamic table capacity. **Related:** A larger table can improve compression ratio, but it also increases state memory and coordination complexity.

**Explanation:** **Context (why chosen):** The real learning target for RFC 9204 is design judgment. A good review comment shows that the engineer sees QPACK as an optimization problem with operational trade-offs. **Terms:** **blocked streams**, **loss**, **dynamic table usage**, and **compression gain** are the practical knobs in QPACK design. **Real-world usage:** This is exactly the framing you want in browser, CDN, proxy, or library implementation reviews when someone asks how aggressive the encoder should be. **Options:** - A (correct): This captures the core trade-off QPACK was designed to expose and manage. - B (incorrect): Better compression is not always better if it creates head-of-line-style stalls. - C (incorrect): Literals are an important safety valve when dynamic-state risk is too high. **Related:** Mature QPACK use is about choosing when to spend bytes to save latency, and when to spend state to save bytes.