Skip to content
Back to the collection

QUIC is not Quick Enough over Fast Internet

Xumiao Zhang, Shuowei Jin, Yi He

Show all 7 authors

Ahmad Hassan, Z. Morley Mao, Feng Qian, Zhi-Li Zhang

2023 · arXiv

Read the paper
HN score
0
Mentions
5
Readers
5
Months
4
What’s in a score?

From the abstract

QUIC is expected to be a game-changer in improving web application performance. In this paper, we conduct a systematic examination of QUIC's performance over high-speed networks. We find that over fast Internet, the UDP+QUIC+HTTP/3 stack suffers a data rate reduction of up to 45.2% compared to the TCP+TLS+HTTP/2 counterpart. Moreover, the performance gap between QUIC and HTTP/2 grows as the underlying bandwidth increases. We observe this issue on lightweight data transfer clients and major web browsers (Chrome, Edge, Firefox, Opera), on different hosts (desktop, mobile), and over diverse networks (wired broadband, cellular). It affects not only file transfers, but also various applications such as video streaming (up to 9.8% video bitrate reduction) and web browsing. Through rigorous packet trace analysis and kernel- and user-space profiling, we identify the root cause to be high receiver-side processing overhead, in particular, excessive data packets and QUIC's user-space ACKs. We make concrete recommendations for mitigating the observed performance issues.

Metadata: arXiv. Abstracts retain their original authors’ rights.

In the conversation

Original HN comments, with labels from simple text rules. A label describes the whole comment and may miss context or irony. Read the discussion to make up your own mind. About the labels

5 selected excerpts · 5 total mentions

ddritzenhoff
Neutral mention · rule
Hi, I've got one. Does your team have any concrete plans to reduce the TCP vs. QUIC diff with respect to goodput [1]? The linked paper claims seeing up to a 9.8% video bitrate reduction from HTTP/2 (TCP) to HTTP/3 (QUIC). Obviously, MoQ is based on a slightly different stack, so the results don't exactly generalize. I can imagine the problems are similar, though. (I find this stuff fascinating, as I spent the last few months investigating the AF_XDP datapath for MsQuic as part of my master's thesis. I basically came to the conclusion that GSO/GRO is a better alternative and that QUIC desperately needs more hardware offloads :p) [1]: https://arxiv.org/pdf/2310.09423
dpeckett
Neutral mention · rule
For TCP streams syscall overhead isn't a big issue really, you can easily transfer large chunks of data in each write(). If you have TCP segmentation offload available you'll have no serious issues pushing 100gbit/s. Also if you are sending static content don't forget sendfile(). UDP is a whole another kettle of fish, get's very complicated to go above 10gbit/s or so. This is a big part of why QUIC really struggles to scale well for fat pipes [1]. sendmmsg/recvmmsg + UDP GRO/GSO will probably get you to ~30gbit/s but beyond that is a real headache. The issue is that UDP is not stream focused so you're making a ton of little writes and the kernel networking stack as of…
Read the full comment
today does a pretty bad job with these workloads. FWIW even the fastest QUIC implementations cap out at <10gbit/s today [2]. Had a good fight writing a ~20gbit userspace UDP VPN recently. Ended up having to bypass the kernels networking stack using AF_XDP [3]. I'm available for hire btw, if you've got an interesting networking project feel free to reach out. 1. https://arxiv.org/abs/2310.09423 2. https://microsoft.github.io/msquic/ 3. https://github.com/apoxy-dev/icx/blob/main/tunnel/tunnel.go
troupo
Neutral mention · rule
A lot of the article is the same marketing spiel that Google has been using to promote QUIC (and then HTTP/3) At best those amazeballs advantages are applicable only at Google's scale, and have very little impact anywhere else. Worse, still, --- start quote --- We find that over fast Internet, the UDP+QUIC+HTTP/3 stack suffers a data rate reduction of up to 45.2% compared to the TCP+TLS+HTTP/2 counterpart. Moreover, the performance gap between QUIC and HTTP/2 grows as the underlying bandwidth increases. https://arxiv.org/abs/2310.09423 --- end quote --- And if you believe the discussion here https://news.ycombinator.com/item?id=25970258 it increased the load on the server unless you can "spend years optimizing it".
crashingintoyou
Neutral mention · rule
Don't have access to the published version but draft at https://arxiv.org/pdf/2310.09423 mentions ping RTT at 0.23ms. As someone frequently at 150ms+ latency for a lot of websites (and semi-frequently 300ms+ for non-geo-distributed websites), in practice with the latency QUIC is easily the best for throughput, HTTP/1.1 with a decent number of parallel connections is a not-that-distant second, and in a remote third is HTTP/2 due to head-of-line-blocking issues if/when a packet goes missing.
0xbadcafebee
Neutral mention · rule
Curl HTTP/3 performance (https://news.ycombinator.com/item?id=39163948) shows HTTP/3 is the slowest performer compared to HTTP2 and HTTP1.1 This paper from 2017 showed QUIC performance was poor: https://arxiv.org/pdf/2310.09423.pdf With no evidence to the opposite, the article's claim that QUIC is displacing TCP for speed is dubious at best.

Keep following the thread.

More in Networks

More from the same topics.