3 ms·

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

by 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.

by ivoras 8y ago

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.