Are You Ready for the New Challenges of QUIC?
In 2013, Google announced a new transport protocol, the QUIC protocol (Quick UDP Internet Connections). QUIC’s original goal was to reduce transport latency, particularly with users of web apps (that use HTTP over TCP). The goal was later expanded to provide a reliable, connection-oriented, low-latency, fully encrypted transport layer.
Approximately 0.9% of all websites use QUIC.
QUIC attempts to optimize elements of important, traditional protocols into a new solution that arguably better addresses modern Internet applications, like gaming, streaming, mobile web access, etc.
Will the Internet migrate from TCP, TLS, etc. to QUIC? Or will QUIC nicely co-exist with these protocols?
For Internet users, any changes to the plumbing will likely be transparent, but for Internet infrastructure suppliers, these changes are enormous.
For QUIC to have a chance at wide-scale adoption, several things must occur:
QUIC must demonstrate clear, compelling advantages that vastly outweigh the installed protocols.
Standard test and diagnostic tools must detect and report on QUIC, so that QUIC errors or performance issues may be resolved.
QUIC must be adopted and advanced through the IETF.
Independent, unbiased benchmarks of QUIC in large scale operation must be vetted and published.
QUIC must be implemented and tested for interoperability with multiple, independent implementations (an IETF requirement).
We predict these requirements will be challenging for Google (QUIC’s backer). Google has traditionally taken a university / research approach to software development. Google engineers will prototype a new technology for internal purposes, and then make that technology available to the general public, at no charge, but typically unsupported and undocumented. It seems that Google may be taking a different approach with QUIC by soliciting feedback and cooperation from the developer community.
Let’s review these considerations for wide-scale adoption, one at a time.
QUIC must demonstrate clear, compelling advantages that vastly outweigh the installed protocols.
Unlike TCP (that has congestion avoidance built in to the protocol), QUIC has attempted to shift congestion-avoidance to the application layer end points. Well, that’s intriguing, but does it work? Is it an advantage? How is it an advantage? Do the app developers have to code this? This could be a great simplification and performance improvement to the protocol, but if the problem has just moved to app developers, then the advantage is limited.
Standard test and diagnostic tools must detect and report on QUIC, so that QUIC errors or performance issues may be resolved.
Good news here. The latest version of Wireshark (2.6) supports QUIC so it is possible to get Wireshark snapshots and review the details of the QUIC network transaction.
In addition, an IETF draft (draft-trammell-quic-spin-03) “...describes the addition of a ‘spin bit’, intended for explicit measurability of end-to-end RTT..” If this draft is adopted and implemented, the QUIC protocol would have built in measurability which would go a long way towards performance measurement and benchmarking.
QUIC must be adopted and advanced through the IETF.
Good news here. QUIC is a chartered working group in the “Transport Area” of the IETF. There are nine QUIC Internet-Drafts and 13 related Internet-Drafts. Meetings have occurred for the past two years.
Independent, unbiased benchmarks of QUIC in large scale operation must be vetted and published.
So far there are no reports from large operators or other testing organizations describing QUIC performance and operation. At the most recent Passive and Active Measurement Conference (March 2018 in Berlin), a group of researchers determined that QUIC “in the wild” accounts for 2.6% to 9.1% of current Internet traffic (with many caveats and qualifications). This is most likely due to operators still learning about it, and more importantly, the rapidly changing standard. No one likes to write code for a moving target; the industry is waiting for an approved standard.
QUIC must be implemented and tested for interoperability with multiple, independent implementations (an IETF requirement).
Several organizations – Akamai, Apple, Cisco, Google, Pandora, University of Hasselt-Belgium -- have reported testing and experimental (or production) deployments of QUIC.
Of course, there is the IETF’s interoperability issue, e.g. that independent implementations must work properly with each other. Then there is the operational deployment interoperability issue, e.g. that QUIC does not present new problems for other apps and devices deployed on the Internet.
Our conclusion is that it is still too early to judge QUIC. We acknowledge that many of our protocols are not highly optimized for today’s Internet. QUIC is a step in the right direction, but is it a big enough step? Will the effort and investment to deploy QUIC demonstrably and materially improve the Internet? We will wait and see.