QUIC is not quick enough over fast internet

(arxiv.org)

306 points carlos-menezes | 1 comments | 19 Oct 24 21:04 UTC | HN request time: 0.391s | source

Show context

jrpelkonen ◴[19 Oct 24 22:21 UTC] No.41891238[source]▶

Curl creator/maintainer Daniel Stenberg blogged about HTTP/3 in curl a few months ago: https://daniel.haxx.se/blog/2024/06/10/http-3-in-curl-mid-20...

One of the things he highlighted was the higher CPU utilization of HTTP/3, to the point where CPU can limit throughput.

I wonder how much of this is due to the immaturity of the implementations, and how much this is inherit due to way QUIC was designed?

replies(4): >>41891693 #>>41891790 #>>41891813 #>>41891887 #

cj ◴[19 Oct 24 23:39 UTC] No.41891693[source]▶

>>41891238 #

I’ve always been under the impression that QUIC was designed for connections that aren’t guaranteed to be stable or fast. Like mobile networks.

I never got the impression that it was intended to make all connections faster.

If viewed from that perspective, the tradeoffs make sense. Although I’m no expert and encourage someone with more knowledge to correct me.

replies(3): >>41891848 #>>41891912 #>>41893147 #

1. dan-robertson ◴[20 Oct 24 00:09 UTC] No.41891848[source]▶

>>41891693 #

I think that’s a pretty good impression. Lots of features for those cases:

- better behaviour under packet loss (you don’t need to read byte n before you can see byte n+1 like in tcp)

- better behaviour under client ip changes (which happen when switching between cellular data and wifi)

- moving various tricks for getting good latency and throughput in the real world into user space (things like pacing, bbr) and not leaving enough unencrypted information in packets for middleware boxes to get too funky

↑