Connecting on the QUIC

Please consider subscribing to LWN

Subscriptions are the lifeblood of LWN.net. If you appreciate this content and would like to see more of it, your subscription will help to ensure that LWN continues to thrive. Please visit this page to join up and keep LWN on the net.

In the never-ending drive to increase the perceived speed of the Internet, improving protocol efficiency is considerably easier than rolling out faster cabling. Google is indeed setting up fiber-optic networks in a handful of cities, but most users are likely to see gains from the company's protocol experimentation, such as the recently-announced QUIC. QUIC stands for "Quick UDP Internet Connection." Like SPDY before it, it is a Google-developed extension of an existing protocol designed to reduce latency. But while SPDY worked at the application layer (modifying HTTP by multiplexing multiple requests over one connection), QUIC works at the transport layer. As the name suggests, it implements a modification of UDP, but that does not tell the whole story. In fact, it is more accurate to think of QUIC as a replacement for TCP. It is intended to optimize connection-oriented Internet applications, such as those that currently use TCP, but in order to do so it needs to sidestep the existing TCP stack.

A June post on the Chromium development blog outlines the design goals for QUIC, starting with a reduction in the number of round trips required to establish a connection. The speed of light being constant, the blog author notes, round trip times (RTTs) are essentially fixed; the only way to decrease the impact of round trips on connection latency is to make fewer of them. However, that turns out to be difficult to do within TCP itself, and TCP implementations are generally provided by the operating system, which makes experimenting with them on real users' machines difficult anyway.

In addition to side-stepping the problems of physics, QUIC is designed to address a number of pain points uncovered in the implementation of SPDY (which ran over TCP). A detailed design document goes into the specifics. First, the delay of a single TCP packet introduces "head of line" blocking in TCP, which undercuts the benefits of SPDY's application-level multiplexing by holding up all of the multiplexed streams. Second, TCP's congestion-handling throttles back the entire TCP connection when there is a lost packet—again, punishing multiple streams in the application layer above.

There are also two issues that stem from running SSL/TLS over TCP: resuming a disconnected session introduces an extra handshake due solely to the protocol design (i.e., not for security reasons, such as issuing new credentials), and the decryption of packets historically needed to be performed in order (which can magnify the effects of a delayed packet). The design document notes that the in-order decryption problem has been largely solved in subsequent revisions, but at the cost of additional bytes per packet. QUIC is designed to implement TLS-like encryption in the same protocol as the transport, thus reducing the overhead of layering TLS over TCP.

Some of these specific issues have been addressed before—including by Google engineers. For example, TCP Fast Open (TFO) reduces round trips when re-connecting to a previously visited server, as does TLS Snap Start. In that sense, QUIC aggregates these approaches and rolls in several new ones, although one reason for doing so is the project's emphasis on a specific use case: TLS-encrypted connections carrying multiple streams to and from a single server, like one often does when using a web application service.

The QUIC team's approach has been to build connection-oriented features on top of UDP, testing the result between QUIC-enabled Chromium builds and a set of (unnamed) Google servers, plus some publicly available server test tools. The specifics of the protocol are still subject to change, but Google promises to publish its results if it finds techniques that result in clear performance improvements.

QUIC trip

Like SPDY, QUIC multiplexes several streams between the same client-server pair over a single connection—thus reducing the connection setup costs, transmission of redundant information, and overhead of maintaining separate sockets and ports. But much of the work on QUIC is focused on reducing the round trips required when establishing a new connection, including the handshake step, encryption setup, and initial requests for data.

QUIC cuts into the round-trip count in several ways. First, when a client initiates a connection, it includes session negotiation information in the initial packet. Servers can publish a static configuration file to host some of this information (such as encryption algorithms supported) for access by all clients, while individual clients provide some of it on their own (such as an initial public encryption key). Since the lifetime of the server's static configuration ought to be very long, requesting it the first time only takes one round-trip in many weeks or months of browsing. Second, when servers respond to an initial connection request, they send back a server certificate, hashes of a certificate chain for the client to verify, and a synchronization cookie. In the best-case scenario, the client can check the validity of the server certificate and start sending data immediately—with only one round-trip expended.

Where the savings really come into play, however, are on subsequent connections to the same server. For repeat connections within a reasonable time frame, the client can assume that the same server certificate will still be valid. The server, however, needs a bit more proof that the computer attempting to reconnect is indeed the same client as before, not an attacker attempting a replay. The client proves its identity by returning the synchronization cookie that the server sent during the initial setup. Again, in the best-case scenario, the client can begin sending data immediately without waiting a round trip (or three) to re-establish the connection.

As of now, the exact makeup of this cookie is not set in stone. It functions much like the cookie in TFO, which was also designed at Google. The cookie's contents are opaque to the client, but the documentation suggests that it should at least include proof that the cookie-holder came from a particular IP address and port at a given time. The server-side logic for cookie lifetimes and under what circumstances to reject or revoke a connection is not mandated. The goal is that by including the cookie in subsequent messages, the client demonstrates its identity to the server without additional authentication steps. In the event that the authentication fails, the system can always fall back to the initial-connection steps. An explicit goal of the protocol design is to better support mobile clients, whose IP addresses may change frequently; even if the zero-round-trip repeat connection does not succeed every time, it still beats initiating both a new TCP and a new TLS connection on each reconnect.

Packets and loss

In addition to its rapid-connection-establishment goals, QUIC implements some mechanisms to cut down on retransmissions. First, the protocol adds packet-level forward-error-correcting (FEC) codes to the unused bytes at the end of streams. Lost data retransmission is the fallback, but the redundant data in the FEC should make it possible to reconstruct lost packets at least a portion of the time. The design document discusses using the bitwise sum of a block of packets as the FEC; the assumption is that a single-packet loss is the most common, and this FEC would allow not only the detection of but the reconstruction of such a lost packet.

Second, QUIC has a set of techniques under review to avoid congestion. By comparison, TCP employs a single technique, congestion windows, which (as mentioned previously) are unforgiving to multiplexed connections. Among the techniques being tested are packet pacing and proactive speculative retransmission.

Packet pacing, quite simply, is scheduling packets to be sent at regular intervals. Efficient pacing requires an ongoing bandwidth estimation, but when it is done right, the QUIC team believes that pacing improves resistance to packet loss caused by intermediate congestion points (such as routers). Proactive speculative retransmission amounts to sending duplicate copies of the most important packets, such as the initial encryption negotiation packets and the FEC packets. Losing either of these packet types triggers a snowball effect, so selectively duplicating them can serve as insurance.

But QUIC is designed to be flexible when it comes to congestion control. In part, the team appears to be testing out several good-sounding ideas to see how well they fare in real-world conditions. It is also helpful for the protocol to be able to adapt in the future, when new techniques or combinations of techniques prove themselves.

QUIC is still very much a work in progress. Then again, it can afford to be. Unlike SPDY, which eventually evolved into HTTP 2.0, the team behind QUIC is up front about the fact that the ideas they implement, if proven successful, would ultimately be destined for inclusion in some future revision of TCP. Building the system on UDP is a purely practical compromise: it allows QUIC's connection-management concepts to be tested on a protocol that is already understood and accepted by the Internet's routing infrastructure. Building an entirely new connection-layer protocol would be almost impossible to test, but piggybacking on UDP at least provides a start.

The project addresses several salient questions in its FAQ, including the speculation that QUIC's goals might have been easily met by running SCTP (Stream Control Transmission Protocol) over DTLS (Datagram Transport Layer Security). SCTP provides the desired multiplexing, while DTLS provides the encryption and authentication. The official answer is that SCTP and DTLS both utilize the old, round-trip–heavy semantics that QUIC is interested in dispensing with. It is possible that other results from the QUIC experiment will make it into later revisions, but without this key feature, the team evidently felt it would not learn what it wanted to. However, as the design document notes: "The eventual protocol may likely strongly resemble SCTP, using encryption strongly resembling DTLS, running atop UDP."

The "experimental" nature of QUIC makes it difficult to predict what outcome will eventually result. For a core Internet protocol, it is a bit unusual for a single company to guide development in house and deploy it in the wild, but then again, Google is in a unique position to do so with real-world testing as part of the equation: the company both runs web servers and produces a web browser client. So long as the testing and the eventual result are open, that approach certainly has its advantages over years of committee-driven debate.