你对新的QUIC协议带来的挑战作好准备了吗?

你对新的QUIC协议带来的挑战作好准备了吗?

Are you ready for the new challenges of QUIC?

2013年，谷歌宣布推出新的传输协议QUIC协议（Quick UDP Internet Connections）。 QUIC的最初目标是减少传输延迟，特别是对于Web应用程序（使用HTTP over TCP）的用户。 该目标后来扩展为提供可靠的，面向连接的，低延迟，完全加密的传输层。

 

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:

1. QUIC must demonstrate clear, compelling advantages that vastly outweigh the installed protocols.
2. Standard test and diagnostic tools must detect and report on QUIC, so that QUIC errors or performance issues may be resolved.
3. QUIC must be adopted and advanced through the IETF.
4. Independent, unbiased benchmarks of QUIC in large scale operation must be vetted and published.
5. 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.

1. 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.

2. 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.

3. 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.

4. 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.

SOURCE: https://arxiv.org/abs/1801.05168

REFERENCE: https://pam2018.inet.berlin/

5. 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.