A First Look at QUIC in the Wild

For the first time since the establishment of TCP and UDP, the Internet transport layer is subject to a major change by the introduction of QUIC. Initiated by Google in 2012, QUIC provides a reliable, connection-oriented low-latency and fully encrypted transport. In this paper, we provide the first broad assessment of QUIC usage in the wild. We monitor the entire IPv4 address space since August 2016 and about 46% of the DNS namespace to detected QUIC-capable infrastructures. Our scans show that the number of QUIC-capable IPs has more than tripled since then to over 617.59 K. We find around 161K domains hosted on QUIC-enabled infrastructure, but only 15K of them present valid certificates over QUIC. Second, we analyze one year of traffic traces provided by MAWI, one day of a major European tier-1 ISP and from a large IXP to understand the dominance of QUIC in the Internet traffic mix. We find QUIC to account for 2.6% to 9.1% of the current Internet traffic, depending on the vantage point. This share is dominated by Google pushing up to 42.1% of its traffic via QUIC

Observing the Evolution of QUIC Implementations

The QUIC protocol combines features that were initially found inside the TCP, TLS and HTTP/2 protocols. The IETF is currently finalising a complete specification of this protocol. More than a dozen of independent implementations have been developed in parallel with these standardisation activities. We propose and implement a QUIC test suite that interacts with public QUIC servers to verify their conformance with key features of the IETF specification. Our measurements, gathered over a semester, provide a unique viewpoint on the evolution of a protocol and of its implementations. They highlight the arrival of new features and some regressions among the different implementations.Comment: 6 pages, 8 figure

A QUIC Implementation for ns-3

Quick UDP Internet Connections (QUIC) is a recently proposed transport protocol, currently being standardized by the Internet Engineering Task Force (IETF). It aims at overcoming some of the shortcomings of TCP, while maintaining the logic related to flow and congestion control, retransmissions and acknowledgments. It supports multiplexing of multiple application layer streams in the same connection, a more refined selective acknowledgment scheme, and low-latency connection establishment. It also integrates cryptographic functionalities in the protocol design. Moreover, QUIC is deployed at the application layer, and encapsulates its packets in UDP datagrams. Given the widespread interest in the new QUIC features, we believe that it is important to provide to the networking community an implementation in a controllable and isolated environment, i.e., a network simulator such as ns-3, in which it is possible to test QUIC's performance and understand design choices and possible limitations. Therefore, in this paper we present a native implementation of QUIC for ns-3, describing the features we implemented, the main assumptions and differences with respect to the QUIC Internet Drafts, and a set of examples.Comment: 8 pages, 4 figures. Please cite it as A. De Biasio, F. Chiariotti, M. Polese, A. Zanella, M. Zorzi, "A QUIC Implementation for ns-3", Proceedings of the Workshop on ns-3 (WNS3 '19), Firenze, Italy, 201

The QUIC Fix for Optimal Video Streaming

Within a few years of its introduction, QUIC has gained traction: a significant chunk of traffic is now delivered over QUIC. The networking community is actively engaged in debating the fairness, performance, and applicability of QUIC for various use cases, but these debates are centered around a narrow, common theme: how does the new reliable transport built on top of UDP fare in different scenarios? Support for unreliable delivery in QUIC remains largely unexplored. The option for delivering content unreliably, as in a best-effort model, deserves the QUIC designers' and community's attention. We propose extending QUIC to support unreliable streams and present a simple approach for implementation. We discuss a simple use case of video streaming---an application that dominates the overall Internet traffic---that can leverage the unreliable streams and potentially bring immense benefits to network operators and content providers. To this end, we present a prototype implementation that, by using both the reliable and unreliable streams in QUIC, outperforms both TCP and QUIC in our evaluations.Comment: Published to ACM CoNEXT Workshop on the Evolution, Performance, and Interoperability of QUIC (EPIQ

Count Me If You Can: Enumerating QUIC Servers Behind Load Balancers

QUIC is a new transport protocol over UDP which is recently became an IETF RFC. Our security analysis of the Connection ID mechanism in QUIC reveals that the protocol is underspecified. This allows an attacker  to count the number of server instances behind a middlebox, e.g., a  load balancer. We found 4/15 (~25%) implementations vulnerable to  our enumeration attack. We then concretely describe how an attacker  can count the number of instances behind a load balancer that either uses Round Robin or Hashing

Is the Web ready for HTTP/2 Server Push?

HTTP/2 supersedes HTTP/1.1 to tackle the performance challenges of the modern Web. A highly anticipated feature is Server Push, enabling servers to send data without explicit client requests, thus potentially saving time. Although guidelines on how to use Server Push emerged, measurements have shown that it can easily be used in a suboptimal way and hurt instead of improving performance. We thus tackle the question if the current Web can make better use of Server Push. First, we enable real-world websites to be replayed in a testbed to study the effects of different Server Push strategies. Using this, we next revisit proposed guidelines to grasp their performance impact. Finally, based on our results, we propose a novel strategy using an alternative server scheduler that enables to interleave resources. This improves the visual progress for some websites, with minor modifications to the deployment. Still, our results highlight the limits of Server Push: a deep understanding of web engineering is required to make optimal use of it, and not every site will benefit.Comment: More information available at https://push.netray.i