←back to thread

QUIC is not quick enough over fast internet

(arxiv.org)
313 points carlos-menezes | 3 comments | 19 Oct 24 21:04 UTC | HN request time: 0.565s | source
Show context
ec109685 ◴[20 Oct 24 00:02 UTC] No.41891809[source]▶
Meanwhile fast.com (and presumably netflix cdn) is using http 1.1 still.
replies(1): >>41891875 #
dan-robertson ◴[20 Oct 24 00:16 UTC] No.41891875[source]▶
Why do you need multiplexing when you are only downloading one (video) stream? Are there any features of http/2 that would benefit the Netflix use case?
replies(1): >>41892018 #
1. jeltz ◴[20 Oct 24 00:51 UTC] No.41892018[source]▶
QUIC handles packet loss better. But I do not think there is any benefit from HTTP2.
replies(2): >>41894756 #>>41916272 #
2. dan-robertson ◴[20 Oct 24 11:53 UTC] No.41894756[source]▶
Yeah I was thinking the same thing – in some video contexts with some video codecs you may care more about latency and may be able to get a video codec that can cope with packet loss instead of requiring retransmission – except it seemed it wouldn’t apply too much to Netflix where the latency requirement is lower and so retransmission ought to be fine.

Maybe one advantage of HTTP/3 would be handling ip changes but I’m not sure this matters much because you can already resume downloads fine in HTTP/1.1 if the server supports range requests (which it very likely does for video)

3. yencabulator ◴[22 Oct 24 16:59 UTC] No.41916272[source]▶
Most significantly, QUIC handles packet loss in a way that is fair to all the contained streams; no head-of-line blocking.

But the parent asks

> Why do you need multiplexing when you are only downloading one (video) stream?

So that largely doesn't apply.