4 ms·

The benefits of QUIC / HTTP/3 have been extremely well defined as- -higher latency connections. -packet loss under multiplexing scenarios / suboptimal connect

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?
- llm_nerd 2y ago
  >And yet it's somehow being pushed as a be-all solve-all replacement But it isn't a be-all solve-all replacement. The whole point of HTTP/3 is that you can still use HTTP/2 all you want in your build-outs, and it uses as appropriate. If large file, many packet, high speed sustained performance is your thing and you've got problems with HTTP/3, deploy it on an HTTP/2 server. Go nuts. Positively nothing will go awry. Everything will be fine. You're arguing a strawman. >Additionally, if your performance degrades even in these ideal conditions, what does this promise for non-ideal conditions? This is an absolutely nonsensical statement. HTTP/3 is quite literally built for situations where you have many small requests, often in suboptimal situations. The average web user interacting with an average web page over something other than their local ethernet connection, exchanging tens of thousands of back and forths for different resources and navigations and posts. Screeching, with moral superiority I might add, that if it pins the CPU using their oddball no-name server -- oh, and where they bizarrely forced the HTTP/3 server to use HTTP/2 congestion control because that made the results funner -- with their client machine with a CPU 1/4 the performance of my smartphone, downloading a many GB file, isn't the big win you seem to think it is.

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?

llm_nerd 2y ago
>And yet it's somehow being pushed as a be-all solve-all replacement But it isn't a be-all solve-all replacement. The whole point of HTTP/3 is that you can still use HTTP/2 all you want in your build-outs, and it uses as appropriate. If large file, many packet, high speed sustained performance is your thing and you've got problems with HTTP/3, deploy it on an HTTP/2 server. Go nuts. Positively nothing will go awry. Everything will be fine. You're arguing a strawman. >Additionally, if your performance degrades even in these ideal conditions, what does this promise for non-ideal conditions? This is an absolutely nonsensical statement. HTTP/3 is quite literally built for situations where you have many small requests, often in suboptimal situations. The average web user interacting with an average web page over something other than their local ethernet connection, exchanging tens of thousands of back and forths for different resources and navigations and posts. Screeching, with moral superiority I might add, that if it pins the CPU using their oddball no-name server -- oh, and where they bizarrely forced the HTTP/3 server to use HTTP/2 congestion control because that made the results funner -- with their client machine with a CPU 1/4 the performance of my smartphone, downloading a many GB file, isn't the big win you seem to think it is.