QUIC - Birth of New Protocol in Layer 4 Family

Introduction

TCP has been dominant transport protocol under the hood of most applications and services for over 40 years, but now it has competitor. First invented at the Google and now in the hands of the IETF (Internet Engineering Task Force), QUIC is already being used today to deliver many of the webservices that we know (e.g., YouTube, Uber, Facebook, etc.). Now, a lot of this has happened under our noses over the past few years. But with QUIC becoming a standard, we will soon see it deployed all over the internet to deliver web and mobile applications to end users. This article covers the key concepts about QUIC that every network engineer, developer, and cybersecurity professional should know. Some of the major topics covered, include, why a new transport protocol was needed, how QUIC is different from TCP, how QUIC securely and reliably transports data while sitting on top of UDP. After reading this you will know how to QUIC is different from existing layer 4 protocols.

Image Source

Why a new transport protocol was needed?

To understand QUIC first we need to understand the need of inventing new protocol. Undoubtedly, long serving protocols TCP and UDP have some limitations which drives the need of new protocol. By nature, UDP is like a negligent child of layer 4 family who don't really care about building connections, avoid handshaking, no interactive conversation etc. which is why UDP failed to land a job in sectors where reliability and data integrity is foremost important. However, due to its nature it is widely used in applications that are "lossy" (can handle some packet loss), streaming media audio/video.

On the other hand TCP is more like a hard-working child, who believes in building good connections, interactive communication, avoid any misunderstandings through build-in error recovery and re-transmission. In a nutshell UDP is like an earlier pigeon message delivery service, whereas TCP is more like reliable shipping service (USPS, FedEx etc.) that guarantees delivery.

QUIC is the newborn in the family, owns all the handy features of both UDP and TCP.

More specifically QUIC is implemented on top of UDP but very similar to TCP.

QUIC ≈ TCP + TLS + HTTP/2

So why we did not update existing TCP?? Why we gave birth to entirely a new protocol??? This is because TCP runs on top of operating system kernels, and middlebox firmware. Any significant changes in existing TCP are nearly impossible. On the other side of the coin, building QUIC on top of UDP resolves all such limitations.

How QUIC is different from TCP??

1) Connection Setup

To build communication between two systems, TCP first has to setup three-way handshake. Additionally, separate roundtrip is required to setup secure communication through SSL/TLS handshake. Thanks to TLS 1.3, before that multiple roundtrips were required to exchange certificates to get the connection going. After all these overheads finally, application begin to use this connection and communicates with server. Noticeably, if we see here from the beginning of the connection all the way until client receiving its first response, minimum three roundtrips are required, that is if everything exactly went as it should!

One might argue, hey Avenash, come-on it is not a big deal!!! Well, if you are sitting really close to the server then yes! it may not be! However, if you are living other side of the ocean then definitely it does matter. The nice thing about QUIC is since it runs over UDP there is no need to setup that initial TCP three-way handshake. And guess what!! it is already sending packets securely.

Unlike TCP, QUIC by default supports secure communication. This is done by merging TLS and transport handshakes together, that results minimizing total number of roundtrips for setting up the secure connection. QUIC initiate most of its communication with 0-RTT, which refers client's request can be sent immediately without worrying about initial handshakes. To understand more about QUIC's secure connection and its important security caveats please refer Google's Parsing QUIC Client Hellos.

Image Source

2) Congestion Control

TCP and UDP primarily works at kernel space, making any fundamental changes will take ages to become standard. In contrast QUIC is implemented in user space which naturally open new doors for improvement to overcome existing limitations of TCP. QUIC supports configurable congestion control mechanism and provide richer information to congestion control algorithms compare to TCP.

One such example of richer information is QUIC carries new packet for sequence number for both original and retransmitted packet. This helps packet sender to differentiate between original ACKs from retransmission ACKs, hence this eliminates TCP's limitation of ACKs ambiguity problem.

Furthermore, QUIC also provides precise calculation for roundtrip-time (RTT). This is achieved after making improvement over traditional ACKs. QUIC ACKs carry information for delay between the receipt of a packet and its acknowledgment being sent. Finally, QUIC's ACK frames support up to 256 ack blocks, so QUIC is more resilient to reordering than TCP (with SACK), as well as able to keep more bytes on the wire when there is reordering or loss. This helps both communicating parties to have complete details for the packets peer has received.

3) Multiplexing

Being a newborn QUIC was already aware about the limitations of elder siblings. From the ground up, the main intent behind the birth of new protocol was to overcome all such obstacles which elder siblings failed to do so. With HTTP/3 QUIC supports native multiplexing which means lost packets will only impact streams where data has been dropped. This improves overall throughput and reduce latency for poor or slow internet connections.

HTTP/2 on TCP tried to do same thing but failed!! It suffers from ahead-of-line blocking i.e., several streams’ multiplexes through TCP's single-bytestream, any Loss of TCP segment results in blocking of all subsequent segments until a retransmission arrives. In contrast, with QUIC streams having no segment loss can continue to make forward progress in the application.

Image Source

4) Connection Migration

When switching mobile data plan to Wi-Fi connection, while watching video stream, have you ever noticed a connection lag??? I am sure many of you have notice that, if not give a try. Sometimes I personally close entire application and reopen to make it work. This is due to change in IP address/port number. TCP connections cannot survive any changes in IP address or port number. MPTCP (Multipath TCP) tried to solve this issue for TCP but still plagued by lack of middlebox support and lack of OS deployment.

Unlike TCP, QUIC connections do not really care much about IP address or port number, instead they rely on client's randomly generated 64-bit Connection ID. Connection ID remains same, regardless of change in IP address/port number, which is why these connections can survive any NAT re-bindings. In addition to that QUIC natively supports cryptographic verification of a migrating client since resettled client continues to use same session key for the purpose of encrypting and decrypting data packets.

Conclusion

The new child of Layer4 family have all the skills and attributes to turn things around for its family in the favor of data security, better performance, throughput, and latency. The majority of Facebook and Google's backend already uses QUIC. As far as the client-side implementation is concerned, it exists in the form of Chrome Browser and Android OS. These clients have all the ingredients to access servers that supports QUIC (e.g., Google docs, Google drive, Youtube, Facebook etc.). In this article I have covered how QUIC is different from its sibling TCP and UDP. It has potential to be the new big thing in tech industry. The effective use of this protocol can offer good results at browser level. Moreover, QUIC can make a worthwhile contribution in regions where internet connection speed is slow.