QUIC is a connection-oriented transport protocol that provides a reliable data stream delivery service over UDP. This is similar to an independent TCP connection, but with drastically reduced connection setup latency (0-RTT). It is proposed as a new transport that HTTP/2 built on top of UDP.
It was initially developed in 2012 by Google in order to take advantage of the work done with SPDY to create a transport protocol with a faster connection setup time and built-in security.
QUIC is being discussed at TPAC this week as a potential extension of the WebRTC specification.The hope is that it will advance the specification by improving the initiation time via reduced latency and by allowing developers to experiment more freely.
Why is QUIC Interesting?
QUIC is designed to reduce latency in a few key ways, especially through improved multiplexing support, a decreased number of roundtrips, and improved packet loss handling.
QUIC is implemented in the user space instead of the kernel space. The hope is that this will allow developers flexibility to improve congestion control over time, since it can be optimized and replaced and allows for rapid deployment. This differs from TCP, because TCP is implemented in the kernel space. This prevents flexibility, since kernel upgrades happen much less frequently than user upgrades. The hope is that if the application requires a specific implementation, the developer will now be able to provide it.
QUIC integrates strong security features by using TLS 1.3 for key negotiation. The initial QUIC handshake combines the typical three-way handshake that you get with TCP with the TLS 1.3 handshake, which provides authentication of the endpoints as well as negotiation of cryptographic parameters. For those familiar with the TLS protocol, QUIC replaces the TLS record layer with its own framing format, while keeping the same TLS handshake messages. HTTP/1 and HTTP/2 already use TLS 1.3.
What does QUIC Have to do with WebRTC?
QUIC is being introduced at TPAC this week as a potential extension of the WebRTC specification. It has been widely discussed since last year to see if QUIC can bring significantly new use cases, which typically allow the application developer no control. In addition to sending arbitrary data over QUIC, sending media over QUIC is also considered, as documented by us here.
Since QUIC is in the user space, it also holds a lot of promise to be easily changed and updated - an important qualification for WebRTC developers. The goal of QUIC for WebRTC is twofold. First, to enable faster connection setups through zero round trips. Second, to use newer congestion control algorithms that handle congestion in a more efficient way and recover from congestion more effectively than TCP. Discussions of QUIC and WebRTC focus around data transfers, and speculatively about media.
How Does QUIC Reduce Latency?
QUIC drastically reduces latency through a few methods.
1. Improved Multiplexing Support
HTTP/2 over TCP multiplexes and pipelines requests over one connection. This means that a single packet loss and retransmission packet causes head-of-line blocking (HOLB) for all the resources that are downloaded in parallel - the entire set of streams. The first packet holds up the rest of the line. QUIC overcomes the shortcomings of multiplexed streams by removing HOL blocking.
2. Fewer Round-trips
Figure 1: TCP, TCP + TLS, & QUIC Trips
QUIC clients are able to include session negotiation information in the initial packet instead of through a separate packet.
QUIC servers publish a static configuration record that can be consistently referenced.
QUIC clients store a synchronization cookie so they are able to connect to the server again easily and with no overhead.
3. Improved Packet Loss Handling
QUIC is able to handle packet loss effectively due to several modern techniques. This may depend on what the developers choose to implement in QUIC, but since it is very flexible, it is possible the default version will include the techniques mentioned here.
QUIC may align cryptographic block boundaries and packet boundaries to reduce packet loss.
QUIC may use improved congestion control, including packet pacing based on ongoing bandwidth estimation.
QUIC may send duplicates of the most critical packets, also known as proactive speculative retransmission.
Looking to the Future
The hope is that QUIC may be used to accelerate the evolution of transport protocols. By implementing transport protocols in user space instead of kernel space, transport protocols can promote rapid deployment and flexibility for increased innovation. QUIC is able to evolve in weeks or months, and is available for rapid expansion and growth.