3 ms·

A lot of the article is the same marketing spiel that Google has been using to promote QUIC (and then HTTP/3) At best those amazeballs advantages are applicabl

by troupo 2y ago

A lot of the article is the same marketing spiel that Google has been using to promote QUIC (and then HTTP/3) At best those amazeballs advantages are applicable only at Google's scale, and have very little impact anywhere else. Worse, still, --- start quote --- 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. Moreover, the performance gap between QUIC and HTTP/2 grows as the underlying bandwidth increases. https://arxiv.org/abs/2310.09423 https://arxiv.org/abs/2310.09423 --- end quote --- And if you believe the discussion here https://news.ycombinator.com/item?id=25970258 https://news.ycombinator.com/item?id=25970258 it increased the load on the server unless you can "spend years optimizing it".

crazygringo 2y ago
Have those findings been independently confirmed? Has Google said anything? Is it dependent on certain e.g. server-side factors? Did Google "get this wrong" or was this intentional? E.g. is it by far a net positive to be faster on slow internet where the difference is perceivable, than to be slower on fast internet because it's still lightning-fast even when it's slower?
- nyrikki 2y ago
  Google's needs are not most people's needs, "wrong" for them is different than "wrong" for general users.
  - crazygringo 2y ago
    I don't know what you mean. In this particular instance, the point is to speed up page loads. In this particular case, speed increases are most people's needs.
llm_nerd 2y ago
The benefits of QUIC / HTTP/3 have been extremely well defined as- -higher latency connections. -packet loss under multiplexing scenarios / suboptimal connections (e.g. mobile). These are the situations where it shines and runs away from HTTP/2. And this has been the promised advantage from the outset, and is literally the problem it is designed to solve. Given that the linked paper mentions the word latency once in an irrelevant context, I think that's telling. Of course there is no advantage -- and in fact is an expected disadvantage -- when your client and server are 0ms from each other with 0% packet loss. Now put them 100ms from each other with 5% packet loss/reordering/retransmission and multiplexing.
- xxs 2y ago
  >with 5% packet loss This is absolutely massive
  - crazygringo 2y ago
    Clearly you have never taken the subway, or stood on a particular street corner with bad reception. Quite frequently I'd love to have just 5% packet loss.
  - llm_nerd 2y ago
    It is bad packet loss, but is the sort of situations that people often find themselves in. Congestion, bad connections (which is a lot of mobile scenarios), satellite comms, and the like and it's a reality. It's interesting how people often say HTTP/3 only benefits the megas like Google. A few years back I worked on a data centric system (fund administration) where we had a single centralized server cluster serving high value users across the globe. Because of the integration and real-time nature of the data, it wasn't possible to replicate to servers around the world, nor was local (relative to the user) caching of much value at all. QUIC (which became HTTP/3) proved a significant improvement for users of the system. Users in the UK, Singapore, Australia, Germany, California, and so on, were all using a system in Toronto basically transparently, with great usability. That it was continents away suddenly didn't matter.
  - aboardRat4 2y ago
    I live in a third world country, and here we consider 5% to be VERY good. Most if my servers have about 40-50% packet loss. 50% is just a half. So we naturally expect our 3000gbit links to turn into 1gbit links, but that's not how tcp works.
- troupo 2y ago
  > These are the situations where it shines and runs away from HTTP/2. And this has been the promised advantage from the outset, and is literally the problem it is designed to solve. And yet it's somehow being pushed as a be-all solve-all replacement despite this: --- start quote --- We experimentally demonstrate that QUIC’s performance degradation affects not only bulk file transfers but also other applications including video content delivery and web browsing, despite their intermittent traffic patterns. QUIC incurs a video bitrate reduction of up to 9.8% compared to HTTP/2 when delivering DASH (Sodagar, 2011) video chunks over high-speed Ethernet and 5G. Again, such QoE degradation only exhibits when the underlying bandwidth is sufficiently high. For example, the impact is hidden over 4G but unleashed over 5G. QUIC’s page load time (PLT) is 3.0% longer than HTTP/2’s, averaged across 100 representative websites, with a long tail of page load time gaps over 50%. --- end quote --- Latency is all good ... until latency isn't the only thing affecting the performance > Of course there is no advantage -- and in fact is an expected disadvantage -- when your client and server are 0ms from each other with 0% packet loss. Now put them 100ms from each other with 5% packet loss/reordering/retransmission and multiplexing. Indeed, why not claim something that article never claimed and then claim moral superiority for yourself. Nowhere in the article do authors claim to have servers 0ms from each other with 0 packet loss. Additionally, if your performance degrades even in these ideal conditions, what does this promise for non-ideal conditions?

by troupo 2y ago

crazygringo 2y ago

Have those findings been independently confirmed? Has Google said anything? Is it dependent on certain e.g. server-side factors? Did Google "get this wrong" or was this intentional? E.g. is it by far a net positive to be faster on slow internet where the difference is perceivable, than to be slower on fast internet because it's still lightning-fast even when it's slower?

nyrikki 2y ago
Google's needs are not most people's needs, "wrong" for them is different than "wrong" for general users.
- crazygringo 2y ago
  I don't know what you mean. In this particular instance, the point is to speed up page loads. In this particular case, speed increases are most people's needs.

llm_nerd 2y ago

The benefits of QUIC / HTTP/3 have been extremely well defined as- -higher latency connections. -packet loss under multiplexing scenarios / suboptimal connections (e.g. mobile). These are the situations where it shines and runs away from HTTP/2. And this has been the promised advantage from the outset, and is literally the problem it is designed to solve. Given that the linked paper mentions the word latency once in an irrelevant context, I think that's telling. Of course there is no advantage -- and in fact is an expected disadvantage -- when your client and server are 0ms from each other with 0% packet loss. Now put them 100ms from each other with 5% packet loss/reordering/retransmission and multiplexing.

xxs 2y ago
>with 5% packet loss This is absolutely massive
- crazygringo 2y ago
  Clearly you have never taken the subway, or stood on a particular street corner with bad reception. Quite frequently I'd love to have just 5% packet loss.
- llm_nerd 2y ago
  It is bad packet loss, but is the sort of situations that people often find themselves in. Congestion, bad connections (which is a lot of mobile scenarios), satellite comms, and the like and it's a reality. It's interesting how people often say HTTP/3 only benefits the megas like Google. A few years back I worked on a data centric system (fund administration) where we had a single centralized server cluster serving high value users across the globe. Because of the integration and real-time nature of the data, it wasn't possible to replicate to servers around the world, nor was local (relative to the user) caching of much value at all. QUIC (which became HTTP/3) proved a significant improvement for users of the system. Users in the UK, Singapore, Australia, Germany, California, and so on, were all using a system in Toronto basically transparently, with great usability. That it was continents away suddenly didn't matter.
- aboardRat4 2y ago
  I live in a third world country, and here we consider 5% to be VERY good. Most if my servers have about 40-50% packet loss. 50% is just a half. So we naturally expect our 3000gbit links to turn into 1gbit links, but that's not how tcp works.
troupo 2y ago
> These are the situations where it shines and runs away from HTTP/2. And this has been the promised advantage from the outset, and is literally the problem it is designed to solve. And yet it's somehow being pushed as a be-all solve-all replacement despite this: --- start quote --- We experimentally demonstrate that QUIC’s performance degradation affects not only bulk file transfers but also other applications including video content delivery and web browsing, despite their intermittent traffic patterns. QUIC incurs a video bitrate reduction of up to 9.8% compared to HTTP/2 when delivering DASH (Sodagar, 2011) video chunks over high-speed Ethernet and 5G. Again, such QoE degradation only exhibits when the underlying bandwidth is sufficiently high. For example, the impact is hidden over 4G but unleashed over 5G. QUIC’s page load time (PLT) is 3.0% longer than HTTP/2’s, averaged across 100 representative websites, with a long tail of page load time gaps over 50%. --- end quote --- Latency is all good ... until latency isn't the only thing affecting the performance > Of course there is no advantage -- and in fact is an expected disadvantage -- when your client and server are 0ms from each other with 0% packet loss. Now put them 100ms from each other with 5% packet loss/reordering/retransmission and multiplexing. Indeed, why not claim something that article never claimed and then claim moral superiority for yourself. Nowhere in the article do authors claim to have servers 0ms from each other with 0 packet loss. Additionally, if your performance degrades even in these ideal conditions, what does this promise for non-ideal conditions?