Faster Web-Delivery via QUIC

A TCP Rival or TCP2.0? — Part 1

In this post we are going to discuss about a an upcoming protocol called QUIC.

Many companies [Uber, Google, Facebook] have already staring using it.

What is QUIC?

• QUIC (not an acronym) is protocol initially developed at Google [at that time called gQUIC, it was — Quick UDP Internet Connections-].
• Later it got adopted by IETF and defined into an RFC. RFC 9000 .
• It is a reliable Transport protocol for web and other application over UDP.
• It is designed for secure and accelerated delivery of web-applications.

Then what does Protocol Stack look like with QUIC?

Courtesy: https://http3-explained.haxx.se/en/the-protocol

• On the left hand-side, we have the current application-level stack which uses TLS1.2 or higher and HTTP1.1 or HTTP/2 as the application layer protocol.
• On the right hand-side, we have newer and adopting QUIC stack, where we make use of TLS1.3 (for security) with baked in Congestion Control and Loss Recovery mechanisms and HTTP/3 for reliable and faster delivery.

What does Quick Packet look like?

There can be multiple frames in the same QUIC packet, have just shown 3 here

• There are around 20 frames defined in the RFC.

• QUIC packets are encapsulated within the UDP packet.
• Frames are defined and encapsulated within QUIC packets.
• Each Frame has its own functionality.
• Connection between a client and server is established via Connection ID. [Like a Highway connecting source and destination and lanes within this highway is what we call Streams].

• STREAM Frame is used to send data between Client and Server — this transfer can be unidirectional or bi-directional. [So, within a connection there can be multiple streams of same or different communications.]

What are the TCP limitations it helps overcome?

1.)

• There is no more change room left in Headers of TCP. Lots of efforts have been put to improve TCP.
• There are some proposal to make things fast like: SCTP, TCP Fast Open and MPTCP [Multipath TCP].
• So, why not try to include advantages of above-mentioned protocols with TCP like features, in just one protocol, with reduced overhead on bandwidth. Hence, QUIC.

2.)

• Using applications over TCP requires higher network RTT [First is TCP Handshake, then TLS Handshake and then the Data Transfer].
• Since QUIC has TLS1.3 as its core function, we have direct TLS handshake from the first packet itself.

From Paper: Innovating transport with QUIC: Design approaches and research challenges

• If there is already a preexisting session in the recent past, client can send direct GET (data packet) in the first packet itself creating a 0-RTT performance.
• This is done why the cryptographic “cookie” and Diffie-Hellman value that gets stored on client during the first connection establishment.

3.)

• Head-Of-Line blocking.
• Though with HTTP/2 we started using Multiplexing which enabled client to send multiple requests concurrently and better utilize the bandwidth.
• But all these multiple concurrent sessions were over a single TCP connection.
• Hence, even when a single packet gets drops for any of the streams on that connection, because of the nature of TCP, it will cause blocking to the other working streams which did not see the packet loss.
• Here, TCP is unaware of the Streams that are being sent over HTTP/2 multiplexed so it does what TCP does to recover lost data i.e., waiting on the lost data to be re-transmitted, during this wait-time all other streams are blocked too.
• QUIC, however avoids this by implementing Stream ID in the QUIC packet itself and just stream re-transmit lost stream to avoid blocking other streams.

More Information on HoL blocking in HTTP/3 over QUIC: https://calendar.perfplanet.com/2020/head-of-line-blocking-in-quic-and-http-3-the-details/#sec_http3

4.)

• NAT devices [in between Client and server], uses 5 tuple hash [Client IP, Destination IP, Client source port, Destination port, protocol] or 4 tuple hash (no protocol) to keep the connection going with the server.
• So, when the NAT connection breaks the source port would change leading to a new connection from NAT device to server.
• Since this is new flow, server might not respond to the end client’s request as it will consider this as new connection.
• QUIC, avoid this by using something called as Connection ID, rather than relying on ports or IP. This helps to perform “Connection Migration”.

5.)

• TCP headers are not encrypted.
• QUIC — headers are authenticated and encrypted. This helps in keeping the connection temper-proof from the middleboxes.
• Not much can be derived about the connection even if we take packet capture. We can only check the packets once they are decrypted.

From Paper: Multipath QUIC: A Deployable Multipath Transport Protocol

More information on QUIC packet and header protection: https://blogs.keysight.com/blogs/tech/nwvs.entry.html/2021/07/17/looking_into_quicpa-pUtF.html

QUIC can be used for better bandwidth utilization, faster packet delivery and with the same goodness that you get in TCP connections.

Let us see how it looks like in WireShark in Part 2.