5 ms·

From September: QUIC is not quick enough over fast internet (acm.org) https://news.ycombinator.com/item?id=41484991 https://news.ycombinator.com/item?id=41484

by Tempest1981 2y ago

From September: QUIC is not quick enough over fast internet (acm.org) https://news.ycombinator.com/item?id=41484991 https://news.ycombinator.com/item?id=41484991 (327 comments)

lysace 2y ago
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.
- vlovich123 2y ago
  So because the Linux kernel isn’t as optimized for QUIC as it has been for TCP we shouldn’t design new protocols? Or it should be restricted to academics that had tried and failed for decades and would have had all the same problems even if they succeeded? And all of this only in a data center environment really and less about the general internet Quic was designed for? This is an interesting hot take.
  - lysace 2y ago
    I'm struggling to parse my comment in the way you seem to think it did. In what way did or would my comment restrict your ability to design new protocols? Please explain.
    - vlovich123 2y ago
      Because you imply in that comment that it should be someone other than Google developing new protocols while in another you say that the protocols are already too complex implying stasis is the preferred state. You’re also factually incorrect in a number of ways such as claiming that HTTP/2 was a Google project (it’s not and some of the poorly thought out ideas like push didn’t come from Google). The fact of the matter is that other attempts at “next gen” protocols had taken place. Google is the only one that won out. Part of it is because they were one of the few properties that controlled enough web traffic to try something. Another is that they explicitly learned from mistakes that the academics had been doing and taken market effects into account (ie not requiring SW updates of middleware boxes). I’d say all things considered Internet connectivity is better that QUIC got standardized. Papers like this simply point to current inefficiencies of today’s implementation - those can be fixed. These aren’t intractable design flaws of the protocol itself. But you seem to really hate Google as a starting point so that seems to color your opinion of anything they produce rather than engaging with the technical material in good faith.
      - lysace 2y ago
        I don't hate Google. I admire it what for what it is; an extremely efficient and inherently scalable corporate structure designed to exploit the Internet and the web in the most brutal and profitable way imaginable. It's just that their interests in certain aspects don't align with ours.
- GuB-42 2y ago
  Maybe, but QUIC is not bad as a protocol. The problem here is that OSes are not as well optimized for QUIC as they are for TCP. Just give it time, the paper even has suggestions. QUIC has some debatable properties, like mandatory encryption, or the use of UDP instead of being a protocol under IP like TCP, but there are good reasons for it, related to ossification. Yes, Google pushed for it, but I think it deserves its approval as a standard. It is not perfect but it is practical, they don't want another IPv6 situation.
- ratorx 2y ago
  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.
  - lysace 2y ago
    > 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.
    - bawolff 2y ago
      > It's Microsoft's old embrace-extend-and-extinguish scheme taken to the next level. It literally is not.
      - lysace 2y ago
        Because? Edit: I'm not the first person to make this comparison. Witness the Chrome section in this article: https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish#Google_Chrome https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
        bawolff 2y ago
        Well it may be possible to make the comparison in other things google does (they have done a lot of things) it makes no sense for quic/http3. What are they extending in this analogy? Http3 is not an extension of http. What are they extinguishing? There is no plan to get rid of http1/2, since you still need it in lots of networks that dont allow udp. Additionally, its an open standard, with an rfc, and multiple competing implementations (including firefox and i believe experimental in safari). The entire point of embrace, extend, extinguish is that the extension is not well specified making it dufficult for competitors to implement. That is simply not what is happening here.
chgs 2y ago
QUIC is all about an advertising company guarenteeing delivery of adverts to the consumer. As long as the adverts arrive quickly the rest is immaterial.

From September: QUIC is not quick enough over fast internet (acm.org) https://news.ycombinator.com/item?id=41484991 https://news.ycombinator.com/item?id=41484991 (327 comments)

lysace 2y ago

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.

vlovich123 2y ago
So because the Linux kernel isn’t as optimized for QUIC as it has been for TCP we shouldn’t design new protocols? Or it should be restricted to academics that had tried and failed for decades and would have had all the same problems even if they succeeded? And all of this only in a data center environment really and less about the general internet Quic was designed for? This is an interesting hot take.
- lysace 2y ago
  I'm struggling to parse my comment in the way you seem to think it did. In what way did or would my comment restrict your ability to design new protocols? Please explain.
  - vlovich123 2y ago
    Because you imply in that comment that it should be someone other than Google developing new protocols while in another you say that the protocols are already too complex implying stasis is the preferred state. You’re also factually incorrect in a number of ways such as claiming that HTTP/2 was a Google project (it’s not and some of the poorly thought out ideas like push didn’t come from Google). The fact of the matter is that other attempts at “next gen” protocols had taken place. Google is the only one that won out. Part of it is because they were one of the few properties that controlled enough web traffic to try something. Another is that they explicitly learned from mistakes that the academics had been doing and taken market effects into account (ie not requiring SW updates of middleware boxes). I’d say all things considered Internet connectivity is better that QUIC got standardized. Papers like this simply point to current inefficiencies of today’s implementation - those can be fixed. These aren’t intractable design flaws of the protocol itself. But you seem to really hate Google as a starting point so that seems to color your opinion of anything they produce rather than engaging with the technical material in good faith.
    - lysace 2y ago
      I don't hate Google. I admire it what for what it is; an extremely efficient and inherently scalable corporate structure designed to exploit the Internet and the web in the most brutal and profitable way imaginable. It's just that their interests in certain aspects don't align with ours.
GuB-42 2y ago
Maybe, but QUIC is not bad as a protocol. The problem here is that OSes are not as well optimized for QUIC as they are for TCP. Just give it time, the paper even has suggestions. QUIC has some debatable properties, like mandatory encryption, or the use of UDP instead of being a protocol under IP like TCP, but there are good reasons for it, related to ossification. Yes, Google pushed for it, but I think it deserves its approval as a standard. It is not perfect but it is practical, they don't want another IPv6 situation.
ratorx 2y ago
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.
- lysace 2y ago
  > 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.
  - bawolff 2y ago
    > It's Microsoft's old embrace-extend-and-extinguish scheme taken to the next level. It literally is not.
    - lysace 2y ago
      Because? Edit: I'm not the first person to make this comparison. Witness the Chrome section in this article: https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish#Google_Chrome https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
      - bawolff 2y ago
        Well it may be possible to make the comparison in other things google does (they have done a lot of things) it makes no sense for quic/http3. What are they extending in this analogy? Http3 is not an extension of http. What are they extinguishing? There is no plan to get rid of http1/2, since you still need it in lots of networks that dont allow udp. Additionally, its an open standard, with an rfc, and multiple competing implementations (including firefox and i believe experimental in safari). The entire point of embrace, extend, extinguish is that the extension is not well specified making it dufficult for competitors to implement. That is simply not what is happening here.

chgs 2y ago

QUIC is all about an advertising company guarenteeing delivery of adverts to the consumer. As long as the adverts arrive quickly the rest is immaterial.