As computer scientists notice TCP's limited ability to support new, more advanced Internet services, interest in QUIC is rising. QUIC is the leading candidate to replace TCP as a transport protocol, and may bring new life to Internet data delivery.
In a previous post, we discussed what QUIC is, its goals, and how it works. Now we’d like to address a slightly different question: is it really worth adopting? Below is a deep dive into the advantages and disadvantages of using QUIC.
The benefits of QUIC
QUIC enthusiasts point to ways that the protocol will make the Internet more efficient, fast, secure, and evolvable.
1. Extensibility
It’s tough to make any changes to TCP, because middleboxes are resistant to new behaviors, and TCP’s 40 bytes of optional bits are almost fully populated (for more information, see our post on QUIC and the Future of Transport) .
TCP does not have any version negotiation field bits, and in contract QUIC has 32 bits. That allows plenty of space for the rapid deployment of new versions, and for vendors to define their own proprietary versions.
2. User-space implementation
QUIC can be implemented in the application space, enabling modifications to be rolled out faster than with TCP, which is implemented in the operating system (OS) kernel. This further enhances QUIC’s extensibility to potentially allow for very rapid service evolution, permitting new features to be deployed even on a daily basis. It also facilitates higher responsiveness by involving less overhead when context switching.
3. Faster connection and setup establishment
Web browsing, in particular, requires rapid setup for connections because the user opens multiple, often short-lived connections. When using HTTPS, TCP connections require what’s termed a “3-way handshake,” followed by setup of the TLS protocol, before establishing the connection.
QUIC (which is based on UDP) doesn’t require a 3-way handshake, plus it exchanges security keys as part of the initial handshake process, making it twice as fast at setting up an encrypted connection.
4. Reduced sensitivity to packet loss
With TCP, if a data packet is dropped, all the subsequent packets are held up until the missing one is sent. This is termed “head of line blocking” and can cause a significant increase in latency.
QUIC, in contrast, uses a multiplexed HTTP2 connection scheme, which supports multiple data streams concurrently. If an error occurs in one data stream, causing packet loss, the other data streams will continue to send data packets without holding up transmission.
This figure below shows an example of connections with a congestion window of 3 packets in which packet 0 was dropped. In the TCP connection with a single data stream, the subsequent packets are held back. The QUIC multiplexed connection has three data streams, each operating independently. As a result, Data Stream 2 and 3 still progress, and only the subsequent packets of Data Stream 1 are held back.
5. Improved performance when switching networks
QUIC offers a smooth transition from one network to another; for example, if you’re watching a video on your phone at home using home wifi, and then switch to LTE when you walk out the door and leave the wifi connection, or when you’re streaming on the go and roam between mobile base stations.
In these situations, TCP will kill the connection and create a new one with the new network, interrupting your viewing experience, while QUIC can allow seamless switching.
6. Improved security and privacy
QUIC has encryption built into the transport layer that authenticates the entire payload, including the header. TCP doesn’t include encryption in the header, making it vulnerable to attacks. As a result, QUIC supports secured TLS by default, which means full end-to-end security.
Limitations of QUIC
TCP was invented at a time when every connection was wired and fairly reliable, which obviously isn’t the case any more. QUIC brings improvements in unreliable, unpredictable wireless links, but it still doesn’t change the essence of Internet delivery which limits its ability to be considered as a game changer for certain usage scenarios. Here are some additional limitations of QUIC.
1. Migrating an app can require significant effort
There is an effort involved in migrating an app from HTTP/2 to HTTP/3, or from TCP to UDP. It requires transferring the entire app layer implementation and transport layer implementation to UDP, and building a completely new solution on both the server-side and the client-side.
This is a challenge for small streaming vendors with limited resources, and explains why extremely large companies like Google and Microsoft have been the first to adopt the protocol.
2. Limited adoption
The biggest drawback to QUIC is that its adoption is still limited. Almost every web browser accepts it for simple web browsing, yet none except for chromium define it as the default.
In addition, when it comes to streaming, very few are using QUIC beyond Google and Facebook. Only a few CDN providers support QUIC, and even among them, some have a couple of caches supporting it as a proof of concept, without readiness for deployment at scale. This could cause a problem if you launch a new QUIC-based service using a multi-CDN implementation, and only 20% of your caches are rolling to QUIC, because you wouldn’t be able to demonstrate a noticeable impact on user experience to your customers.
3. QUIC includes a TCP fallback
Part of the reason that QUIC was built on UDP is because UDP is blocked by the fewest middleboxes and network devices. But there’s still a risk that it could be blocked, so QUIC-based apps have to be designed to fall back to TCP, just in case.
This means that developers of QUIC-based apps have the burden of developing and maintaining two different versions (due to TCP fallback as well as limited adoption rates).
The good news is that with the newest DEVOPS structures and usage of HTTP’s Alt-Svc tags, supporting two protocols has become much simpler than it used to be.
4. No packet inspection
Network firewalls aren’t able to decrypt QUIC traffic to inspect packets, so potentially malicious traffic could enter the network without getting picked up by standard security features. As a result, security vendors such as Cisco and Palo Alto Networks routinely block QUIC packets on ports 80 (web server) and 443 (TLS) assuming that they might contain malware, forcing clients to fall back to using HTTP/2 and TCP protocols.
While this wouldn’t significantly affect the experience of content consumers, because a properly-implemented streaming service would default back to TCP + TLS, it might defeat the purpose of deploying QUIC in the first place. This challenge needs to be addressed to allow QUIC to be widely accepted in enterprises.
5. Some TCP features aren’t included
There are some features, e.g., throttling, which are included by default in TCP, to the extent that they are often taken for granted. But with QUIC, you may need to build them for yourself.
In addition, HTTP3 lacks some features that are needed for the introduction of certain
protocols. For example, the HTTP3 spec still does not support chunked transfer, i.e. the ability to split a segment into small chunks, a feature which is supported by HTTP1.1. This limits the number of possible protocols that can be used for QUIC-based video streaming.
Therefore, while QUIC supports the most common streaming protocols (e.g., HLS, MPEG DASH), at this stage, it can’t support as is, some of the more novel protocols which aim to reduce glass-to-glass latency, such as LL CMAF (Low Latency Common Media Format), which rely on support for chunked transfer.
6. Fingerprinting could be easier
A new concern that is still being investigated is the risk that malicious actors could sniff network traffic between Internet users and the websites they visit, and use the observed packets to build distinct patterns that correspond with specific websites. This is called web fingerprinting, and it seems that TCP+ HTTPS are more resistant to it,at the early connection traffic phase.
7. QUIC may need higher CPU usage
There are some claims that HTTP3, which is needed for QUIC, uses more CPU power both on the client side and on the server side. However, Google argues that on the contrary, QUIC helps extend battery life.
Either way, this isn’t expected to be a significant issue once QUIC becomes part of the mainstream tech stack.
8. Multitude of protocol implementations
Since it took more than 5 years for the release of the first IETF version of QUIC, there are currently 60 QUIC version implementations on the market, which were developed prior to the spec release. As a result, most of them either don’t support the full spec, or support their own interpretation of it. Widespread adoption of QUIC can only occur once the different versions are aligned with the released QUIC specification.
9. The Internet is still optimized for TCP
TCP delivery has existed for many decades and over the years TCP applications have been thoroughly optimized by building off-load capabilities in both software (e.g the operating system kernel) and hardware (e.g. network interfaces and Smart NIC’s). None of these exist for QUIC, which is based on UDP and resides in the user space, so its endpoints and even some middlebox functions have a significant disadvantage at this stage. Such optimization is expected to be implemented in QUIC once it is more widely adopted, yet it is a temporary disadvantage of QUIC.
QUIC vs. TCP: Impact on quality of experience
QUIC supports some unique features and provides more flexibility in new feature implementations. As a result, QUIC-based apps are expected to deliver QoE benefits over TCP implementations.
Here are two common use cases where QUIC is expected to bring QoE benefits:
Web browsing - QUIC supports built-in TLS and establishes connections rapidly. It is expected to provide significant performance benefits in cases where the majority of the connections are short-lived, such as faster download times for secured websites. Google claims a 10% reduction in page loading times for apps running on QUIC.
Video streaming - QUIC supports certain features which are expected to improve QoE for video streaming. So far, the predicted impact has been limited, because its implementation logic is similar to TCP’s, but there are some cases where QUIC benefits could already be experienced. E.g. QUIC’s ability to mitigate “head of the line blocking” can provide benefits to QoE for a network with mid to high packet loss.
QUIC may be an improvement, not a game changer
QUIC does bring incremental benefits for Internet users, but it’s debatable whether or not it’s truly a game changer. There are solid reasons for adopting it, but also some valid issues and early adopter challenges that encourage a “wait and see” approach. Whatever you decide, TCP or QUIC, Compira Labs can support you and deliver the best QoE for your users.
About Compira Labs
Compira Labs is a pioneer in ML-powered content delivery. Its software-only solution can easily upgrade any CDN to deliver best-in-class QoE even in the most challenging last-mile networks. Compira Labs’ solution can dramatically improve user experience for latency-sensitive and bandwidth-hungry Internet services such as live and on-demand video streaming, game downloads etc. It is available for both HTTP/TCP and HTTP/3/QUIC delivery methods.
Comments