QUIC is not quick enough over fast internet

Original Article ↗ Hacker News Discussion ↗

Scope of the performance problem

  • Paper shows QUIC underperforms TCP/HTTP/2 at high bandwidth and very low RTT, mainly ≥500–600 Mbps and sub‑millisecond latency.
  • Several commenters note this regime isn’t typical 4G/5G, but is increasingly common for home gigabit fiber and in data centers.
  • On “normal” or slow links (mobile, high latency, lossy), many report QUIC/HTTP/3 performs as well or better.

Root causes identified

  • Consensus in the thread: the gap is largely due to TCP hardware offload and mature kernel TCP optimizations that UDP/QUIC does not yet enjoy.
  • QUIC’s ACK and state handling in userspace add scheduler and syscall overhead; UDP receive buffers are small by default and accounting is expensive.
  • Lack of QUIC‑specific NIC offload (vs widespread TCP/TLS offload) is a central bottleneck.

Userspace vs kernel networking

  • One camp argues putting QUIC in userspace was a mistake; ACKs and congestion control belong in the kernel for latency and efficiency.
  • Others argue userspace is essential: kernels evolve slowly, and QUIC’s design goal was rapid iteration and avoiding kernel crypto stacks.
  • There is work on kernel QUIC and kTLS‑style offload, but encryption‑in‑NIC raises key‑exposure and IOMMU/I/O‑isolation concerns.

When QUIC helps vs when it hurts

  • QUIC/HTTP/3 seen as clear wins on:
    • High‑latency, lossy, or mobile connections (subways, roaming, bad rural links).
    • Multipath / interface switching without breaking connections.
  • On fast, stable networks:
    • Several operators report HTTP/1.1 or HTTP/2 giving lower CPU, memory, and latency; some have disabled HTTP/2/3 entirely.
    • Others see HTTP/2 clearly beating HTTP/1.1 in such conditions; results appear implementation‑dependent.

Alternatives and design philosophy

  • Some argue SCTP already solved QUIC’s problems, but is unusable on today’s Internet due to middleboxes and lack of Windows support.
  • QUIC over UDP is seen as a pragmatic response to “only TCP/UDP pass everywhere” and to keep transport headers encrypted from meddling middleboxes.
  • There is discomfort with rising protocol complexity (HTTP/2, HTTP/3/QUIC) and calls to keep HTTP/1.1 available and favor offline‑first, simpler app designs.

System and API issues

  • Discussion of Linux networking limits: slow syscalls, small UDP buffers, imperfect UDP offload, and need for better APIs (sendmmsg/recvmmsg, io_uring) or new interfaces beyond BSD sockets.
  • Some expect this kind of research to drive UDP/QUIC stack and NIC improvements over time, narrowing the gap with TCP.