Exercises — HTTP - 3 — QUIC, UDP-based, why

Directly below HTTP/3 is QUIC. Directly below QUIC is UDP. The full stack is: HTTP/3 → QUIC → UDP → IP. Here IP (Internet Protocol, defined above) is the bottom network layer that actually routes packets between machines. TCP appears nowhere in this stack — that is the whole point.

The five letters expand to:

• S — Setup faster (0/1-RTT),
• H — HOL blocking gone (independent streams),
• I — IP migration (Connection ID),
• M — Multiplexing without TCP,
• E — Encryption built-in (TLS 1.3 mandatory).

The four distinct wins over TCP are S, H, I, and E. M (Multiplexing) is the overlapping letter: multiplexing many streams is not a new capability QUIC invented — HTTP/2 already multiplexed streams over TCP. What QUIC adds is doing that multiplexing without TCP's single ordered stream, which is exactly what the H win (HOL blocking gone via independent streams) already describes. So M is really a restatement of H from a different angle, not a fifth independent benefit. SHIM-E keeps M only because it makes the word pronounceable.

False. HTTP semantics (methods, headers, status codes) are identical to HTTP/2. Only the transport changed. Header compression differs — HTTP/2 uses HPACK and HTTP/3 uses QPACK (both defined above: same goal of shrinking repeated headers, but QPACK tolerates out-of-order arrival across QUIC streams) — yet a GET /index.html means exactly the same thing in both.

Why 2 RTT for TCP + TLS 1.3? Count the round trips before you can send an HTTP byte:

1. TCP three-way handshake (see TCP — three-way handshake and reliability): client sends SYN, server replies SYN-ACK, client sends ACK. The client can only send data after the SYN-ACK comes back — that is the client's packet out and the server's reply back = 1 full RTT of pure waiting.
2. TLS 1.3 handshake (see TLS 1.3 — handshake and 0-RTT): on top of the now-open TCP connection, the client sends ClientHello, the server replies ServerHello + keys, and only after that reply arrives can the client send encrypted data = 1 more RTT.

So $T_{\text{setup}}^{\text{TCP+TLS}}=1RT{T}_{\text{TCP}}+1RT{T}_{\text{TLS}}=2RTT$.

Why only 1 RTT for fresh QUIC? QUIC folds the transport handshake and the crypto handshake into the same first flight of packets. The client's first flight carries both "let's connect" and "here is my crypto"; the server's single reply answers both. So $T_{\text{setup}}^{\text{QUIC fresh}}=1RTT$.

Why 0 RTT for resumed QUIC? On a repeat visit the client already remembers the server's crypto keys, so it can encrypt and attach the actual HTTP request to the very first packet. No round trip of pure waiting is needed: $T_{\text{setup}}^{\text{QUIC 0-RTT}}=0RTT$.

Now plug in $RTT=80$ ms:

• (a) $T_{\text{setup}}^{\text{TCP+TLS}}=2\times 80=160$ ms.
• (b) $T_{\text{setup}}^{\text{QUIC fresh}}=1\times 80=80$ ms.
• (c) $T_{\text{setup}}^{\text{QUIC 0-RTT}}=0$ ms.

Returning QUIC uses 0-RTT: $T_{\text{setup}}^{\text{QUIC 0-RTT}}=0$ ms. TCP+TLS1.3: $T_{\text{setup}}^{\text{TCP+TLS}}=160$ ms. Saving $=160-0=160$ ms.

Assumption (stated up front): packet losses are independent — one packet vanishing tells us nothing about whether any other vanishes. This is what lets us multiply per-packet survival probabilities; without independence the product $(1-p{)}^N$ would not be valid. The probability a single packet survives is $1-p=0.98$. Because losses are independent, all $N$ surviving together has probability $(1-p{)}^N=0.98^{50}$. So $P(\text{at least one loss})=1-(1-p{)}^N=1-0.98^{50}\approx 1-0.3642=0.6358.$ Why this formula? "At least one" is the complement of "none lost." Computing "none lost" is easy because independent survivals multiply; subtracting from $1$ is far simpler than summing all the "exactly-$k$-lost" cases.

Assumption (stated up front): as in L2.3, losses are independent across packets, each lost with the same probability $p$. This is exactly the setup that defines a binomial count, so the binomial coefficient $\left(\genfrac{}{}{0ex}{}{N}{k}\right)$ and the factors $p^k(1-p{)}^{N-k}$ are justified. The number of lost packets follows a binomial count: each of $N$ packets is lost independently with probability $p$. (a) Expected losses. Expectation of a sum of independent indicators is the sum of their probabilities: $E[\text{losses}]=Np=50\times 0.02=1.0.$ So on average one packet is lost — which is exactly why the single-loss model in L3/L4 is the natural baseline, but note it is only the average, not a guarantee. (b) Exactly two lost. Choose which $2$ of the $50$ are lost ($\left(\genfrac{}{}{0ex}{}{50}{2}\right)$ ways), those $2$ lost ($p^2$), the other $48$ survive ($(1-p{)}^{48}$): $P(\text{exactly }2)=\left(\genfrac{}{}{0ex}{}{50}{2}\right)p^2(1-p{)}^{48}=1225\times 0.02^2\times 0.98^{48}\approx 0.1858.$ So even though the average is one loss, there is roughly an $18.6\%$ chance of two losses — multiple losses are common, not exotic.

TCP: delivery is strictly in order, so every object arriving after the lost one is held back until the retransmission arrives. If the loss is at position $k$, then objects $k+1,k+2,\dots ,N$ are blocked — that is $N-k$ later objects blocked, plus object $k$ itself is late. Worst case is $k=1$: up to $N-1=49$ later objects blocked. QUIC: each object rides its own stream, so a loss on stream $k$ blocks only stream $k$. Exactly $1$ object is delayed. The other $49$ keep flowing. This is the visual meaning of "independent streams": one broken go-kart, not one frozen truck.

HTTP/2 slices many logical streams into frames and interleaves them — that removes application-layer HOL blocking. But all those frames are poured into one TCP byte-stream. TCP promises byte-#500 is not delivered until bytes #1–#499 arrive. When a TCP segment is lost, TCP holds back all already-arrived later bytes — including frames belonging to other HTTP/2 streams — until the retransmission fills the gap. So the blocking moved down one layer, from HTTP into TCP, but did not disappear. QUIC solves it by giving each stream its own ordering inside the transport, so a gap in one stream never stalls another. See Head-of-line blocking.

QUIC: each lost packet delays only its own stream. Two independent losses on two different streams delay exactly 2 objects; the other $48$ flow. The count of delayed objects equals the count of losses — it grows linearly and gently. TCP: everything is one ordered stream, so what matters is the earliest of the two losses. If the earlier loss sits at position $k_{\min }$, all objects $k_{\min }+1,\dots ,N$ are blocked = $N-k_{\min }$ objects — the second loss adds essentially nothing, because the earliest gap already froze the tail. Worst case ($k_{\min }=1$) still blocks $49$. Why the gap widens: under QUIC, blocked-objects ≈ number-of-losses (linear, small). Under TCP, blocked-objects is governed by the position of the earliest loss, and with more losses the earliest one tends to sit further forward, freezing an even larger tail. More losses barely hurt QUIC but push TCP toward its worst case — so on lossy links (high $p$, many losses) the advantage of independent streams grows.

(a) Setup. $T_{\text{setup}}^{\text{TCP+TLS}}=2\times 60=120$ ms; $T_{\text{setup}}^{\text{QUIC fresh}}=1\times 60=60$ ms. Saving $=120-60=60$ ms. (b) Blocked objects. With one loss placed uniformly at position $k\in \{1,\dots ,N\}$:

• TCP: blocked-later count is $N-k$. Averaging over $k$: $E[\text{blocked}{]}_{\text{TCP}}=\frac{1}{N}{\sum }_{k=1}^N(N-k)=\frac{N-1}{2}=\frac{49}{2}=24.5.$
• QUIC: exactly the lost stream is delayed, so $E[\text{blocked}{]}_{\text{QUIC}}=1$. The story: the fresh-connection setup win is a fixed $60$ ms, but the HOL win scales with the page — on average TCP stalls ~$24.5$ objects behind one loss while QUIC stalls one. On rich, lossy pages the HOL win dominates.

Define combined saving $=(\text{setup ms saved})+(\text{HOL ms saved})$, converting blocked objects into time via "each average blocked object waits one extra $RTT$ for the retransmission."

Setup saving. $T_{\text{setup}}^{\text{QUIC 0-RTT}}=0$ ms; $T_{\text{setup}}^{\text{TCP+TLS}}=2\times 60=120$ ms. Setup saved $=120$ ms.

HOL time. Under the toy model a stalled batch waits one retransmission $RTT$ to unblock, and the number stalled differs: TCP averages $24.5$ objects behind the gap, QUIC just $1$. Because in TCP those $24.5$ objects all wait behind the same single retransmission, the extra wall-clock delay is $1RTT=60$ ms for TCP versus $1RTT=60$ ms for QUIC — the same one retransmission RTT. So in this simplest model the HOL wall-clock time saving is $0$ ms even though $23.5$ fewer objects are stalled: QUIC's win here is how many objects are held, not the length of the single retransmission wait.

Combined saving (wall-clock ms) $=120+0=120$ ms, plus a throughput/experience win of $24.5-1=23.5$ fewer objects stalled that this ms-only number deliberately does not capture.

The honest answer: the clean combined time saving is $120$ ms (all from setup); the HOL benefit shows up as $23.5$ fewer blocked objects, which improves perceived load even when the single retransmission RTT is shared. Report both — a single ms figure alone understates QUIC.

Reason 1 — deployability. Middleboxes (NATs, firewalls) routinely drop packets with unknown IP protocol numbers. A brand-new protocol number would be silently blackholed across much of the internet, so it could never be deployed. UDP is already universally permitted (it carries DNS), so QUIC packets pass everywhere. Reason 2 — evolvability. TCP lives in the OS kernel and is fossilized by middleboxes that inspect and rewrite its headers. QUIC lives in user space and encrypts almost its entire packet, so browsers/servers can ship transport upgrades like ordinary software and middleboxes cannot peek or meddle. Consequence: UDP only provides ports + a checksum, so QUIC must rebuild reliability, ordering, flow control, and congestion control itself (see Congestion control — slow start, AIMD). That is a cost, but it is a cost paid in user-space code that can evolve — exactly the point.

A TCP connection is identified by the 4-tuple (source IP, source port, destination IP, destination port). When Wi-Fi → 4G changes your source IP, the tuple no longer matches, so the OS treats packets as belonging to no known connection — the TCP connection dies and must be rebuilt (new handshake, new TLS). QUIC instead tags the connection with a Connection ID that is independent of IP and port. When your IP changes, the server still recognizes the same Connection ID and the connection migrates without interruption — no new handshake, no dropped call.

The claim confuses layers. UDP indeed offers no retransmission — it is the dumb "delivery truck." But QUIC adds, on top of UDP, its own packet numbers, acknowledgements, and retransmission logic. If a QUIC packet is lost, QUIC detects the missing ACK and resends the data on the affected stream. From the application's view, HTTP/3 delivers every byte reliably and in per-stream order — as reliably as TCP, and without TCP's cross-stream HOL blocking. So HTTP/3 is fully reliable; the unreliability lives only in the UDP carrier beneath QUIC's reliability machinery.

Transport directly under HTTP/3 ::: QUIC (which runs over UDP). $T_{\text{setup}}$ for fresh QUIC in RTTs ::: 1 RTT. $T_{\text{setup}}$ for TCP+TLS1.3 in RTTs ::: 2 RTT (1 for TCP handshake + 1 for TLS 1.3). Probability of at least one loss among N packets, per-packet loss p (losses independent) ::: $1-(1-p{)}^N$. Expected number of packets lost among N at loss p ::: $Np$. Probability of exactly k losses among N at loss p (independent) ::: $\left(\genfrac{}{}{0ex}{}{N}{k}\right)p^k(1-p{)}^{N-k}$. Average objects blocked by one uniformly-placed loss under TCP, N objects ::: $(N-1)/2$. Objects blocked by one loss under QUIC ::: exactly 1. Header compression format in HTTP/2 vs HTTP/3 ::: HPACK vs QPACK (QPACK tolerates out-of-order streams). QUIC feature that survives Wi-Fi→4G ::: the Connection ID (connection migration).