92 COMMUNICATIONS OF THE ACM | JULY 2019 | VOL. 62 | NO. 7
relatively stable delay scenarios. To investigate this, we
instrumented QUIC’s loss detection mechanism, and our
analysis reveals that variable delays cause QUIC to incorrectly infer packet loss when jitter leads to out-of-order
packet delivery. This occurs in our testbed because
netem, which we use for network emulation, adds jitter
by assigning a delay to each packet, then queues each
packet based on the adjusted send time, not the packet
arrival time—thus causing packet reordering.
The reason that QUIC cannot cope with packet reorder-
ing is that it uses a fixed threshold for number of Negative
Acknowledgment (NACKs) (default 3) before it determines
that a packet is lost and responds with a fast retransmit.
Packets reordered deeper than this threshold cause false
positive loss detection.i In contrast, TCP uses the Duplicate
Selective Acknowledgment (DSACK) algorithm24 to detect
packet reordering and adapt its NACK threshold accord-
ingly. As we will show later in this section, packet reorder-
ing occurs in the cellular networks we tested, so in such
cases QUIC will benefit from integrating DSACK. We quan-
tify the impact of using larger DSACK values in Figure 8,
demonstrating that in the presence of packet reordering
larger NACK thresholds substantially improve end to end
performance compared to smaller NACK thresholds. We
shared this result with a QUIC engineer, who subsequently
informed us that the QUIC team is experimenting with
dynamic threshold and time-based solutions to avoid
falsely inferring loss in the presence of reordering.
Desktop with variable bandwidth. The previous tests
set a static threshold for the available bandwidth.
However, in practice such values will fluctuate over time,
particularly in wireless networks. To investigate how
QUIC and TCP compare in environments with variable
bandwidth, we configured our testbed to change the
bandwidth randomly within specified ranges and with
Figure 9 shows the throughput over time for three back-
to-back TCP and QUIC downloads of a 210MB object when
the bandwidth randomly fluctuates between 50 and
150Mbps. As shown in this figure, QUIC is more responsive
to bandwidth changes and is able to achieve a higher aver-
age throughput compared to TCP. We repeated this experi-
ment with different bandwidth ranges and change
frequencies and observed the same behavior in all cases.
Mobile environment. Due to QUIC’s implementation in
userspace (as opposed to TCP’s implementation in the OS
kernel), resource contention might negatively impact performance independent of the protocol’s optimizations for
transport efficiency. To test whether this is a concern in
practice, we evaluated an increasingly common resource-constrained deployment environment: smartphones. We
use the same approach as in the desktop environment, controlling Chrome (with QUIC enabled) over two popular
Android phones: the Nexus 6 and the MotoG. These phones
are neither top-of-the-line, nor low-end consumer phones,
and we expect that they approximate the scenario of a moderately powerful mobile device.
Figure 10 shows heatmaps for the two devices when
varying bandwidth and object size.j We find that, similar to
the desktop environment, in mobile QUIC outperforms
TCP in most cases; however, its advantages diminish across
To understand why this is the case, we investigate the
QUIC congestion control states visited most in mobile and
non-mobile scenarios under the same network conditions.
Figure 7. Congestion window over time for QUIC and TCP at 100Mbps
rate limit and 1% loss.
0 50 100 150 200 T h r
Figure 9. QUIC vs. TCP when downloading a 210MB object.
Bandwidth fluctuates between 50 and 150Mbps (randomly picks a
rate in that range every one second). Averaging over 10 runs, QUIC
is able to achieve an average throughput of 79Mbps (std. dev. = 31)
while TCP achieves an average throughput of 46Mbps (std. dev. = 12).
3 10 30 100
NACK threshold for fast retransmit
Figure 8. QUIC vs. TCP when downloading a 10MB page (112ms
RTT with 10ms jitter that causes packet reordering). Increasing the
NACK threshold for fast retransmit allows QUIC to cope with packet
i Note that reordering impact when testing small objects is insignificant because QUIC does not falsely detect losses until a sufficient number of packets are exchanged.
j We omit 100Mbps because our phones cannot achieve rates beyond
50Mbps over WiFi, and we omit results from varying the number of objects
because they are similar to the single-object cases.
k A parallel study from Google15 using aggregate data identifies the same
performance issue but does not provide root cause analysis.