←back to thread

306 points carlos-menezes | 2 comments | | HN request time: 0.001s | source
Show context
lysace ◴[] No.41890996[source]
> 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.

Haven't read the whole paper yet, but below 600 Mbit/s is implied as being "Slow Internet" in the intro.

replies(9): >>41891071 #>>41891077 #>>41891146 #>>41891362 #>>41891480 #>>41891497 #>>41891574 #>>41891685 #>>41891800 #
dathinab ◴[] No.41891362[source]
They also mainly identified a throughput reduction due to latency issues caused by ineffective/too many syscalls in how browsers implement it.

But such a latency issue isn't majorly increasing battery usage (compared to a CPU usage issue which would make CPUs boost). Nor is it an issue for server-to-server communication.

It basically "only" slows down high bandwidth transmissions on end user devices with (for 2024 standards) very high speed connection (if you take effective speeds from device to server, not speeds you where advertised to have bough and at best can get when the server owner has a direct pairing agreement with you network provider and a server in your region.....).

Doesn't mean the paper is worthless, browser should improve their impl. and it highlights it.

But the title of the paper is basically 100% click bait.

replies(1): >>41891784 #
1. ec109685 ◴[] No.41891784[source]
How is it clickbait? The title implies that QUIC isn't as fast as other protocols over fast internet connections.
replies(1): >>41891850 #
2. dathinab ◴[] No.41891850[source]
Because it's QUIC _implementations of browser_ not being as fast as the non quick impl of browsers on connections most people would not just call fast but very fast (in context of browser usage) while still being definitely 100% fast enough for all browser use case done today (sure it theoretically might reduce video bit rate, that is, if it isn't already capped to a anyway smaller rate, which AFIK it basically always is).

So "Not Quick Enough" is plain out wrong, it is fast enough.

The definition of "Fast Internet" misleading.

And even "QUIC" is misleading as it normally refers to the protocol while the benchmarked protocol is HTTP/3 over QUIC and the issue seem to be mainly in the implementations.