This article is more than 1 year old

Don't rush to adopt QUIC – it's a slog to make it faster than TCP

Boffins say their real-world tests show developers can make more of a difference than switching transport protocols

Quick UDP Internet Connections (QUIC), the alternative to Transmission Control Protocol advanced as a fine way to speed up web traffic, struggles to deliver that outcome without considerable customisation.

So write Alexander Yu and Theophilus A. Benson of Brown University in a paper [PDF] titled "Dissecting Performance of Production QUIC". The paper was presented in April 2021, and on Monday a summary yesterday reached the blog of the Asia Pacific Network Information Centre (APNIC) – the regional internet address registry for the Asia-Pacific.

The paper explains that QUIC was designed to speed up the web (which is one reason it recently became an IETF standard) but asserts that most tests of the protocol "have only used unoptimized open-source QUIC servers on non-tuned kernels". The authors deem the resulting analyses "unrepresentative of production deployments which raises the question of whether QUIC actually outperforms TCP in practice" because many big QUIC users employ custom code.

So they conducted their own tests, which the paper states compared QUIC and TCP performance "against production endpoints hosted by Google, Facebook, and Cloudflare under various dimensions: network conditions, workloads, and client implementations."

The authors' tests used HTTP/2 (for TCP) and HTTP/3 (for QUIC) application protocols, probed for both single-object performance to assesses raw transport behaviour and multi-object performance "to understand how the application can use new protocol features". Tests also used a variety of clients and servers, all described in the paper in more detail than it is sensible to summarise.

Suffice to say their finding is that QUIC doesn't make a huge difference to the speed of transfers over the internet.

Rather, you do.

"Our findings demonstrate that most performance differences can be attributed to developer design and operator configuration choices, eg, selection of congestion control algorithms or cipher suites,” the paper concludes. "In most cases, performance differences were due to implementation details and not due to specific inherent properties of the QUIC protocol."

Which is not to say that QUIC is a dud – the authors point out that their work shows it has "inherent advantages over TCP in terms of its latency, versatility, and application-layer simplicity".

But putting those advantages to work is hard.

"We conclude that optimizing QUIC in practice can be difficult and time-consuming considering the overhead of dealing with QUIC edge cases and implementing congestion control algorithms from scratch," they write.

Benefits from use of QUIC "come at the cost of high implementation overhead, leading to inconsistencies in performance across implementations.

"By demonstrating large differences between Google, Facebook, and Cloudflare's QUIC performance profiles, we show that deploying QUIC does not automatically lead to improvements in network or application performance for many use cases," the paper ends. ®

More about


Send us news

Other stories you might like