←back to thread

QUIC is not quick enough over fast internet

(arxiv.org)
306 points carlos-menezes | 6 comments | 19 Oct 24 21:04 UTC | HN request time: 1.264s | source | bottom
Show context
Tempest1981 ◴[19 Oct 24 21:59 UTC] No.41891085[source]▶
From September:

QUIC is not quick enough over fast internet (acm.org)

https://news.ycombinator.com/item?id=41484991 (327 comments)

replies(2): >>41891107 #>>41893876 #
lysace ◴[19 Oct 24 22:01 UTC] No.41891107[source]▶
My personal takeaway from that: Perhaps we shouldn't let Google design and more or less unilaterally dictate and enforce internet protocol usage via Chromium.

Brave/Vivaldi/Opera/etc: You should make a conscious choice.

replies(3): >>41891197 #>>41891355 #>>41891374 #
ratorx ◴[19 Oct 24 22:46 UTC] No.41891374[source]▶
Having read through that thread, most of the (top) comments are somewhat related to the lacking performance of the UDP/QUIC stack and thoughts on the meaningfulness of the speeds in the test. There is a single comment suggesting HTTP/2 was rushed (because server push was later deprecated).

QUIC is also acknowledged as being quite different from the Google version, and incorporating input from many different people.

Could you expand more on why this seems like evidence that Google unilaterally dictating bad standards? None of the changes in protocol seem objectively wrong (except possibly Server Push).

Disclaimer: Work at Google on networking, but unrelated to QUIC and other protocol level stuff.

replies(1): >>41891400 #
lysace ◴[19 Oct 24 22:51 UTC] No.41891400[source]▶
> Could you expand more on why this seems like evidence that Google unilaterally dictating bad standards?

I guess I'm just generally disgusted in the way Google is poisoning the web in the worst way possible: By pushing ever more complex standards. Imagine the complexity of the web stack in 2050 if we continue to let Google run things. It's Microsoft's old embrace-extend-and-extinguish scheme taken to the next level.

In short: it's not you, it's your manager's manager's manager's manager's strategy that is messed up.

replies(3): >>41891503 #>>41891552 #>>41894048 #
ratorx ◴[19 Oct 24 23:15 UTC] No.41891552[source]▶
This is making a pretty big assumption that the web is perfectly fine the way it is and never needs to change.

In reality, there are perfectly valid reasons that motivate QUIC and HTTP/2 and I don’t think there is a reasonable argument that they are objectively bad. Now, for your personal use case, it might not be worth it, but that’s a different argument. The standards are built for the majority.

All systems have tradeoffs. Increased complexity is undesirable, but whether it is bad or not depends on the benefits. Just blanket making a statement that increasing complexity is bad, and the runaway effects of that in 2050 would be worse does not seem particularly useful.

replies(1): >>41891586 #
lysace ◴[19 Oct 24 23:21 UTC] No.41891586[source]▶
Nothing is perfect. But gigantic big bang changes (like from HTTP 1.1 to 2.0) enforced by a browser mono culture and a dominant company with several thousands of individually well-meaning Chromium software engineers like yourself - yeah, pretty sure that's bad.
replies(1): >>41891762 #
1. jsnell ◴[19 Oct 24 23:54 UTC] No.41891762[source]▶
Except that HTTP/1.1 to HTTP/2 was not a big bang change on the ecosystem level. No server or browser was forced to implement HTTP/2 to remain interoperable[0]. I bet you can't point any of this "enforcement" you claim happened. If other browser implemented HTTP/2, it was because they thought that the benefits of H2 outweighed any downsides.

[0] There are non-browser protocols that are based on H2 only, but since your complaint was explicitly about browsers, I know that's not what you had in mind.

replies(1): >>41891785 #
2. lysace ◴[19 Oct 24 23:57 UTC] No.41891785[source]▶
You are missing the entire point: Complexity.

It's not your fault, in case you were working on this. It was likely the result a strategy thing being decided at Google/Alphabet exec level.

Several thousand very competent C++ software engineers don't come cheap.

replies(1): >>41891904 #
3. jsnell ◴[20 Oct 24 00:21 UTC] No.41891904[source]▶
I mean, the reason I was discussing those specific aspects is that you're the one brought them up. You made the claim about how HTTP/2 was a "big bang" change. You're the one who made the claim that HTTP/2 was enforced on the ecosystem by Google.

And it seems that you can't support either of those claims in any way. In fact, you're just pretending that you never made those comments at all, and have once again pivoted to a new grievance.

But the new grievance is equally nonsensical. HTTP/2 is not particularly complex, and nobody on either the server or browser side was forced to implement it. Only those who thought the minimal complexity was worth it needed to do it. Everyone else remained fully interoperable.

I'm not entirely sure where you're coming from here, to be honest. Like, is your belief that there are no possible tradeoffs here? Nothing can ever justify even such minor amounts of complexity, no matter how large the benefits are? Or do you accept that there are tradeoffs, and are "just" disagree with every developer who made a different call on this when choosing whether to support HTTP/2 in their (non-Google) browser or server?

replies(1): >>41891920 #
4. lysace ◴[20 Oct 24 00:25 UTC] No.41891920{3}[source]▶
Edit: this whole comment is incorrect. I was really thinking about HTTP 3.0, not 2.0.

HTTP/2 is not "particularly complex?" Come on! Do remember where we started.

> I'm not entirely sure where you're coming from here, to be honest. Like, is your belief that there are no possible tradeoffs here? Nothing can ever justify even such minor amounts of complexity, no matter how large the benefits are? Or do you accept that there are tradeoffs, and are "just" disagree with every developer who made a different call on this when choosing whether to support HTTP/2 in their (non-Google) browser or server?

"Such minor amounts of complexity". Ahem.

I believe there are tradeoffs. I don't believe that HTTP/2 met that tradeoff between complexity vs benefit. I do believe it benefitted Google.

replies(1): >>41892103 #
5. jsnell ◴[20 Oct 24 01:12 UTC] No.41892103{4}[source]▶
"We" started from you making outlandish claims about HTTP/2 and immediately pivoting to a new complaint when rebutted rather than admit you were wrong.

Yes, HTTP/2 is not really complex as far as these things go. You just keep making that assertion as if it was self-evident, but it isn't. Like, can you maybe just name the parts you think are unnecessary complex? And then we can discuss just how complex they really are, and what the benefits are.

(Like, sure, having header compression is more complicated than not having it. But it's also an amazingly beneficial tradeoff, so it can't be what you had in mind.)

> I believe there are tradeoffs. I don't believe that HTTP/2 met that tradeoff between complexity vs benefit.

So why did Firefox implement it? Safari? Basically all the production level web servers? Google didn't force them to do it. The developers of all of that software had agency, evaluated the tradeoffs, and decided it was worth implementing. What makes you a better judge of the tradoffs than all of these non-Google entities?

replies(1): >>41892192 #
6. lysace ◴[20 Oct 24 01:32 UTC] No.41892192{5}[source]▶
Yeah, sorry, I mixed up 2.0 (the one that still uses TCP) with 3.0. Sorry for wasting your time.