Chapter 08 · Handling High-Latency Networks and Long RTT Effects
Check your understanding
16 questionsself-scored · offline
Answer to check your grasp of Chapter 08. Multiple-choice and true/false questions score themselves and reveal an explanation; short-answer questions reveal a model answer. Nothing leaves your browser.
- Q1multiple choiceWhy is it better to budget latency in round trips than in milliseconds?WhyA design that costs '2 RTT to first byte' costs 20 ms on a LAN and 600 ms over satellite — same count, different path. Counting round trips separates the protocol's cost from the path's. [§8.1]
- Q2multiple choiceOn a cold QUIC+TLS connection, roughly how many round trips until the first response byte?WhyThe combined handshake takes ~1 RTT, then the request/response exchange takes another — first byte at ~2 RTT. 0-RTT overlaps the request with the handshake to reach ~1 RTT. [§8.1, RFC 9000 §7]
- Q3true / false'1-RTT handshake' and '1-RTT to first byte' mean the same thing.WhyThe handshake completes in 1 RTT, but on a cold connection the request needs a second RTT after it, so first byte is ~2 RTT. 0-RTT (or a warm connection) is what makes first byte ~1 RTT. [§8.1]
- Q4multiple choiceA path reorders a packet by more than 3 positions. What can happen, and why does it matter more on a long path?WhyThe packet threshold declares a packet lost once 3 later ones are acked; reordering beyond that triggers a spurious retransmit, wasting a full RTT and cutting the congestion window — cheap on a LAN, expensive over satellite. [§8.2, RFC 9002 §6.1.1]
- Q5multiple choiceA receiver reports a 20 ms ACK Delay. How does the sender use it in the RTT estimate?Whyadjusted_rtt = latest_rtt - ack_delay, floored at min_rtt (a locally observed value never adjusted for reported delay) and capped at the peer's max_ack_delay once the handshake is confirmed. [§8.2, RFC 9002 §5.2, §5.3]
- Q6multiple choiceThe Probe Timeout is PTO = smoothed_rtt + max(4·rttvar, kGranularity) + max_ack_delay. What happens on each expiry without progress?WhyEach PTO expiry doubles the period (backoff); a PTO does NOT mark packets lost or collapse the window — it sends probe packets. On a long path a lost tail already costs a long PTO, and doubling makes repeated loss very expensive. [§8.2, RFC 9002 §6.2.1, §6.2.4]
- Q7multiple choiceWhich is a DETERMINISTIC latency reduction (not speculation)?Why0-RTT sends a real, known request one round trip earlier; its failure mode is bounded (replay-safe requests only). Server push and blind prefetch send bytes that are wasted when the guess is wrong — worse on long paths. [§8.3]
- Q8multiple choice103 Early Hints reduces latency by:WhyEarly Hints is the non-speculative replacement for server push: the server states what the page links (authoritative, not a guess) and the client does the fetching, so no unused bytes are sent. [§8.3, §5.3]
- Q9true / falseAn address-validation Retry adds a full round trip to connection setup.WhyRetry makes the client echo a token in a new Initial before the handshake proceeds — one extra RTT. Servers that don't need per-connection validation (or use it only under load) spare clients that cost. [§8.3, RFC 9000 §8.1.2]
- Q10multiple choiceWhy can a client open many concurrent request streams immediately, with no extra round trip?WhySetting initial_max_streams_bidi is equivalent to sending a MAX_STREAMS of that value, so the client may open streams up to the limit right away — no permission round trip. [§8.4, RFC 9000 §18.2]
- Q11multiple choiceTo keep a long-RTT pipe full, in-flight data should be about:WhyIf available flow-control credit isn't kept above the BDP, receive throughput is flow-control limited. So streams × per-stream window must reach the BDP, bounded by the connection window. [§8.4, RFC 9000 §4.3]
- Q12true / falseOn a variable-bandwidth path you should size flow-control windows for the peak BDP, not the average.WhyA window sized for the median throttles the connection exactly when the link is fast. Autotuning grows credit from a live RTT estimate so windows track the BDP upward as the path improves. [§8.4, RFC 9000 §4.2]
- Q13multiple choiceIn the §8.5 lab, the measured handshake component is ~1 RTT and TTFB is ~1 RTT on a 50 ms path. What independently confirms the emulated RTT?WhyTwo independently derived numbers — wall-clock component timing and the protocol's EWMA smoothed_rtt — agree on the path RTT, which is what shows the measurement is sound. [§8.5, RFC 9002 §5.3]
- Q14true / falseIndependent QUIC streams remove transport head-of-line blocking, so concurrency also eliminates application dependency round trips.WhyConcurrency fills the pipe with work you already know you need, but if asset B's request can't be formed until A's response is parsed, that's a dependency round trip no concurrency fixes — it's what 103 Early Hints exists to collapse. [§8.4, §8.3]
- Q15short answerA cold HTTP/3 GET on a 200 ms path takes ~400 ms to first byte. Name two deterministic changes that each remove ~200 ms, and why.Model answer(1) Reuse a warm connection: an already-open connection has paid its handshake RTT, so the request reaches first byte in ~1 RTT (~200 ms) instead of ~2 RTT. Connection pooling/coalescing and keepalive keep one warm. (2) 0-RTT resumption: when a new connection is unavoidable, sending the request as replay-safe early data in the first flight overlaps it with the handshake, removing the handshake round trip (~200 ms). Both are deterministic — no speculative bytes. [§8.1, §8.3, RFC 9000 §7]
- Q16short answerYou decompose a slow request into handshake, TTFB, and transfer components. For each, name one thing it tells you to change.Model answerHandshake dominates -> you're opening cold connections every time: reuse/pool connections and enable 0-RTT; if the handshake is inflated beyond 1 RTT, suspect an address-validation Retry or an amplification stall (shrink the cert chain). TTFB beyond one RTT -> server processing time or a request waterfall: fix server timing or batch requests concurrently. Transfer large -> the body exceeds the congestion or flow-control window: size initial_max_data and per-stream windows to the BDP and add concurrency. A high smoothed_rtt vs min_rtt points to queueing/ACK-delay or a stale min_rtt after a path change. [§8.5, §8.2, §8.3, §8.4]