Making communication faster has long meant removing bottlenecks, one by one. In the past, bandwidth was the primary bottleneck. As bandwidth became more abundant, latency emerged as the next major constraint. Early efforts to reduce it included HTTP/2 multiplexing, TLS 1.3, and QUIC's shorter handshakes.

Now that QUIC has been standardized and is gaining adoption, attention is shifting to the next bottleneck: the startup phase—the time it takes to discover and fully utilize available bandwidth after a connection is established.

This session introduces "Rapid Start," a new approach currently being evaluated by Fastly. It reviews Slow Start, the conventional method for bandwidth probing, explaining why startup can be slow, what assumptions it relies on, and where its limitations appear. It then shows how Rapid Start changes the initial behavior of bandwidth estimation to shorten startup time, highlighting its design points, trade-offs, and how Ruby was used to analyze its behavior.