The good, the bad… and the QUIC A new transport protocol for the Internet

Every student of computer networks will have heard it a million times: when an application wants to send a message over the Internet, it can do so by enlisting the services of one of the Internet’s two transport protocols: either TCP or UDP. As it turns out, that’s not entirely true anymore and there is in fact a third option. It’s called QUIC.

Traditionally, an application could choose to send its data over TCP or UDP. UDP is focused on raw speed, so much so that it doesn’t bother about tiny details such as making sure the data actually gets across correctly (or at all). So, like many other applications, our software could choose to go with TCP instead. This protocol ensures reliable data transfer, but in order to do so it needs to set up connections, exchange acknowledgements and retransmit lost or corrupted data, all of which takes up extra time and bandwidth. It gets even worse if we want to secure our connection – and of course we do! Running TLS / SSL on top of TCP introduces even more overhead.

Introducing QUIC

So, can’t we have the benefits of TCP but with better performance? The people at Google belief we can and developed a new transport protocol: QUIC, or Quick UDP Internet Connections. Used since 2014, QUIC works over UDP and adds TCP-like connection management on top of that. So, while QUIC offers the benefits of TCP, building a new transport protocol has allowed Google to add various tweaks and improvements:

  • connection setup can be much faster
  • security is included by default
  • support for multiplexing: a single QUIC connection can carry multiple streams of data. In TCP, if some of the data is lost, all streams have to wait until the missing part is recovered. QUIC, however, is able to process the other data and only put the affected stream on hold.
  • improved congestion control and error recovery

QUIC in the protocol stack

Why didn’t the people at Google just build an entirely new transport protocol, instead of taking the existing UDP as their starting point? The reason is that a lot of network infrastructure has been build up over the years, and most of that wouldn’t be able to understand a new transport protocol. Operating systems might disregard it, firewalls might block it, network boxes might not process it. Of course, we could eventually update them all, but that’s quite an undertaking – remember how the much more urgent migration from IPv4 to IPv6 is already taking decades.

Instead, QUIC sits in the application layer. In order to use it, you’ll need to add it to your software. Google’s Chrome browser and YouTube app, as well as most of Google’s webservers have support for QUIC included by default. Here’s how a stack based on QUIC compares to a traditional stack using a secured TCP connection:

The image above is taken from the paper: The QUIC transport protocol: design and Internet-scale deployment (Langley et al., SIGCOMM’17), which offers a comprehensive description of QUIC.

Performance

What does QUIC do for us in terms of performance? Research has found that it can speed up the loading time of a page by about 3%. That may not sound like much, but when looking at large amounts of Internet traffic, small improvements do add up to considerable savings. Users with very slow connections would even find that the Google search page loaded a full second faster for them. Furthermore, YouTube users reported as much as 30% less rebuffering when watching videos. (Sadly, Google did not report data specific to watching funny cat videos.)

A lot of these savings come from the reduced overhead when establishing a connection, as illustrated on Google’s blog:

The future of QUIC

Google’s support and inclusion of QUIC in their software of course gives a tremendous boost to the adaption of QUIC by web users. However, a recent study has found that others are not so quic(k) to catch on.  At the moment, QUIC accounts for somewhere between 2.6% and 9.1% of all internet traffic and at most 0.1% of domains are hosted on QUIC-enabled hosts. One reason might be that software developers could be hesitant to add support to their applications, while QUIC is still a draft standard and subject to change.

So, why don’t you start up your Wireshark and see if you can catch any QUIC traffic on your machine?

1 thought on “The good, the bad… and the QUIC

Leave a Comment

Your email address will not be published. Required fields are marked *


The reCAPTCHA verification period has expired. Please reload the page.