7 ms·

To be clear, this became a bigger issue because HTTP/2 moved to “1 TCP connection per origin with all requests multiplexed on it”. There has always been head of

To be clear, this became a bigger issue because HTTP/2 moved to “1 TCP connection per origin with all requests multiplexed on it”. There has always been head of line blocking in tcp, however H2 compounded it since it now impacts all requests to the origin instead of just a few requests in one of four or one of six tcp connections to origin. H2 effectively moved the problem to TCP (really just made underlyubg problem more impactful). Quic is an attempt to solve the TCP problem

ivoras 8y ago
But moving the solution away from TCP into something new (in this case userland UDP-based QUIC) would make sense if (and probably only if) the overhead of QUIC connections + request bookkeeping is lower in memory and CPU usage (ideally both) than just establishing multiple TCP connections. Right?
- jayd16 8y ago
  My understanding is multiplexing over an existing connection also provides time savings as new data does not need the full handshake and ramp up a completely new connection would.
- dagenix 8y ago
  TCP flow control is generally applied per-connection. So, a web browser that creates 6 connections to load a website is going to get a greater share of available bandwidth than an application that just uses one. And what will get greater bandwidth still is if the website owner can trick the browser into opening 12 or 18 or more connections by sharding their site over multiple domains. "Just open more connections" has issues. QUIC making it less necessary to do that has value even if it didn't save memory or CPU usage.
  - ivoras 8y ago
    The need for maintaining flow control still exists, both in QUIC and TCP, it doesn't just vanish. Also, big(ish) routers are aware of TCP and can adapt as the load changes. They literally won't know what to do with a huge increase in UDP traffic. I'd make an educated guess that mass deployment of QUIC will prove to be pretty awful until it's hacked to look more or less exactly like TCP with multiple connections, just with more overhead.
    - anticensor 8y ago
      > They literally won't know what to do with a huge increase in UDP traffic. Randomly drop UDP packets.
    - dagenix 8y ago
      Afaik, the bigger the router, the more likely it is to just route ip packets. I'll make the educated guess that deployment of QUIC will be just fine as routers already know how to handle UDP and IP just fine.
josteink 8y ago
So HTTP/1.1 worked fine for around 2+ decades. Google(tm) HTTP/2.0 was unasked for, tried to reinvent TCP, found buggy and fundamentally broken after less than a year. So now Google is pushing HTTP/3 to solve the bugs they made with HTTP/2, by reinventing even more of the IP-stack. What could possibly go wrong? Can someone please tell Google that protocols are not Chrome-releases? They need to work and stay working and supported for decades. You can’t ship a new revision every 6 month. Edit: Correct HTTP/1.1 longdetivity.
- manigandham 8y ago
  3 decades? 1.1 was released in 1997. Networks change as the world evolves and supports more people and applications, so new protocols are expected. HTTP/2 was great progress at the application layer, and QUIC is now about improving the transport layer. Can you clearly list the bugs you claim HTTP/2 has?
  - josteink 8y ago
    > 3 decades? 1.1 was released in 1997. Fair enough. Corrected. > Can you clearly list the bugs you claim HTTP/2 has? They seemed fairly well outlined in the post I was replying to, no?
    - profmonocle 8y ago
      The only issue raised in the post you replied to was that TCP head-of-line blocking can be a bigger issue in HTTP/2. Claiming this makes the protocol "fundamentally broken" is a bit of a stretch. Plus, this wasn't "found after less than a year". It was a known drawback from the very beginning, when the protocol was still SPDY, and deemed an acceptable tradeoff.
    - manigandham 8y ago
      That is not a bug with HTTP/2. It is designed to be more efficient by using a single TCP connection, thereby magnifying any efficiency issues that TCP had all along. These issues are not only about HTTP but include the massively increased amount of devices, network types, security features, and general throughput over the years. Perhaps a new version of TCP could've been made, and that's a valid concern, but it's a slow moving standard that takes decades to alter. QUIC evolved faster on UDP so that's what we have. What strategy do you suggest for improving TCP faster than the current process?
deathanatos 8y ago
> There has always been head of line blocking in tcp, however H2 compounded it since it now impacts all requests to the origin instead of just a few requests in one of four or one of six tcp connections to origin. I feel like you're conflating two very different things into "head of line blockings". Head of line blocking in HTTP/1.1 was that HTTP/1.1 cannot transmit responses out of order, so a slow response "blocks" any responses behind it. HTTP/2 solves this by being multiplexed (effectively, it tags the requests & responses s.t. you can match out of order responses back to the appropriate request). This isn't necessarily that the network can't handle it; a request that might be easy for the server to handle (e.g., a static asset) can get caught behind one that is not (e.g., one that entails a slow DB query). The other "head of line blocking" that I think you're getting at is just network loss or saturation. If the network can't deliver packets, I don't see how having 6 connections is going to help: you're going to have to wait for six different state machines to determine that the link is saturated, back off, etc. Regardless, my understanding is that QUIC / HTTP/3 is still a multiplexed protocol; I would think it would behave very similarly. Nonetheless, Google's announcement of it backs up your claim[1]: > Like HTTP/2, QUIC multiplexes multiple streams into one connection, so that a connection can serve several HTTP requests simultaneously. But HTTP/2 uses TCP as its transport, so all of its streams can be blocked when a single TCP packet is lost—a problem called head-of-line blocking. QUIC is different: Loss of a UDP packet within a QUIC connection only affects the streams contained within that packet. In other words, QUIC won’t let a problem with one request slow the others down, even on an unreliable connection. But what here makes QUIC think that those other requests have any hope where the first didn't? To me, this approach seems like you're just spamming the link with packets and hoping for the best; those packets could just end up dropped like the other ones were. What makes QUIC think this approach will have any benefit? (It could, perhaps, if the link is just going to drop one packet and we can get right back to sending. I'm not sure that still conveys any benefit over TCP. Not saying QUIC is wrong, just that I don't see a decent reason to buy into it.) (This whole thing makes me think there are two problems here: there's the actual network connection between two endpoints, and what its state is, how lossy it is, its PMTU, how much data we should allow in-flight between those two endpoints, etc. But then there is also logical streams, such as HTTP request/response pairs. It almost seems like to me any data about the link, such as PMTU/lossiness/window, should be shared between all TCP connections, and the individual logical streams should be otherwise cheap/easy to make.) [1]: https://cloudplatform.googleblog.com/2018/06/Introducing-QUIC-support-for-HTTPS-load-balancing.html https://cloudplatform.googleblog.com/2018/06/Introducing-QUI...

ivoras 8y ago

But moving the solution away from TCP into something new (in this case userland UDP-based QUIC) would make sense if (and probably only if) the overhead of QUIC connections + request bookkeeping is lower in memory and CPU usage (ideally both) than just establishing multiple TCP connections. Right?

jayd16 8y ago
My understanding is multiplexing over an existing connection also provides time savings as new data does not need the full handshake and ramp up a completely new connection would.
dagenix 8y ago
TCP flow control is generally applied per-connection. So, a web browser that creates 6 connections to load a website is going to get a greater share of available bandwidth than an application that just uses one. And what will get greater bandwidth still is if the website owner can trick the browser into opening 12 or 18 or more connections by sharding their site over multiple domains. "Just open more connections" has issues. QUIC making it less necessary to do that has value even if it didn't save memory or CPU usage.
- ivoras 8y ago
  The need for maintaining flow control still exists, both in QUIC and TCP, it doesn't just vanish. Also, big(ish) routers are aware of TCP and can adapt as the load changes. They literally won't know what to do with a huge increase in UDP traffic. I'd make an educated guess that mass deployment of QUIC will prove to be pretty awful until it's hacked to look more or less exactly like TCP with multiple connections, just with more overhead.
  - anticensor 8y ago
    > They literally won't know what to do with a huge increase in UDP traffic. Randomly drop UDP packets.
  - dagenix 8y ago
    Afaik, the bigger the router, the more likely it is to just route ip packets. I'll make the educated guess that deployment of QUIC will be just fine as routers already know how to handle UDP and IP just fine.

josteink 8y ago

So HTTP/1.1 worked fine for around 2+ decades. Google(tm) HTTP/2.0 was unasked for, tried to reinvent TCP, found buggy and fundamentally broken after less than a year. So now Google is pushing HTTP/3 to solve the bugs they made with HTTP/2, by reinventing even more of the IP-stack. What could possibly go wrong? Can someone please tell Google that protocols are not Chrome-releases? They need to work and stay working and supported for decades. You can’t ship a new revision every 6 month. Edit: Correct HTTP/1.1 longdetivity.

manigandham 8y ago
3 decades? 1.1 was released in 1997. Networks change as the world evolves and supports more people and applications, so new protocols are expected. HTTP/2 was great progress at the application layer, and QUIC is now about improving the transport layer. Can you clearly list the bugs you claim HTTP/2 has?
- josteink 8y ago
  > 3 decades? 1.1 was released in 1997. Fair enough. Corrected. > Can you clearly list the bugs you claim HTTP/2 has? They seemed fairly well outlined in the post I was replying to, no?
  - profmonocle 8y ago
    The only issue raised in the post you replied to was that TCP head-of-line blocking can be a bigger issue in HTTP/2. Claiming this makes the protocol "fundamentally broken" is a bit of a stretch. Plus, this wasn't "found after less than a year". It was a known drawback from the very beginning, when the protocol was still SPDY, and deemed an acceptable tradeoff.
  - manigandham 8y ago
    That is not a bug with HTTP/2. It is designed to be more efficient by using a single TCP connection, thereby magnifying any efficiency issues that TCP had all along. These issues are not only about HTTP but include the massively increased amount of devices, network types, security features, and general throughput over the years. Perhaps a new version of TCP could've been made, and that's a valid concern, but it's a slow moving standard that takes decades to alter. QUIC evolved faster on UDP so that's what we have. What strategy do you suggest for improving TCP faster than the current process?

deathanatos 8y ago

> There has always been head of line blocking in tcp, however H2 compounded it since it now impacts all requests to the origin instead of just a few requests in one of four or one of six tcp connections to origin. I feel like you're conflating two very different things into "head of line blockings". Head of line blocking in HTTP/1.1 was that HTTP/1.1 cannot transmit responses out of order, so a slow response "blocks" any responses behind it. HTTP/2 solves this by being multiplexed (effectively, it tags the requests & responses s.t. you can match out of order responses back to the appropriate request). This isn't necessarily that the network can't handle it; a request that might be easy for the server to handle (e.g., a static asset) can get caught behind one that is not (e.g., one that entails a slow DB query). The other "head of line blocking" that I think you're getting at is just network loss or saturation. If the network can't deliver packets, I don't see how having 6 connections is going to help: you're going to have to wait for six different state machines to determine that the link is saturated, back off, etc. Regardless, my understanding is that QUIC / HTTP/3 is still a multiplexed protocol; I would think it would behave very similarly. Nonetheless, Google's announcement of it backs up your claim[1]: > Like HTTP/2, QUIC multiplexes multiple streams into one connection, so that a connection can serve several HTTP requests simultaneously. But HTTP/2 uses TCP as its transport, so all of its streams can be blocked when a single TCP packet is lost—a problem called head-of-line blocking. QUIC is different: Loss of a UDP packet within a QUIC connection only affects the streams contained within that packet. In other words, QUIC won’t let a problem with one request slow the others down, even on an unreliable connection. But what here makes QUIC think that those other requests have any hope where the first didn't? To me, this approach seems like you're just spamming the link with packets and hoping for the best; those packets could just end up dropped like the other ones were. What makes QUIC think this approach will have any benefit? (It could, perhaps, if the link is just going to drop one packet and we can get right back to sending. I'm not sure that still conveys any benefit over TCP. Not saying QUIC is wrong, just that I don't see a decent reason to buy into it.) (This whole thing makes me think there are two problems here: there's the actual network connection between two endpoints, and what its state is, how lossy it is, its PMTU, how much data we should allow in-flight between those two endpoints, etc. But then there is also logical streams, such as HTTP request/response pairs. It almost seems like to me any data about the link, such as PMTU/lossiness/window, should be shared between all TCP connections, and the individual logical streams should be otherwise cheap/easy to make.) [1]: https://cloudplatform.googleblog.com/2018/06/Introducing-QUIC-support-for-HTTPS-load-balancing.html https://cloudplatform.googleblog.com/2018/06/Introducing-QUI...