ReACKed QUICer: Measuring the Performance of Instant Acknowledgments in QUIC Handshakes

TL;DR

A detailed performance analysis of QUIC instant~ACK is presented, a standard-compliant approach to reduce waiting times during the QUIC connection setup in common CDN deployments and finds that instant ACK may lead to unnecessary retransmissions or longer waiting times under some network conditions, raising awareness of drawbacks of instant ACK in the future.

Abstract

In this paper, we present a detailed performance analysis of QUIC instant ACK, a standard-compliant approach to reduce waiting times during the QUIC connection setup in common CDN deployments. To understand the root causes of the performance properties, we combine numerical analysis and the emulation of eight QUIC implementations using the QUIC Interop Runner. Our experiments comprehensively cover packet loss and non-loss scenarios, different round trip times, and TLS certificate sizes. To clarify instant ACK deployments in the wild, we conduct active measurements of 1M popular domain names. For almost all domain names under control of Cloudflare, Cloudflare uses instant ACK, which in fact improves performance. We also find, however, that instant ACK may lead to unnecessary retransmissions or longer waiting times under some network conditions, raising awareness of drawbacks of instant ACK in the future.

Figures (16)

• Figure 1: QUIC server behaviors in common CDN deployments. The delay $\Delta t$ between frontend server and certificate store inflates the RTT estimate for subsequent data from the frontend server, if the frontend server does not use IACK.
• Figure 2: Calculated evolution of the Probe Timeout (PTO) assuming that all subsequent packets arrive exactly after one RTT and the instant ACK is delivered 4 ms earlier. The instant ACK leads to a PTO improvement of $3\times \Delta t$.
• Figure 3: QUIC 1-RTT connection setup RFC-9000 and coalescence differences between IACK and WFC. Blue and orange ACKs indicate client and server RTT samples.
• Figure 4: First PTO improvement according to RFC9002 RFC-9002. Spurious retransmits happen if the delay between Frontend Server and Cert Store ($\Delta t$) is larger than the PTO set by the client. Relative to the RTT, lower latency connections profit more from PTO improvement with IACK.
• Figure 5: Time to First Byte (TTFB) of 10 KB file transfer at 9 ms RTT with large certificate, $\Delta t = 200~ms$, and without packet loss. Each diamond symbol represents the TTFB for an individual measurement. Intense colors indicate a concentration of values. HTTP/3 generally has a lower TTFB because the first STREAM frame received from the server is the Control Stream with the SETTINGS frame, which is send by the server immediately after the handshake completes. Compared to HTTP/1.1, this is one RTT faster.