What's Happening with QUIC

In other words, QUIC is no less than a new alternative to TCP, the Internet's venerable transport protocol. It provides a foundation for new applications, and existing ones–like HTTP–can be adapted to use it too.

Like all big changes, QUIC is taking time to get right, even though we're on a very aggressive schedule. The Working Group is very busy discussing the design of the protocol, prototyping it in multiple implementations, and making them interoperate to feed those discussions with data. While that happens, let's answer a few questions that often come up.

The IETF community had a number of goals when it chartered work on QUIC. Much of the motivation for this work comes from HTTP, and in particular what we've learned from HTTP/2.

One of the key goals for HTTP/2 was to avoid head-of-line blocking–when an outstanding request blocks subsequent requests. HTTP/2 solved that problem by allowing multiplexing on top of TCP; many HTTP requests and responses can be in flight at the same time, with no blocking from the application protocol.

However, fixing head-of-line blocking in HTTP exposed it down in the transport layer. When a packet is lost, TCP buffers any subsequent packets until it is successfully retransmitted, even when the application (like HTTP with multiplexing) might be able to use some of that buffered data. For example, some deployments of HTTP/2 have seen reduced performance on lossy connections–especially for video–because of this.

QUIC takes the stream model of HTTP/2 and embeds it in the transport layer, so that a single connection can make progress on a stream even if packets containing data from other streams are lost–thereby mitigating the head-of-line blocking problem in the transport as well as the application layer.

Many have noted that SCTP already offers multiplexing in a transport protocol. However, it's difficult to deploy SCTP on the open Internet, because many networks block it. As a result, QUIC is built on top of UDP.

That brings up another important feature of QUIC: protection against ossification. Because TCP exposes things like acknowledgements and retransmissions to networks, devices on the network sometimes try to "help" by changing unprotected information, or by inferring things from it.

Unfortunately, this makes evolving the protocol more difficult, because any changes can have unpredictable results. TCP is now so ossified that introducing any changes to its basic operation have to be done very carefully; this harms the ability of the protocol to meet the needs of its users.

QUIC hides much of this state from observers, ensuring that it remains a flexible, end-to-end protocol. Even where QUIC's state is exposed to the network, it is protected from on-path tampering, including QUIC's handshake as well as signals intended for on-path devices like the connection ID and the spin bit, should it be adopted.

QUIC does that by being encrypted by default. Internet protocols have been moving towards always-on encryption for a while now, because of concerns about ossification as well as pervasive monitoring. As an always-encrypted protocol, QUIC helps achieve this, and as a bonus, is able to offer better performance, thanks to its tighter integration between things like the transport and cryptographic handshakes.

The IETF isn't starting work on QUIC from scratch. In 2012, Google designed its own version of QUIC and then deployed it both in its popular Chrome browser and most of its services, including Youtube and search. This allowed them to observe the protocol in action and tweak its design before submitting it to the IETF for consideration in 2016. 

The IETF QUIC Working Group took Google's documents as input, and has created a set of drafts that used them as a starting point. 

QUIC now has several important changes from Google's input documents. In fact, every aspect of the wire protocol has been changed, as we've discussed and tweaked its design.

The biggest change is in how we negotiate encryption. Google QUIC's bespoke encryption handshake was new to many, where as Transport Layer Security (TLS) is more widely understood, has more features, and is much more widely supported in both implementations, and deployment. Considering the investment the community has in TLS research, security analysis, implementation, and deployment, the QUIC Working Group was chartered to use it as the basis of encryption in QUIC.

As a result, when an QUIC handshake starts, the TLS handshake takes place inside of the QUIC frames, so that the peers can authenticate each other and derive session keys for encryption. Once that takes place, those keys are used to encrypt the QUIC frames. You can read about it more in the QUIC TLS document.

QUIC also has unidirectional as well as bidirectional streams, to aid in composing different types of applications on it.

We've also taken the time to identify aspects of QUIC that will not change in future versions, which we call invariants. This helps devices like load balancers implement limited QUIC support in hardware.

HTTP over QUIC has changed as well. Besides explicitly separating it out into a separate document, Google's QUIC used HTTP/2's header compression scheme, HPACK. However, HPACK dictionaries track their state by assuming that ordering of messages on different streams is guaranteed by TCP–something that QUIC doesn't provide. So, we've designed a new, QUIC-specific header compression scheme, QPACK.

The current set of drafts (listed on the Working Group home page) represent two years of work by a broad set of engineers from around the world, as well as a number of years of pre-standardization work at Google. They're not ready for Working Group Last Call yet, but the chairs, editors, and many implementers believe that we're exiting the design phase of the work so that we can focus on getting full implementation of the specifications to validate that design.

In other words, we think that the set of drafts is ready for broader implementation and review, even if we're not yet ready to say that they should become RFCs.

There are currently more than fifteen experimental implementations of QUIC. We coordinate interoperability testing at IETF meetings and our interim meetings between them by designating a set of drafts an "Implementation Target." 

Implementing QUIC is not trivial; it requires providing most of the capabilities of a reliable, congestion-controlled transport protocol, HTTP/2 streams and integration with TLS. As a result, interoperability testing is going slowly, but steadily improving. QUIC is not yet ready for production use, but past experience (e.g., with HTTP/2) has shown that it's possible to get from this stage of protocol development to broad deployment in a relatively short amount of time.

So, we'll be meeting to both discuss issues and interoperate during the IETF 103 meeting in Bangkok, and we've also scheduled a January interim meeting in Tokyo. While we're chartered to finish by the end of this year, it currently looks like the work will continue into Q1 of 2019–mostly to sufficiently prove the interoperability and the deployability of the protocol.

There's been a considerable amount of interest in both using QUIC for applications other than HTTP, and in extending QUIC for new capabilities. While QUIC is not quite yet ready for either, it's interesting to see where it might go next.

One of the big applications that's shown interest in porting to QUIC is WebRTC. QUIC offers faster connection setup time and potentially easier firewall traversal than WebRTC's current transports.

Although the Working Group was initially chartered to focus on HTTP, there are a number of things people have talked about adding to it to improve both HTTP and other applications. For example, there's been some interest in extending QUIC to offer a multipath facility, much like MPTCP. Multicast has also seen some interest, especially for video delivery. Another interesting facility for video is unreliable delivery, to avoid retransmitting frames that aren't important any more.

It's not clear if, when or where any of this work will take place yet; currently everyone is focused on getting QUIC finished and successfully deployed, so that the Internet is faster, safer, and more evolvable. Until then, you can track the work on the QUIC home page.

Thanks to Alan Frindell, Jana Iyengar, Mirja Kuehlewind, Ian Swett, Martin Thomson and Brian Trammell for their feedback on this article.