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
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
- HN score
- 0
- Mentions
- 5
- Readers
- 5
- Months
- 4
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
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
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".
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.
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 NetworksMore from the same topics.
NP-complete Problems and Physical Reality
Scott Aaronson
Can NP-complete problems be solved efficiently in the physical universe?
Therapeutic benefit of combining calorie-restricted ketogenic diet and glutamine targeting in late-stage experimental glioblastoma
Purna Mukherjee, Zachary M. Augur, Mingyi Li +10
AbstractGlioblastoma (GBM) is an aggressive primary human brain tumour that has resisted effective therapy for decades.
SARS-CoV-2 infection induces long-lived bone marrow plasma cells in humans
Jackson S. Turner, Wooseob Kim, Elizaveta Kalaidina +10
The Surprising Creativity of Digital Evolution: A Collection of Anecdotes from the Evolutionary Computation and Artificial Life Research Communities
Joel Lehman, Jeff Clune, Dusan Misevic +50
Biological evolution provides a creative fount of complex and subtle adaptations, often surprising the scientists who discover them.