Am I understanding things correctly? Because QUIC ramps up its bandwidth estimate more aggressively, it <i>fundamentally</i> competes unfairly with TCP? Is that an inherent property or something that can be fixed? Definitely it's too late to fix it on the TCP side<p>Nice to know 7% of Internet traffic isn't playing fair with the rest just so one company's content loads a few ms faster! Really don't know how I feel about TCP in general losing out to QUIC if it saw much wider deployment outside Google<p>And finally, it's incredibly disappointing to read these results from a third party, rather than having a balanced perspective as part of the original marketing
This is a pretty disappointing article. It's really comparing a <i>particular</i> implementation (or maybe multiple implementations) of TCP congestion control, implemented in kernel space, with a particular implementation of QUIC congestion control, implemented in user space.<p>The article points out that both the QUIC and TCP implementations they tested are using CUBIC congestion control, but that's not enough information, because the article also points out that QUIC is using "more aggressive parameters." It's tough to say which parameters are better, but what's unsaid is that a TCP implementation could change their parameters and get the same congestion control results as QUIC.<p>The supposed poor performance of QUIC on resource-limited mobile devices is, as they point out, because it's a user space implementation that is thus more expensive. If QUIC becomes popular, I assume there will be kernel implementations that are as resource efficient as TCP. Meanwhile, it's a lot easier to to experiments (such as tuning CUBIC parameters!) when you don't have to reboot to install a new version.<p>It's also quite common for various TCP congestion controllers to completely fail to saturate busy links, because of various limitations. If that happens, it might be that QUIC is able to fill the empty space, thereby taking "more than its fair share" only because TCP wasn't going to use that share anyway. Since the article doesn't even say which TCP implementation it's comparing against, and doesn't say what happens when the TCP sessions are competing only amongst themselves with no QUIC present, it's hard to say what's going on.<p>The funny thing about all this is that, if they use the same congestion control (which seems to be the intention given that they are both using CUBIC and Google is <i>separately</i> trying to fix congestion control via BBR[1]), they should both be about equally fair. The performance benefits of QUIC are not even congestion control related!<p>[1] <a href="https://queue.acm.org/detail.cfm?id=3022184" rel="nofollow">https://queue.acm.org/detail.cfm?id=3022184</a><p>[Disclaimer: I've worked with some of the people who wrote BBR and QUIC, so I'm biased.]
I wonder how QUIC compares to KCP[0].<p>[0]: <a href="https://github.com/skywind3000/kcp/blob/master/README.en.md" rel="nofollow">https://github.com/skywind3000/kcp/blob/master/README.en.md</a>
If you want to try QUIC yourself, you can use Caddy, which has experimental QUIC support (<a href="https://caddyserver.com/docs/cli#quic" rel="nofollow">https://caddyserver.com/docs/cli#quic</a>) powered by quic-go.<p>(However, QUIC versions are extremely transient and has very limited support in Chrome; the next release of Caddy will bring it back up-to-date again.)
What's the current positioning of QUIC by Google? It predates HTTP/2, and Google hasn't been making noises about it lately. Is it being slowly phased out or just in a "let it be" status for now in Chrome?