Two CDNs with identical POP maps can deliver visibly different throughput to the same user, and one under-appreciated reason lives in the transport layer: which congestion-control algorithm their servers run. It is the kind of infrastructure choice vendors rarely surface and measurements always do.
The loss-based inheritance
Classic algorithms, Reno lineage through CUBIC, treat packet loss as the congestion signal: ramp up until loss, back off, repeat. On clean short paths this works fine. On paths with random non-congestive loss, wireless links, long international routes, loss-based control interprets noise as congestion and throttles throughput far below what the path could carry. Deep buffers invert the failure: no loss until buffers overflow, so latency balloons, the bufferbloat everyone eventually meets.
The model-based turn
BBR, from Google, ignores loss as the primary signal and instead continuously estimates the path’s bottleneck bandwidth and round-trip time, pacing transmission to the model. The practical consequences: dramatically better throughput on lossy and long-fat paths, and lower queuing delay because it does not need to fill buffers to find capacity. Later revisions addressed fairness criticisms, early BBR could bully CUBIC flows on shared links, and refinement continues, but the direction stuck: modern high-performance edges pace by model, not by loss.
A concrete pattern from the field: video rebuffer rates on mobile networks correlate strongly with the delivery stack’s congestion behavior, because ABR players read throughput estimates that transport smoothness directly shapes. Estates that switched delivery for the same content, same players, same encodes have measured rebuffer improvements on cellular cohorts attributable to nothing except the transport underneath. The lesson generalizes: at the tail, the network stack is product experience, and the CDN industry’s quiet arms race in pacing, probing and loss recovery is fought precisely over the users your averages ignore.
Why this is a CDN selection detail
Server-side congestion control is the CDN’s choice, invisible in feature tables, decisive on hostile paths. QUIC raises the stakes: congestion control lives in userspace, per-implementation, so vendor transport engineering directly shapes HTTP/3 behavior. The users who feel the difference are exactly your problem cohort: mobile, distant, congested. Which is to say: the p95 tail you keep reading about in this series is partly a congestion-control benchmark in disguise.
In practice
You cannot configure this, but you can measure it: sustained-throughput tests from representative last-mile conditions (not data centers) across candidate CDNs expose transport quality directly. Weight large-object throughput distributions, not just TTFB, when your product ships heavy bytes. And when a vendor’s numbers look inexplicably strong on bad networks, transport engineering is usually the unexplained variable, and a legitimate reason to shortlist them.
Our benchmarks include sustained-throughput distributions from real last-mile vantage points. Ask for the transport tab.