RTT is the unavoidable minimum delay between any action and its acknowledgement on the network. It sets the lower bound on how quickly TCP can grow its congestion window, how fast a QUIC handshake completes, how often a WebRTC stack can correct sender bitrate, and how quickly an LL-HLS player can react to a missing partial segment. RTT is dominated by physics — light in fibre travels at about 200 km per millisecond, so London to São Paulo is roughly 90 ms one way and 180 ms RTT just for the fibre.
For streaming, RTT determines the floor of every latency budget. A WebRTC call between two cities one continent apart will never go below their network RTT no matter how good the encoder. A CDN edge serves segments at one RTT to the viewer plus origin RTT if the edge missed the cache. ABR algorithms estimate throughput as bytes ÷ time including RTT effects, so a high-RTT path looks slower than it is and provokes lower-quality choices unless the algorithm compensates.
Operations teams measure RTT continuously per CDN POP, per edge IP and per major ISP. Sudden RTT spikes signal routing flaps; sustained RTT growth signals congestion or bad peering. Most CDN dashboards expose p50 and p95 RTT per region. Multi-CDN steering decisions are usually driven by a combination of RTT, throughput and rebuffer ratio rather than RTT alone.
