QUIC (Quick UDP Internet Connections) is an experimental transport layer network protocol originally designed by Google. The overall goal is to reduce latency compared to that of TCP. While QUIC is largely invisible to end users except through improved performance, it also subtly impacts how networks are managed, how private the connections are, as well as future evolution. As a result, it is important for network architects and administrators to understand these impacts, and to prepare for them.
Speeding-up the internet with Google's QUIC
QUIC's design is focused on minimizing latency in the connection setup phase, protecting the QUIC packets and headers with encryption, and maximizing the ability of QUIC to evolve.
While TCP is typically implemented in the operating system kernel, QUIC is typically implemented as part of an application such as a browser. This allows a fast pace of adoption and future evolution. And given the use of encrypted headers, it is expected that lack of updates to middle boxes that process those headers is not as big deterrent for evolution in QUIC as it was for TCP.
That being said, the network and the endpoints co-operate to provide the most efficient service for the application, each having their own role. Having some information about how well the connections are doing can be helpful in managing the underlying network. For instance, if connections experience excessive delays, that can be an indication of a problem somewhere in the network. Or there at least exists an opportunity to adjust the network in some manner.
The QUIC design keeps all information about connections it carries private. But it has an ability to expose round-trip times for some connections, making it possible for the underlying networks to observe the latency situation for the traffic being carried, at least from a statistical perspective. The so called "Spin Bit" in the QUIC header is used to convey this information.
The standardization work for QUIC happens at the Internet Engineering Task Force or IETF, in the QUIC working group. The group is finishing the final details of the first standard. The work of the group happens mostly on the mailing list, but a few times per year they meet in person for an active face-to-face session.
This week key participants of the working group are meeting in Tokyo, Japan. In addition to the standard discussions, a big part of the work relates to testing different implementations against each other in a two-day interop session.
This is a typical IETF approach to standards, as the specifications are not as important as running code. The work is only complete when the actual products work in different situations and against each other.
Ericsson has been a long-time contributor to this effort, and we've driven the need for the underlying networks — such as Ericsson's 5G networks — to be able to take advantage of the low-latency communications offered by QUIC, and the need to manage and tune those networks appropriately.
We at Ericsson also believe in running code. It is important to have all the necessary tools in the ecosystem to deal with a new transport protocol.
For this week's QUIC interop event, for instance, we are publishing a new open source tool, Spindump. This tool can be useful in debugging QUIC connections, measuring their latency, and ensuring that the QUIC protocol and its header bits are correctly interpreted by the different systems.
To learn more about QUIC, read our earlier blog post QUIC – a vehicle for transport protocol evolution.
Or check out the Ericsson Technology Review article on queue management in mobile networks: Low latency, high flexibility - Virtual AQM
