HackerPapers

arXiv:2310.09423cs.NI

QUIC is not Quick Enough over Fast Internet

Xumiao Zhang, Shuowei Jin, Yi He, Ahmad Hassan, Z. Morley Mao, Feng Qian, Zhi-Li Zhang

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.

arXiv comments
10 pages, 16 figures
Journal reference
Proceedings of the ACM Web Conference 2024 (WWW '24), Pages 2713-2722
DOI
doi:10.1145/3589334.3645323
Subjects
cs.NINetworking and Internet Architecture

On Hacker News

Linked by 9 identifiable commenters in 9 comments across 6 threads, from Feb 2024 to Oct 2025. Found in 1 HN submission from Oct 2024 to Oct 2024. Open submission discussions.

Comments linking this paper, per year.

Discussed in comments6 threads

  1. HTTP3 Explained 1 comment
    • 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…

      ddritzenhoffView on HNParent context

    • 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…

      dpeckettView on HNParent context

    • 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…

      troupoView on HNParent context

    • Seems to be available on arXiv: https://arxiv.org/pdf/2310.09423

      JoshTriplettView on HNParent context

    • It's available on arxiv and nope, they are testing mostly for regular 4G/5G speeds. https://arxiv.org/pdf/2310.09423

      dartharvaView on HNParent context

    • Free PDF file of the research: https://arxiv.org/pdf/2310.09423

      AlphaCharlieView on HNParent context

    • 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…

      crashingintoyouView on HNParent context

    • 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…

      0xbadcafebeeView on HNParent context

Submitted to Hacker News

Connected through shared HN threads, not inferred similarity or a recommendation.