QUIC

QUIC's place in the networking stack. Source: Iyengar 2017, slide 15.
QUIC's place in the networking stack. Source: Iyengar 2017, slide 15.

QUIC is a transport protocol that's an alternative to TCP. QUIC sits on top of UDP and uses TLS 1.3 for securing its payload. It was initially designed for HTTP use case but later evolved to accommodate a variety of use cases. HTTP on top of QUIC is often called HTTP/3.

QUIC improves on TCP in a number of aspects: faster connection establishment, reduced head-of-line blocking, better congestion control, improved privacy and flow integrity. While measurements show that QUIC outperforms TCP, there are some scenarios where TCP does better.

QUIC is being standardized by the IETF. As on January 2021, all documents are Internet-Drafts (I-Ds) and none of them are standards yet. Many open source implementations of QUIC are available in various programming languages. QUIC is actively used on the Internet by about 5% of web servers.

Discussion

  • What are the problems with TCP/IP networking stack that QUIC aims to solve?
    HTTP/2's multiplexed streams are still limited by a single TCP connection. Source: Orozco 2018.
    HTTP/2's multiplexed streams are still limited by a single TCP connection. Source: Orozco 2018.

    Each HTTP connection traditionally used a separate TCP connection. However, opening a TCP connection is slow. It requires three round trip times (RTTs): one RTT for first contact and two RTTs for TLS security. Given that increasingly more of web traffic is encrypted these days, RTTs due to TLS can't be eliminated. Though network bandwidth has increased, exchanging short packet that's typical of web traffic is hampered due to these handshake delays.

    HTTP/2 partly mitigated TCP connection problem by allowing multiple HTTP streams to share a single TCP connection. Thus, multiple HTTP streams can exchange data in parallel. But since there's only one TCP connection, a packet loss would block all HTTP streams. This problem is called Head-of-Line (HOL) blocking. It can't be solved unless we make changes to the transport layer. Solving this could be important since more and more of web traffic is coming from smartphones over lossy mobile networks.
  • What are the key features of QUIC?
    QUIC speeds up connection setups to known servers. Source: Orozco 2018.
    QUIC speeds up connection setups to known servers. Source: Orozco 2018.

    QUIC features follow from its attempt to overcome limitations of TCP/IP:

    • Connection Setup: Connection to a known server is setup with 0-RTT. Setup time increases only for new cryptographic key exchange or version negotiation. By combining cryptographic and transport handshake, setup time is less.
    • Stream Multiplexing: Overcomes HOL blocking issue by multiplexing QUIC streams over UDP. Loss of a QUIC packet blocks only streams in that packet.
    • Flow Control: Receiver specifies in terms of total bytes that a sender can send per stream and across streams.
    • Congestion Control: QUIC sits in the user space, not kernel space. Hence, updates to algorithms can be done more quickly. Different applications can potentially use different algorithms. QUIC has been integrated with CUBIC and BBR algorithms. RTT estimates are better.
    • Connection Migration: Connection is preserved even if underlying client IP address changes. Such changes are common with mobile clients, such as switching between Wi-Fi and cellular.

    Forward Error Correction (FEC) and ACK entropy are two early features of QUIC that were later removed since maintenance costs outweighed the benefits.

  • Aren't problems of TCP/IP already solved by TFO and SCTP?

    Indeed there are techniques such as TLC Snapstart and TCP Fast Open (TFO) that reduce setup time. In fact, QUIC's 0-RTT is inspired by these earlier approaches. Likewise, Stream Control Transmission Protocol (SCTP) can multiplex at the transport layer.

    However, network middleboxes interfere with the end-to-end principle. To optimize delivery of packets within the network, network operators may meddle with TCP headers, drop packets or track connections. Firewalls block unfamiliar packets. Network Address Translators (NATs) rewrite transport headers. These practices made it difficult to introduce changes such as TFO or SCTP across the Internet. In fact, the term network ossification is used in this context.

    QUIC can also suffer from network ossification. To prevent this, QUIC encrypts most of the protocol information, including some fields of QUIC packet headers. Middleboxes can't know much of what is carried and can't attempt to optimize delivery in non-standard ways. The long term benefit is that QUIC can evolve without worrying if middleboxes will support the changes. QUIC semantics remain end-to-end.

  • What are QUIC, gQUIC and iQUIC?

    QUIC started in Google in 2012. IETF started standardizing it in 2016 but as of January 2021, it's still a draft. Meanwhile, many implementations of QUIC are already out there, some supporting Google's QUIC and others focusing on IETF's QUIC.

    It's common to say gQUIC for Google's QUIC. Sometimes the term iQUIC has been used to refer to IETF's QUIC. When QUIC becomes a standard and becomes more widely supported, we expect the term QUIC to refer to IETF's QUIC. Some already use QUIC in this sense. For now, whenever adoption or performance numbers are mentioned, it would be wise to check the version used for the study.

    It's worth noting that gQUIC was specified as a monolith. IETF QUIC is more modular. Core QUIC transport, TLS with QUIC, congestion control, header compression, HTTP mapping to QUIC, version negotiation are all separate IETF drafts.

    gQUIC's cryptographic handshake was called QUIC-Crypto. This inspired the creation of TLS 1.3 that's used by QUIC.

    Clients and servers can support multiple versions and negotiate the version during connection setup. Version numbers 0x00000001-0x0000ffff are reserved for the standard. gQUIC and iQUIC versions have a separate ranges.

  • What are some essentials terms about QUIC?

    Here are some essential QUIC terms to know:

    • Stream: A lightweight, ordered byte-stream abstraction. A stream can be unidirectional or bidirectional, created by either endpoint. Streams are prioritized but priority is set by the application.
    • Frame: A unit of structured protocol information. There are many frame types. Only some of them carry streams, one stream per frame. Other frame types are for control.
    • Packet: A complete processable unit of QUIC. Multiple packets can be part of the same UDP datagram. Packets are confidentiality and integrity protection. A packet can include multiple streams but a packet loss blocks all its streams for retransmission. Preferably, a packet carries fewer streams. Packet payload is a sequence of one or more frames. Packet numbers are never reused within a connection, even for retransmissions.
    • Header: Part of a QUIC packet. Header can be long (4 types) or short (1 type). Some header fields are encrypted.
    • Connection: A shared state between client and server, which are the connection endpoints. Connection parameters are agreed during a handshake phase. Connection ID helps with correct packet delivery even when lower layer addressing changes.
  • What are some criticisms of QUIC?

    We note these criticisms or concerns about QUIC (likely to be overcome as QUIC matures):

    • Security: Network attacks on UDP are common to the extent that some enterprises and operators block UDP traffic except those arriving on port 53 for DNS. 0-RTT can be misused for replay attacks, which can be a problem with non-idempotent requests. QUIC traffic is also not recognized or analysed by firewalls.
    • Network Control: Since transport layer headers are encrypted, network operators can't optimize their networks to manage congestion. For example, they can't know if a packet is an ACK or a retransmission. Estimating RTT is more difficult. The only options appear to be a single Spin Bit and IP-level Explicit Congestion Notification (ECN).
    • Performance: Compared to TCP, UDP implementations are less performant. QUIC takes up too much CPU time. Low-end smartphones and IoT devices will suffer.
    • Latency: 0-RTT works only if load balancers maintain state and route to the same server. Since multiple versions can co-exist, each version negotiation takes an extra RTT.
    • Fairness: Since QUIC is in user space, applications and servers could implement more aggressive Congestion Control Algorithms (CCAs) that make it unfair for non-QUIC connections.
  • Could you compare the performance of QUIC against TCP/IP?
    Comparing performance of gQUIC v34 vs TCP: gQUIC outperforms TCP (red) or TCP outperforms gQUIC (blue). Source: Kakhki et al. 2019, fig. 6.
    Comparing performance of gQUIC v34 vs TCP: gQUIC outperforms TCP (red) or TCP outperforms gQUIC (blue). Source: Kakhki et al. 2019, fig. 6.

    In one study, gQUIC outperformed TCP+HTTPS in desktop environments, due to 0-RTT and quick loss recovery. In fluctuating bandwidths, QUIC did better due to better ACK handling and more accurate RTT estimates. However, QUIC was sensitive to out-or-order delivery, which it perceives as loss. QUIC is poorer on smartphones since it runs in user space. It's poorer in handling lots of small packets. It's also unfair to TCP by consuming more than its share of bandwidth.

    Researchers at RWTH Aachen University compared TCP+TLS1.3+HTTP/2 versus gQUIC performance under different network conditions. TCP parameters were fine-tuned. On a lossy network, QUIC performed better. In another test, visual web page performance was not all that different. They comment that fine-tuning TCP might suffice.

    Experiments by Fastly showed that QUIC performed poorly due to expensive memory copies between user space and kernel space. However, they matched TCP's performance by delaying ACK (a QUIC extension), using a Linux feature called Generic Segmentation Offload (GSO), and increasing the Maximum Transmission Unit (MTU) length.

  • What are some resources to get started with QUIC?

    IETF's QUIC WG webpage is the place to track the latest in standardization, or download current versions of documents.

    The QUIC project page at Chromium is worth reading. It's FAQ shows how to test a QUIC server against Chrome or build standalone QUIC server and client.

    Chrome browser enables QUIC by default. In other popular browsers, HTTP/3 and QUIC can be enabled by setting specific configuration flags.

    Implementers can join the quicdev Slack channel to coordinate interoperability testing. There are already many implementations of QUIC, lists of which are maintained at QUIC WG's Wiki and on Wikipedia. An interoperability matrix is also available online.

    We note a few of these implementations: Chromium (C/C++), ngtcp2 (C), nginx (C), quic-go (Go), and quicker (NodeJS/TypeScript).

    In 2018, it was commented that only some implementations support all the advanced features. Very few map HTTP/3 to QUIC.

  • Could you share some tools for debugging or analysing QUIC traffic?
    Decoding a QUIC packet in Wireshark. Source: CellStream 2021.
    Decoding a QUIC packet in Wireshark. Source: CellStream 2021.

    It's possible to capture QUIC traffic and analyze it offline within Chrome.

    Another tool is Wireshark. Since packets are encrypted, it's possible to load the SSL secret and then decrypt the packets. CellStream has released gQUIC and IETF QUIC profiles for Wireshark.

    Multiple implementations fragmented across QUIC versions may lead to sub-optimal performance or even buggy behaviour. Since traditional network analysis tools are tuned to TCP, new tools are needed. Hasselt University has created useful tools to analyse QUIC traffic.

    Ericsson's Spindump is a tool that makes use of QUIC's Spin Bit to figure out RTT for individual connections and aggregates. It's written in C and supports TCP, QUIC, COAP, DNS, ICMP, and SCTP traffic. It's also available as a library that can be linked with other programs.

Milestones

2012
QUIC evolves the transport layer, following improvements in other layers. Source: Eggert and Lustig 2020, slide 22.
QUIC evolves the transport layer, following improvements in other layers. Source: Eggert and Lustig 2020, slide 22.

Google's work on SPDY protocol becomes the starting point for the standardization of HTTP/2 by IETF. Previously, Google made improvements to the physical layer by building its own carrier-grade networks and CDNs. While HTTP/2 allows multiple HTTP sessions share a single TCP connection, a single packet loss affects all sessions of that connection. This becomes the motivation to innovate at the transport layer, thus kickstarting QUIC work.

Jun
2013

Google engineer Roskind makes public QUIC's design document. He notes that RTT is limited by speed of light. It's high on mobile networks. At best, we can try to reduce the number of RTTs. QUIC is a proposal to do just that. Roskind notes that prototype implementations are ready for real-world experiments.

Jul
2014

Wireshark 1.12.0 is released. This release introduces support for Google's QUIC. In August 2020, it's reported that Wireshark's support of Google's gQUIC and IETF's QUIC is still evolving.

Jun
2016

IETF accepts QUIC as an Internet-Draft. QUIC was proposed to IETF a year earlier in June 2015. IETF also renames the protocol to simply QUIC from its original expanded form of Quick UDP-Based Internet Connection. Thus, QUIC should not be treated as an acronym. The QUIC Working Group is chartered in October. Version 00 of Internet-Draft titled QUIC: A UDP-Based Multiplexed and Secure Transport is published in November.

Jan
2018

In an interview, we come to learn that 3GPP Core Networks and Terminals (CT) Working Groups are interfacing with IETF on how to adopt QUIC for 5G networks. QUIC may be considered for 5G Release 16. 3GPP expresses concerns about protocol headers being encrypted. They therefore provide IETF with requirements from network providers who often like to know more about the traffic that they carry. Meanwhile, Openwave Mobility reports more than 20% of video traffic on the networks of 30 mobile operators use QUIC. YouTube is a significant factor in this growth.

Oct
2018

The term HTTP/3 is proposed in IETF as the new name for HTTP over QUIC, which has also been called HTTP/2 over QUIC. Essentially, it's a mapping of HTTP semantics over QUIC. Its wire format isn't compatible with HTTP/2. IETF Internet-Draft version 17 titled Hypertext Transfer Protocol Version 3 (HTTP/3) is published in December.

May
2019

The engineering team at Uber reports that QUIC outperforms TCP. They used Cronet networking library for Android. In production apps, they find that QUIC reduces tail-end latencies by 10-30% even on low connectivity networks. Tail-end latencies are a big problem for Uber, being almost six times the median values.

Oct
2020

Google Chrome browser includes IETF's QUIC (v29) in addition to Google's QUIC (Q050). However, IETF QUIC 0-RTT is not yet supported. Google claims that IETF QUIC outperforms HTTP over TLS 1.3 over TCP. Google search latency is less by 2%. YouTube rebuffer time is less by 9%. Client throughput is up by 3% (desktop) and 7% (mobile). Google also notes that QUIC carries a third of Google traffic.

Dec
2020

Measurements collected by W3Techs show that about 5% of web servers use QUIC. This has grown from about 2.8% in January. Of all sites that use QUIC, about 80% use LiteSpeed server.

Jan
2021
IETF draft version 29 of QUIC is widely supported. Source: Netray 2021.
IETF draft version 29 of QUIC is widely supported. Source: Netray 2021.

Weekly scans at netray.io show that IETF draft version 29 of QUIC is widely supported. Version 29 was published in June 2020. The most recent one is version 34, published in January 2021.

References

  1. Arkko, Jari. 2019. "Gearing-up for modern Internet transport." Blog, Ericsson, January 28. Accessed 2021-01-20.
  2. AskF5. 2020. "K05822509: Decrypting HTTP/3 over QUIC with Wireshark." AskF5, February 11. Accessed 2021-01-21.
  3. Bishop, M, (ed). 2018. "Hypertext Transfer Protocol Version 3 (HTTP/3)." draft-ietf-quic-http-17, IETF, December 18. Accessed 2021-01-23.
  4. Bouzas, Santiago. 2018. "Why the Meteoric Rise of Google QUIC is Worrying Mobile Operators." Enea Openwave, January 25. Accessed 2021-01-20.
  5. CellStream. 2021. "Wireshark Profiles Repository." Resources, CellStream. Accessed 2021-01-21.
  6. Chromium. 2021a. "QUIC, a multiplexed stream transport over UDP." Chromium. Accessed 2021-01-20.
  7. Chromium. 2021b. "QUIC FAQ." Chromium. Accessed 2021-01-22.
  8. Chromium Dev. 2021. "How to capture a NetLog dump." Chromium. Accessed 2021-01-22.
  9. Eggert, Lars and Tim Lustig. 2020. "QUIC-Will it Replace TCP/IP?" Live Webcast, SNIA, April 2. Accessed 2021-01-20.
  10. EricssonResearch. 2020. "spindump." EricssonResearch, on GitHub, Novemeber 11. Accessed 2021-01-23.
  11. HTTP/3 Explained. 2020. "Common criticism." HTTP/3 Explained, June. Accessed 2021-01-20.
  12. IETF. 2021a. "QUIC (quic)." QUIC Working Group, IETF. Accessed 2021-01-20.
  13. IETF. 2021b. "QUIC (quic): Documents." QUIC Working Group, IETF. Accessed 2021-01-20.
  14. IETF. 2021c. "QUIC (quic): History." QUIC Working Group, IETF. Accessed 2021-01-20.
  15. IETF Datatracker. 2021. "QUIC: A UDP-Based Multiplexed and Secure Transport." Datatracker, IETF, January 14. Accessed 2021-01-24.
  16. IETF QUIC WG. 2020. "QUIC Versions." Wiki, quicwg/base-drafts, on GitHub, December 27. Accessed 2021-01-21.
  17. IETF QUIC WG. 2021. "Implementations. Wiki, quicwg/base-drafts, on GitHub, January 15. "Accessed 2021-01-21.
  18. Iyengar, J. 2017. "QUIC Tutorial: A New Internet Transport." IETF 98 Proceedings, Chicago, US, March 26.Accessed 2021-01-20.
  19. Iyengar, Jana. 2019. "The Maturing of QUIC." Blog, Fastly, November 11. Accessed 2021-01-20.
  20. Iyengar, J. and M. Thomson, (eds). 2016. "QUIC: A UDP-Based Multiplexed and Secure Transport." Internet-Draft, v34, IETF, November 28.Accessed 2021-01-23.
  21. Iyengar, J. and M. Thomson, (eds). 2021. "QUIC: A UDP-Based Multiplexed and Secure Transport." Internet-Draft, v34, IETF, January 15.Accessed 2021-01-21.
  22. Kakhki, Arash Molavi, Samuel Jero, David Choffnes, Cristina Nita-Rotaru, and Alan Mislove. 2019. "Taking a Long Look at QUIC: An Approach for Rigorous Evaluation of Rapidly Evolving Transport Protocols." Communications of the ACM, vol. 62, no. 7, pp. 86-94, July. Accessed 2021-01-20.
  23. Kuehlewind, M. and B. Trammell. 2020. "Applicability of the QUIC Transport Protocol." Internet-Draft, v8, IETF, November 2. Accessed 2021-01-21.
  24. Langley, Adam, Alistair Riddoch, Alyssa Wilk, Antonio Vicente, Charles Krasic, Dan Zhang, Fan Yang, Fedor Kouranov, Ian Swett, Janardhan Iyengar, Jeff Bailey, Jeremy Dorfman, Jim Roskind, Joanna Kulik, Patrik Westin, Raman Tenneti, Robbie Shade, Ryan Hamilton, Victor Vasiliev, Wan-Teh Chang, and Zhongyi Shi. 2017. "The QUIC Transport Protocol: Design and Internet-Scale Deployment." In Proceedings of the Conference of the ACM Special Interest Group on Data Communication (SIGCOMM '17), ACM, New York, NY, USA, pp. 183-196, August. Accessed 2021-01-20.
  25. Liebetrau, Etienne. 2018. "How Google’s QUIC Protocol Impacts Network Security and Reporting." Blog, fastvue, June 22. Accessed 2021-01-22.
  26. Mahindra, Rajesh, Vinoth Chandar, and Ethan Guo. 2019. "Employing QUIC Protocol to Optimize Uber’s App Performance." Uber Engineering, May 14. Accessed 2021-01-20.
  27. Marx, Robin. 2018. "QUIC and HTTP/3 : Too big to fail?!" Perfplanet, December 4. Accessed 2021-01-20.
  28. Mayer, George. 2018. "3GPP CT work on 5G." 3GPPlive, on Vimeo, January 26. Accessed 2021-01-21.
  29. Maynard, Christopher. 2020. "Wireshark doesn't show QUIC protocol." StackOverflow, August 7. Accessed 2021-01-21.
  30. Netray. 2021. "IETF-QUIC in IPv4." QUIC, Netray. Accessed 2021-01-24.
  31. Nottingham, Mark. 2015. "HTTP/2 Approved." Blog, IETF, February 17. Accessed 2021-01-23.
  32. Nottingham, Mark. 2018. "What's Happening with QUIC." Blog, IETF, October 29. Accessed 2021-01-21.
  33. Oku, Kazuho, and Jana Iyengar. 2020. "Can QUIC match TCP’s computational efficiency?" Blog, Fastly, April 30. Accessed 2021-01-20.
  34. Orozco, Frank. 2018. "How QUIC speeds up all web applications." Blog, Verizon Media, May 23. Accessed 2021-01-20.
  35. Pardue, Lucas. 2019. "HTTP/3: From root to tip." Blog, Cloudflare, January 24. Accessed 2021-01-20.
  36. Roskind, Jim. 2013a. "Experimenting with QUIC." Chromium Blog, June 27. Accessed 2021-01-20.
  37. Schinazi, David, Fan Yang, and Ian Swett. 2020. "Chrome is deploying HTTP/3 and IETF QUIC." Chromium Blog, October 7. Accessed 2021-01-21.
  38. W3Techs. 2021a. "Usage statistics of QUIC for websites." W3Techs. sAccessed 2021-01-20.
  39. W3Techs. 2021b. "Distribution of web servers among websites that use QUIC." W3Techs. Accessed 2021-01-20.
  40. Wikipedia. 2021. "QUIC." Wikipedia, January 14. Accessed 2021-01-20.
  41. Wireshark. 2014. "Wireshark 1.12.0 Release Notes." Accessed 2021-01-21.
  42. Wireshark. 2021. "News." Wireshark. Accessed 2021-01-21.
  43. Wolsing, Konrad. 2019. "Does TCP keep pace with QUIC?" Blog, APNIC, September 25. Accessed 2021-01-20.
  44. van Damme, Bramus. 2020. "How to enable HTTP3 in Chrome / Firefox / Safari." Blog, Bram.us, April 8. Accessed 2021-01-20.

Further Reading

  1. Iyengar, Jana. 2019. "The Maturing of QUIC." Blog, Fastly, November 11. Accessed 2021-01-20.
  2. Pardue, Lucas. 2019. "HTTP/3: From root to tip." Blog, Cloudflare, January 24. Accessed 2021-01-20.
  3. Iyengar, J. and M. Thomson, (eds). 2021. "QUIC: A UDP-Based Multiplexed and Secure Transport." Internet-Draft, v34, IETF, January 15.Accessed 2021-01-21.
  4. Langley, Adam, Alistair Riddoch, Alyssa Wilk, Antonio Vicente, Charles Krasic, Dan Zhang, Fan Yang, Fedor Kouranov, Ian Swett, Janardhan Iyengar, Jeff Bailey, Jeremy Dorfman, Jim Roskind, Joanna Kulik, Patrik Westin, Raman Tenneti, Robbie Shade, Ryan Hamilton, Victor Vasiliev, Wan-Teh Chang, and Zhongyi Shi. 2017. "The QUIC Transport Protocol: Design and Internet-Scale Deployment." In Proceedings of the Conference of the ACM Special Interest Group on Data Communication (SIGCOMM '17), ACM, New York, NY, USA, pp. 183-196, August. Accessed 2021-01-20.
  5. Rüth, Jan, Ingmar Poese, Christoph Dietzel, and Oliver Hohlfeld. 2019. "A First Look at QUIC in the Wild." arXiv, v2, February 24. Accessed 2021-01-20.
  6. Roskind, Jim. 2013b. "QUIC: Quick UDP Internet Connections: multiplexed stream transport over UDP." June 24. Updated 2015-06-05. Accessed 2021-01-20.

Article Stats

Author-wise Stats for Article Edits

Author
No. of Edits
No. of Chats
DevCoins
Avatar of user arvindpdmn arvindpdmn
5
0
2090
DevCoins due to articles, chats, their likes and article hits are included.
2373
Words
1
Authors
5
Edits
0
Chats
3
Likes
9996
Hits

Cite As

Devopedia. 2021. "QUIC." Version 5, March 8. Accessed 2023-11-12. https://devopedia.org/quic
Contributed by
1 author

Last updated on
2021-03-08 15:46:17
networking protocol standardization performance 5g tech

See Also

  • QUIC Packet and Frame Formats
  • QUIC Streams and Connections
  • QUIC Security
  • QPACK
  • Network Ossification
  • Transport Layer Security