# QUIC

## Summary


QUIC is a transport protocol that's an alternative to TCP. QUIC sits on top of UDP and uses *TLS 1.3* for securing its payload. It was initially designed for HTTP use case but later evolved to accommodate a variety of use cases. HTTP on top of QUIC is often called *HTTP/3*. 

QUIC improves on TCP in a number of aspects: faster connection establishment, reduced head-of-line blocking, better congestion control, improved privacy and flow integrity. While measurements show that QUIC outperforms TCP, there are some scenarios where TCP does better. 

QUIC is being standardized by the IETF. As on January 2021, all documents are Internet-Drafts (I-Ds) and none of them are standards yet. Many open source implementations of QUIC are available in various programming languages. QUIC is actively used on the Internet by about 5% of web servers.

## Discussion

### What are the problems with TCP/IP networking stack that QUIC aims to solve?

Each HTTP connection traditionally used a separate TCP connection. However, opening a TCP connection is slow. It requires three round trip times (RTTs): one RTT for first contact and two RTTs for TLS security. Given that increasingly more of web traffic is encrypted these days, RTTs due to TLS can't be eliminated. Though network bandwidth has increased, exchanging short packet that's typical of web traffic is hampered due to these **handshake delays**. 

HTTP/2 partly mitigated TCP connection problem by allowing multiple HTTP streams to share a single TCP connection. Thus, multiple HTTP streams can exchange data in parallel. But since there's only one TCP connection, a packet loss would block all HTTP streams. This problem is called **Head-of-Line (HOL) blocking**. It can't be solved unless we make changes to the transport layer. Solving this could be important since more and more of web traffic is coming from smartphones over lossy mobile networks.


### What are the key features of QUIC?

QUIC features follow from its attempt to overcome limitations of TCP/IP: 

    + **Connection Setup**: Connection to a known server is setup with *0-RTT*. Setup time increases only for new cryptographic key exchange or version negotiation. By combining cryptographic and transport handshake, setup time is less.
    + **Stream Multiplexing**: Overcomes HOL blocking issue by multiplexing QUIC streams over UDP. Loss of a QUIC packet blocks only streams in that packet.
    + **Flow Control**: Receiver specifies in terms of total bytes that a sender can send per stream and across streams.
    + **Congestion Control**: QUIC sits in the user space, not kernel space. Hence, updates to algorithms can be done more quickly. Different applications can potentially use different algorithms. QUIC has been integrated with CUBIC and BBR algorithms. RTT estimates are better.
    + **Connection Migration**: Connection is preserved even if underlying client IP address changes. Such changes are common with mobile clients, such as switching between Wi-Fi and cellular.Forward Error Correction (FEC) and ACK entropy are two early features of QUIC that were later removed since maintenance costs outweighed the benefits. 


### Aren't problems of TCP/IP already solved by TFO and SCTP?

Indeed there are techniques such as TLC Snapstart and TCP Fast Open (TFO) that reduce setup time. In fact, QUIC's 0-RTT is inspired by these earlier approaches. Likewise, Stream Control Transmission Protocol (SCTP) can multiplex at the transport layer. 

However, network middleboxes interfere with the end-to-end principle. To optimize delivery of packets within the network, network operators may meddle with TCP headers, drop packets or track connections. Firewalls block unfamiliar packets. Network Address Translators (NATs) rewrite transport headers. These practices made it difficult to introduce changes such as TFO or SCTP across the Internet. In fact, the term **network ossification** is used in this context. 

QUIC can also suffer from network ossification. To prevent this, QUIC encrypts most of the protocol information, including some fields of QUIC packet headers. Middleboxes can't know much of what is carried and can't attempt to optimize delivery in non-standard ways. The long term benefit is that QUIC can evolve without worrying if middleboxes will support the changes. QUIC semantics remain end-to-end.  


### What are QUIC, gQUIC and iQUIC?

QUIC started in Google in 2012. IETF started standardizing it in 2016 but as of January 2021, it's still a draft. Meanwhile, many implementations of QUIC are already out there, some supporting Google's QUIC and others focusing on IETF's QUIC. 

It's common to say *gQUIC* for Google's QUIC. Sometimes the term *iQUIC* has been used to refer to IETF's QUIC. When QUIC becomes a standard and becomes more widely supported, we expect the term *QUIC* to refer to IETF's QUIC. Some already use *QUIC* in this sense. For now, whenever adoption or performance numbers are mentioned, it would be wise to check the version used for the study.

It's worth noting that gQUIC was specified as a monolith. IETF QUIC is more modular. Core QUIC transport, TLS with QUIC, congestion control, header compression, HTTP mapping to QUIC, version negotiation are all separate IETF drafts. 

gQUIC's cryptographic handshake was called *QUIC-Crypto*. This inspired the creation of *TLS 1.3* that's used by QUIC. 

Clients and servers can support multiple versions and negotiate the version during connection setup. Version numbers `0x00000001-0x0000ffff` are reserved for the standard. gQUIC and iQUIC versions have a separate ranges. 


### What are some essentials terms about QUIC?

Here are some essential QUIC terms to know: 

    + **Stream**: A lightweight, ordered byte-stream abstraction. A stream can be unidirectional or bidirectional, created by either endpoint. Streams are prioritized but priority is set by the application.
    + **Frame**: A unit of structured protocol information. There are many frame types. Only some of them carry streams, one stream per frame. Other frame types are for control.
    + **Packet**: A complete processable unit of QUIC. Multiple packets can be part of the same UDP datagram. Packets are confidentiality and integrity protection. A packet can include multiple streams but a packet loss blocks all its streams for retransmission. Preferably, a packet carries fewer streams. Packet payload is a sequence of one or more frames. Packet numbers are never reused within a connection, even for retransmissions.
    + **Header**: Part of a QUIC packet. Header can be long (4 types) or short (1 type). Some header fields are encrypted.
    + **Connection**: A shared state between client and server, which are the connection endpoints. Connection parameters are agreed during a *handshake phase*. *Connection ID* helps with correct packet delivery even when lower layer addressing changes.

### What are some criticisms of QUIC?

We note these criticisms or concerns about QUIC (likely to be overcome as QUIC matures):  

    + **Security**: Network attacks on UDP are common to the extent that some enterprises and operators block UDP traffic except those arriving on port 53 for DNS. 0-RTT can be misused for replay attacks, which can be a problem with non-idempotent requests. QUIC traffic is also not recognized or analysed by firewalls.
    + **Network Control**: Since transport layer headers are encrypted, network operators can't optimize their networks to manage congestion. For example, they can't know if a packet is an ACK or a retransmission. Estimating RTT is more difficult. The only options appear to be a single *Spin Bit* and IP-level *Explicit Congestion Notification (ECN)*.
    + **Performance**: Compared to TCP, UDP implementations are less performant. QUIC takes up too much CPU time. Low-end smartphones and IoT devices will suffer.
    + **Latency**: 0-RTT works only if load balancers maintain state and route to the same server. Since multiple versions can co-exist, each version negotiation takes an extra RTT.
    + **Fairness**: Since QUIC is in user space, applications and servers could implement more aggressive Congestion Control Algorithms (CCAs) that make it unfair for non-QUIC connections.

### Could you compare the performance of QUIC against TCP/IP?

In one study, gQUIC outperformed TCP+HTTPS in desktop environments, due to 0-RTT and quick loss recovery. In fluctuating bandwidths, QUIC did better due to better ACK handling and more accurate RTT estimates. However, QUIC was sensitive to out-or-order delivery, which it perceives as loss. QUIC is poorer on smartphones since it runs in user space. It's poorer in handling lots of small packets. It's also unfair to TCP by consuming more than its share of bandwidth. 

Researchers at RWTH Aachen University compared TCP+TLS1.3+HTTP/2 versus gQUIC performance under different network conditions. TCP parameters were fine-tuned. On a lossy network, QUIC performed better. In another test, visual web page performance was not all that different. They comment that fine-tuning TCP might suffice. 

Experiments by Fastly showed that QUIC performed poorly due to expensive memory copies between user space and kernel space. However, they matched TCP's performance by delaying ACK (a QUIC extension), using a Linux feature called Generic Segmentation Offload (GSO), and increasing the Maximum Transmission Unit (MTU) length. 


### What are some resources to get started with QUIC?

IETF's QUIC WG webpage is the place to track the latest in standardization, or download current versions of documents. 

The QUIC project page at Chromium is worth reading. It's FAQ shows how to test a QUIC server against Chrome or build standalone QUIC server and client. 

Chrome browser enables QUIC by default. In other popular browsers, HTTP/3 and QUIC can be enabled by setting specific configuration flags. 

Implementers can join the quicdev Slack channel to coordinate interoperability testing. There are already many implementations of QUIC, lists of which are maintained at QUIC WG's Wiki and on Wikipedia. An interoperability matrix is also available online.

We note a few of these implementations: Chromium (C/C++), ngtcp2 (C), nginx (C), quic-go (Go), and quicker (NodeJS/TypeScript).

In 2018, it was commented that only some implementations support all the advanced features. Very few map HTTP/3 to QUIC. 


### Could you share some tools for debugging or analysing QUIC traffic?

It's possible to capture QUIC traffic and analyze it offline within Chrome. 

Another tool is Wireshark. Since packets are encrypted, it's possible to load the SSL secret and then decrypt the packets. CellStream has released gQUIC and IETF QUIC profiles for Wireshark. 

Multiple implementations fragmented across QUIC versions may lead to sub-optimal performance or even buggy behaviour. Since traditional network analysis tools are tuned to TCP, new tools are needed. Hasselt University has created useful tools to analyse QUIC traffic. 

Ericsson's Spindump is a tool that makes use of QUIC's Spin Bit to figure out RTT for individual connections and aggregates. It's written in C and supports TCP, QUIC, COAP, DNS, ICMP, and SCTP traffic. It's also available as a library that can be linked with other programs.  

## Milestones

2012

Google's work on SPDY protocol becomes the starting point for the standardization of **HTTP/2** by IETF. Previously, Google made improvements to the physical layer by building its own carrier-grade networks and CDNs. While HTTP/2 allows multiple HTTP sessions share a single TCP connection, a single packet loss affects all sessions of that connection. This becomes the motivation to innovate at the transport layer, thus kickstarting QUIC work. 

Jun  
2013

Google engineer Roskind makes public **QUIC's design document**. He notes that RTT is limited by speed of light. It's high on mobile networks. At best, we can try to reduce the number of RTTs. QUIC is a proposal to do just that. Roskind notes that prototype implementations are ready for real-world experiments. 

Jul  
2014

**Wireshark 1.12.0** is released. This release introduces support for Google's QUIC. In August 2020, it's reported that Wireshark's support of Google's gQUIC and IETF's QUIC is still evolving. 

Jun  
2016

**IETF accepts QUIC** as an Internet-Draft. QUIC was proposed to IETF a year earlier in June 2015. IETF also renames the protocol to simply *QUIC* from its original expanded form of *Quick UDP-Based Internet Connection*. Thus, QUIC should not be treated as an acronym. The QUIC Working Group is chartered in October. Version 00 of Internet-Draft titled *QUIC: A UDP-Based Multiplexed and Secure Transport* is published in November. 

Jan  
2018

In an interview, we come to learn that 3GPP Core Networks and Terminals (CT) Working Groups are interfacing with IETF on how to adopt **QUIC for 5G networks**. QUIC may be considered for 5G Release 16. 3GPP expresses concerns about protocol headers being encrypted. They therefore provide IETF with requirements from network providers who often like to know more about the traffic that they carry. Meanwhile, Openwave Mobility reports more than 20% of video traffic on the networks of 30 mobile operators use QUIC. YouTube is a significant factor in this growth. 

Oct  
2018

The term **HTTP/3** is proposed in IETF as the new name for HTTP over QUIC, which has also been called HTTP/2 over QUIC. Essentially, it's a mapping of HTTP semantics over QUIC. Its wire format isn't compatible with HTTP/2. IETF Internet-Draft version 17 titled *Hypertext Transfer Protocol Version 3 (HTTP/3)* is published in December. 

May  
2019

The engineering team at Uber reports that QUIC outperforms TCP. They used *Cronet* networking library for Android. In production apps, they find that QUIC reduces tail-end latencies by 10-30% even on low connectivity networks. Tail-end latencies are a big problem for Uber, being almost six times the median values. 

Oct  
2020

Google Chrome browser includes IETF's QUIC (v29) in addition to Google's QUIC (Q050). However, IETF QUIC 0-RTT is not yet supported. Google claims that IETF QUIC outperforms HTTP over TLS 1.3 over TCP. Google search latency is less by 2%. YouTube rebuffer time is less by 9%. Client throughput is up by 3% (desktop) and 7% (mobile). Google also notes that QUIC carries a third of Google traffic. 

Dec  
2020

Measurements collected by W3Techs show that about 5% of web servers use QUIC. This has grown from about 2.8% in January. Of all sites that use QUIC, about 80% use LiteSpeed server. 

Jan  
2021

Weekly scans at netray.io show that IETF draft version 29 of QUIC is widely supported. Version 29 was published in June 2020. The most recent one is version 34, published in January 2021.