4 ms·

QUIC makes the web faster, particularly for slow connections QUIC is a characteristic Google standard -- dictated, poorly thought through, and destructive for

QUIC makes the web faster, particularly for slow connections QUIC is a characteristic Google standard -- dictated, poorly thought through, and destructive for the rest of the web. See e.g. https://blog.apnic.net/2018/01/29/measuring-quic-vs-tcp-mobile-desktop/ https://blog.apnic.net/2018/01/29/measuring-quic-vs-tcp-mobi... "our experiments showed that QUIC always consumes more than half of the bottleneck bandwidth, even as the number of competing TCP flows increases." QUIC improves speed for high-latency connections (at the cost of cohoused TCP flows, as above), but is worse than no change for the reality of poor connectivity on the ground, which has highly variable latency, packet loss and/or duplication, and (sometimes profoundly) asymmetric routing.

eklitzke 8y ago
Criticizing QUIC becasue of its interaction with existing TCP flows is tricky, because the most efficient protocol isn't necessarily the one that interoperates best with existing protocols. There have been a lot of iterations on TCP congestion control algorithms that improve bandwidth/latency of TCP connections under the new congestion control algorithms at the detriment of legacy TCP connections. I don't know enough about QUIC to say whether it's good or bad, but the standardization process by which SPDY evolved into HTTP/2 seemed good to me: there was a lot of external feedback that was incorporated and addressed, and the protocol evolution and standardization happened over a reasonable timeline. Do you see a problem with how QUIC is being developed by the IETF?
- Sylos 8y ago
  As the article that the guy linked to points out, this unfairness is due an aggressive configuration of the CUBIC congestion control algorithm in QUIC. TCP also uses CUBIC. So, you would have just as well already been able to be a dick by configuring your CUBIC in TCP to be more aggressive. Lots of research has gone into an optimal configuration of CUBIC for TCP, under the presumption that everyone will use this implementation, and therefore with the goal of optimal results for everyone. QUIC now falls out of line because early adopters get better results, as they can unfairly compete against the fair TCP implementation. In the long term however, if QUIC is adopted by everyone, this will lead to a worse result for everyone, because this optimal configuration that's been researched under TCP has been thrown out for no good reason. At least I'm not aware of a good reason. Maybe QUIC is actually somewhat less impacted by packets being dropped or something like that and does work better with everyone just trying to squeeze everything through aggressively, but even if that is the case, I cannot imagine it being the case to the degree that this CUBIC configuration has been made more aggressive.
  - detaro 8y ago
    To be fair, that's from my understanding "aggressive configuration of CUBIC in Chrome", not something dictated by the protocol. It's an interesting point though that move to UDP and doing congestion-control in higher levels, in user-space, makes it easier for applications to be overly aggressive, and there's some incentive for them to do so. Clear downside of how frozen the lower levels of the stack have become in some ways...

eklitzke 8y ago

Criticizing QUIC becasue of its interaction with existing TCP flows is tricky, because the most efficient protocol isn't necessarily the one that interoperates best with existing protocols. There have been a lot of iterations on TCP congestion control algorithms that improve bandwidth/latency of TCP connections under the new congestion control algorithms at the detriment of legacy TCP connections. I don't know enough about QUIC to say whether it's good or bad, but the standardization process by which SPDY evolved into HTTP/2 seemed good to me: there was a lot of external feedback that was incorporated and addressed, and the protocol evolution and standardization happened over a reasonable timeline. Do you see a problem with how QUIC is being developed by the IETF?

Sylos 8y ago
As the article that the guy linked to points out, this unfairness is due an aggressive configuration of the CUBIC congestion control algorithm in QUIC. TCP also uses CUBIC. So, you would have just as well already been able to be a dick by configuring your CUBIC in TCP to be more aggressive. Lots of research has gone into an optimal configuration of CUBIC for TCP, under the presumption that everyone will use this implementation, and therefore with the goal of optimal results for everyone. QUIC now falls out of line because early adopters get better results, as they can unfairly compete against the fair TCP implementation. In the long term however, if QUIC is adopted by everyone, this will lead to a worse result for everyone, because this optimal configuration that's been researched under TCP has been thrown out for no good reason. At least I'm not aware of a good reason. Maybe QUIC is actually somewhat less impacted by packets being dropped or something like that and does work better with everyone just trying to squeeze everything through aggressively, but even if that is the case, I cannot imagine it being the case to the degree that this CUBIC configuration has been made more aggressive.
- detaro 8y ago
  To be fair, that's from my understanding "aggressive configuration of CUBIC in Chrome", not something dictated by the protocol. It's an interesting point though that move to UDP and doing congestion-control in higher levels, in user-space, makes it easier for applications to be overly aggressive, and there's some incentive for them to do so. Clear downside of how frozen the lower levels of the stack have become in some ways...