Chapter 09 · Real-Time Traffic Optimization for Low Latency and Jitter
Check your understanding
16 questionsself-scored · offline
Answer to check your grasp of Chapter 09. Multiple-choice and true/false questions score themselves and reveal an explanation; short-answer questions reveal a model answer. Nothing leaves your browser.
- Q1multiple choiceFor real-time media, which latency source usually dominates?WhyQUIC removes inter-stream head-of-line blocking, but within a reliable stream a loss still holds later chunks until the retransmit arrives ~1 RTT later — the dominant real-time latency source. [§9.1]
- Q2true / falseJitter (variance of per-packet delay) matters less than raw latency for interactive media.WhyJitter forces a de-jitter/playout buffer sized to the tail of the delay distribution, and that buffer is added latency — so cutting jitter cuts latency twice. [§9.1]
- Q3multiple choiceThe smallest maximum datagram size QUIC requires a path to support is:WhyQUIC MUST NOT be used if the path can't carry a 1200-byte maximum datagram; Initial packets are padded to it. A 1280-byte IPv6 packet leaves 1232 bytes of UDP payload. [§9.2, RFC 9000 §14]
- Q4true / falseQUIC relies on IP-layer fragmentation to carry packets larger than the path MTU.WhyIP fragmentation is banned — the DF bit is set. A packet above the PMTU is dropped, not split; QUIC discovers the usable size with DPLPMTUD probes. [§9.2, RFC 9000 §14, §14.3]
- Q5multiple choiceA lost DPLPMTUD PMTU probe should be treated as:WhyProbes are larger than the current max and more likely dropped, so their loss SHOULD NOT trigger a congestion reaction — it only tells you the path won't support that size. [§9.2, RFC 9000 §14.4]
- Q6multiple choiceWhich transport parameter both enables DATAGRAM frames and bounds their size?Whymax_datagram_frame_size (default 0 = unsupported) advertises support and caps the largest DATAGRAM frame the endpoint will receive; 65535 is recommended. [§9.2, §9.3, RFC 9221 §3]
- Q7multiple choiceThe single question that decides reliable stream vs. unreliable datagram is:WhyReliable streams optimize completeness; datagrams optimize timeliness. If a retransmit that arrives a round trip late is still useful (a file), use a stream; if it's past the deadline (live media), use datagrams. [§9.3]
- Q8true / falseDATAGRAM frames are never retransmitted, and are also never acknowledged.WhyThey are NOT retransmitted on loss, but they ARE ack-eliciting — so the sender is notified whether each was delivered or lost, and the application decides how to react (conceal, FEC, keyframe). [§9.3, RFC 9221 §5.2]
- Q9multiple choiceAn acknowledgment of a DATAGRAM frame guarantees:WhyThe ack indicates transport-layer receipt only; it can't replace an application-level acknowledgment of successful processing. [§9.3, RFC 9221 §5.2]
- Q10multiple choiceDATAGRAM frames are congestion controlled but NOT flow controlled. What must a sender do when the congestion controller won't allow a datagram?WhyWith no flow control there's no window to fill; the sender must shed load at the source — drop stale frames rather than queue them, keeping the stream fresh. [§9.4, RFC 9221 §5.4]
- Q11true / falseFor a real-time stream, a large flow-control window is good because it prevents the sender from being blocked.WhyOn a real-time flow a big window is a big latency reservoir: the sender dumps seconds of data that then sits queued and stale. Keep windows and send buffers small so latency can't accumulate. [§9.4]
- Q12multiple choiceWhy does flow-control backpressure hurt real-time traffic specifically?WhyBackpressure buffers rather than sheds; for data whose value expires, buffering delivers everything late instead of the freshest on time. Real-time wants to drop stale data, not queue it. [§9.4]
- Q13multiple choiceIn the §9.5 media profile, how are media and control split?WhyTimely media that expires rides datagrams; must-arrive control (keyframe requests, signaling, stats) rides a reliable stream — both on the same QUIC connection. [§9.5]
- Q14true / falseBecause a DATAGRAM frame cannot be fragmented, an application must split media larger than the usable datagram payload itself.WhyQUIC won't fragment a DATAGRAM frame — it must fit one packet. A 4 KB keyframe on a ~1200-byte path must be split into application-level fragments with the app's own reassembly. [§9.2, §9.3, RFC 9221 §5]
- Q15short answerExplain why, for a live video call, retransmitting a lost frame on a reliable stream can be worse than not recovering it at all.Model answerThe retransmit takes about a round trip to arrive, by which time the frame's playout deadline has passed, so the repaired frame is useless. Worse, on a reliable ordered stream that lost frame also held every later frame (in-order delivery), so one loss stalled the whole stream to deliver data nobody can use — a freeze then a jump. Unreliable datagrams instead deliver later frames immediately and let the sender send fresh data (concealment, FEC, or a new keyframe), trading a brief artifact for staying in sync. [§9.1, §9.3]
- Q16short answerQUIC datagrams have no flow control. What replaces it to keep a real-time sender from flooding the network AND from building latency?Model answerTwo different mechanisms. The NETWORK limit is still enforced by congestion control — datagrams use the connection's congestion controller, so the sender can't overrun the path. The TIME/latency limit is the application's job: because there's no flow-control window to queue behind, the sender must shed at the source — drop datagrams the congestion controller won't allow (rather than queue them), honouring a per-frame expiration deadline, and keep send buffers small. Congestion control bounds the rate; the deadline bounds the age. [§9.4, RFC 9221 §5.3, §5.4]