JULY 2019 | VOL. 62 | NO. 7 | COMMUNICATIONS OF THE ACM 87
quickly and at scale. On the other hand, changing application-layer code can be done relatively easily, particularly
when client and server code are controlled by the same
entity (e.g., in the case of Google). As such, QUIC is implemented at the application layer to allow Google to more
quickly modify and deploy new transport-layer optimizations at scale.
Second, to avoid privacy violations as well as transparent proxying and content modification by middleboxes,
QUIC is encrypted end-to-end, protecting not only the
application-layer content (e.g., HT TP) but also the transport-layer headers.
QUIC features. QUIC implements several optimizations
and features borrowed from existing and proposed TCP,
TLS, and HTTP/2 designs. These include:
• “0-R TT” connection establishment: Clients that have pre-
viously communicated with a server can start a new ses-
sion without a three-way handshake, using limited
state stored at clients and servers.
• Reduced “head of line blocking”: HTTP/2 allows multiple
objects to be fetched over the same connection, using
multiple streams within a single flow. If a loss occurs in
one stream when using TCP, all streams stall while
waiting for packet recovery. In contrast, QUIC allows
other streams to continue to exchange packets even if
one stream is blocked due to a missing packet.
• Improved congestion control: QUIC implements better
estimation of connection Round-trip Time (RTTs) and
detects and recovers from loss more efficiently.
Other features include forward error correctiond and
improved privacy and flow integrity compared to TCP.
Most relevant to this work are the congestion and flow
control enhancements over TCP, which have received substantial attention from the QUIC development team. QUIC
currentlye uses the Linux TCP Cubic congestion control
implementation, 20 and adds with several new features.
Specifically, QUIC’s ACK implementation eliminates ACK
ambiguity, which occurs when TCP cannot distinguish
losses from out-of-order delivery. It also provides more
precise timing information that improves bandwidth and
RTT estimates used in the congestion control algorithm.
QUIC includes packet pacing to space packet transmissions in a way that reduces bursty packet losses, tail loss
probes12 to reduce the impact of losses at the end of flows,
and proportional rate reduction16 to mitigate the impact of
random loss on performance.
2. 1. Related work
QUIC emulation results. Several papers explore QUIC performance and compare it with TCP. 8, 11, 17 However, prior
work have a number of shortcomings including lack of
proper configuration of QUIC, limited test environments,
behind observed performance differences and to generate
inferred state machine diagrams. We make this code (and
our dataset) publicly available at http://quic.ccs.neu.edu.
Third, we conduct tests using a variety of emulated network conditions, against our own servers and those run by
Google, from both desktop and mobile-phone clients, and
using multiple historical versions of QUIC. This analysis
allows us to understand how QUIC performance evolved
over time, and to determine how code changes impact relevant metrics. In doing so, we produce the first state
machine diagrams for QUIC based on execution traces.
Summary of findings. Our key findings covered in this
article are as follows:
• In the desktop environment, QUIC outperforms
TCP+HTTPS in nearly every scenario. This is due to fac-
tors that include 0-RTT connection establishment and
recovering from loss quickly.
• QUIC is sensitive to out-of-order packet delivery. QUIC
interprets such behavior as loss and performs significantly worse than TCP in many scenarios.
• QUIC’s performance gains are diminished on phones
due to its reliance on application-layer packet processing
• QUIC outperforms TCP in scenarios with fluctuating
bandwidth. This is because QUIC’s Acknowledgment
(ACK) implementation eliminates ACK ambiguity, resulting in more precise RTT and bandwidth estimations.
• When competing with TCP flows, QUIC is unfair to TCP
by consuming more than twice its fair share of the bottleneck bandwidth.
• QUIC performance has improved since 2016 mainly
due to a change from a conservative maximum congestion window to a much larger one.
• We identified a bug affecting the QUIC server included
in Chromium version 52 (the stable version at the time
of our experiments), where the initial congestion window and Slow Start threshold led to poor performance
compared with TCP.
2. BACKGROUND AND RELATED WORK
Google’s QUIC protocol is an application-layer transport
protocol that is designed to provide high performance, reliable in-order packet delivery, and encryption. 4 The protocol
was introduced in 2013, and has undergone rapid development by Google developers. QUIC is included as a separate
module in the Chromium source; at the time of our experiments, the latest stable version of Chrome is 60, which supports QUIC versions up to 37. 12 versions of QUIC have been
released during our study, that is, between September 2015
and January 2017.c
QUIC motivation. The design of QUIC is motivated
largely by two factors. First, experimenting with and
deploying new transport layers in the OS is difficult to do
c Throughout this paper, unless stated otherwise, we use QUIC version 34,
which we found to exhibit identical performance to versions 35 and 36.
Changelogs and source code analysis confirm that none of the changes
should impact protocol performance.
d This feature allows QUIC to recover lost packets without needing retransmissions. Due to poor performance it is currently disabled. 22
e Google is developing a new congestion control called BBR, 10 which is not
yet in general deployment.