QUIC is around, it is being tested on you!

A QUIC Introduction

QUIC is UDP-based network protocol designed by Jim Roskind at Google. Initially implemented by Google in 2012 and announced as an experimental project in 2013. TCP & UDP are the widely-used protocols over Transport Layer and both protocols have their own advantages & disadvantages. To leverage the advantages of both protocols, Google redefined internet transport called QUIC - Quick UDP Internet Connections.

QUIC Features

QUIC reshaped the key mechanisms (connection establishment, stream multiplexing, congestion control & reliability) of TCP, outline is as follows: QUIC Negotiation & Connection Establishment QUIC offers "Zero-RTT" with equivalent security as “TLS over TCP” but with lower latency. In TCP, connection establishment is a three-way handshake negotiation process that means additional roundtrip-time (RTT) for starting a connection which adds significant delays to any new connection establishment. On top of that, if TCP also needs to negotiate TLS for a secure connection, more network packets need to be sent back & forth which means furthermore delay to the connection establishment.

QUIC Congestion Control & Loss Recovery

QUIC offers pluggable congestion control, TCP Cubic is reimplemented as the default congestion control algorithm. which enables QUIC to provide richer information to congestion control algorithms than TCP. QUIC uses a monotonically increasing sequence number for an original packet as well as retransmitted one, which never gets repeated in a lifetime of a connection. This helps to determine ACKs for retransmissions from ACKs for original transmissions, thus suppressing TCP's retransmission ambiguity problem. QUIC precisely calculates roundtrip-time (RTT) based on the delay between the receipt of a packet and its acknowledgment being sent along with monotonically-increasing packet numbers.

QUIC Stream & Connection Flow Control

QUIC implemented flow control at stream-level & connection-level.In stream-level connection flow, receiver advertises the offset limit upto which it is willing to receive the data. On a particular stream, after successful data transmission, the receiver sends WINDOW_UPDATE to increase the advertised offset limit for that stream, which allows the sender to send more data on that stream. Connection-level flow control works in the same way as stream-level flow control, but the delivered & received offsets are all aggregates across all streams. In stream-level connection flow, receiver advertises the offset limit upto which it is willing to receive the data. On a particular stream, after successful data transmission, the receiver sends WINDOW_UPDATE to increase the advertised offset limit for that stream, which allows the sender to send more data on that stream. Connection-level flow control works in the same way as stream-level flow control, but the delivered & received offsets are all aggregates across all streams.

Multiplexing without Head-of-Line blocking

Head of line (HOL) blocking is the performance-limiting phenomenon that occurs when HTTP/2 multiplexes many streams on top of TCP single-byte stream abstraction. As a segment loss in a TCP causes blocking of all subsequent segments until a retransmission covers the loss. QUIC is designed from scratch to support multiplexing, a segment loss in an individual stream generally only impact that specific steam. So, the streams without loss can continue to be reassembled and make forward progress in the application.

Authenticated and Encrypted Header & Payload

TCP headers transit as plaintext & not authenticated, causing the possibilities of active attack like injection, header manipulation (receive-window or sequence-number manipulation) etc. QUIC packets are always authenticated and typically the payload is fully encrypted. The parts of the packet header which are not encrypted are still authenticated by the receiver, so the possibilities of active attack are very less. not authenticated.

QUIC Forward Error Correction

Forward Error Correction (FEC) is a proactive loss recovery scheme. QUIC uses XOR-based Forward FEC, the XOR-based mechanism has a concept of a ‘group’ of packets. The group number is indicated on each packet in the group, as well as on the XOR packet sent to protect the group. If any of the packets is lost, the contents of that packet can be recovered from the FEC packet and the remaining packets in the group.

QUIC Connection Migration

A TCP connection uniquely identified by a four-tuple (source address, source port, destination address & destination port). If any of the tuples attributes changes (for example, by switching from Wi-Fi to cellular) TCP connection do not survive. QUIC connections are identified by a 64-bit Connection ID, randomly generated by the client. QUIC can survive IP address changes and NAT re-bindings since the Connection ID remains the same across these migrations.

QUIC in Action

QUIC integrated (experimental) with the Chrome version 2 since 2013. QUIC is enabled by default in Chrome. Post QUIC support verification, see QUIC in action by opening the chrome://net-internals/#quic: Verify the Connection ID (CID) in traces using Wireshark:

QUIC Implementation

As wireless networks experience hardship with network congestion, wireless interference & poor connection, QUIC is immensely suitable for the mobile applications where TCP faces shortcomings. As QUIC supports RESTful API, it improves server-2-server & server-2-client communications built on top of REST or other protocols that use HTTP today. The noteworthy surge has attracted open source community for flavored QUIC implementations. QUIC in GO - https://github.com/devsisters/goquic QUIC in Caddy - https://github.com/mholt/caddy QUIC in Docker - https://hub.docker.com/r/devsisters/quic-reverse-proxy/ QUIC in Node.js - https://github.com/toajs/quic QUIC in RUST - https://github.com/iorust/quic QUIC in benchmark tool - https://github.com/devsisters/quicbench QUIC for .Net - https://github.com/seanmcelroy/QuicDotNet To explore QUIC, Google provided step by step chromium code base client & server implementation - http://www.chromium.org/quic/playing-with-quic

QUIC Summary

The glimpse of experimental improvements:

50 - 80% of the overall latency reduces.
25% retransmission reduces.
5% faster page loading times on average.
1-second faster for web search at 99th-percentile.
30% lesser rebuffering on YouTube videos.

Predicted Internet Video Traffic will be 80% by 2019. To deal with emerging video, gaming & virtual reality based traffic QUIC and other new network improvements are important. Cloud-based communication and collaboration to do also. The IETF committee to standardize it is underway.