Measuring QUIC vs TCP on mobile and desktop
blog.apnic.net
Measuring QUIC vs TCP on mobile and desktop
1–10 of 47 posts
Re: Measuring QUIC vs TCP on mobile and desktop
#2>Google has the largest QUIC deployment, and has reported that more than 85% of requests from Chrome browsers to Google servers (about 90% of Chrome bytes received) are now using QUIC, which accounts for 7% of Internet traffic!
>Taking a closer look at the congestion window changes (Figure 6), we found that while both protocols use Cubic, QUIC increases its window more aggressively (both in terms of slope, and in terms of more frequent window size increases). As a result, QUIC is able to grab available bandwidth faster than TCP does, leaving TCP unable to acquire its fair share of the bandwidth.
First AMP and now QUIC. As I see it, Google is emerging as the biggest enemy of both the web and the underlying internet.
Re: Measuring QUIC vs TCP on mobile and desktop
#3>Google has the largest QUIC deployment, and has reported that more than 85% of requests from Chrome browsers to Google servers (about 90% of Chrome bytes received) are now using QUIC, which accounts for 7% of Internet traffic! >Taking a closer look at the congestion window changes (Figure 6), we found that while both protocols use Cubic, QUIC increases its window more aggressively (both in terms of slope, and in ter…
I'm not sure it's all that bad. AMP is awful, particularly because of the way in which Google abuses it, but QUIC is less of a problem – it's on an IETF standards track with a couple of implementations.
Re: Measuring QUIC vs TCP on mobile and desktop
#4Am I understanding things correctly? Because QUIC ramps up its bandwidth estimate more aggressively, it fundamentally 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
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
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
Re: Measuring QUIC vs TCP on mobile and desktop
#5>Google has the largest QUIC deployment, and has reported that more than 85% of requests from Chrome browsers to Google servers (about 90% of Chrome bytes received) are now using QUIC, which accounts for 7% of Internet traffic! >Taking a closer look at the congestion window changes (Figure 6), we found that while both protocols use Cubic, QUIC increases its window more aggressively (both in terms of slope, and in ter…
> First AMP and now QUIC.
Um, pretty sure QUIC was in the pipeline a few years longer than AMP. Besides, it's literally a protocol in the network stack -- would you say IPv6 is an enemy of the web and underlying internet?
Please stop the needless fear mongering.
Re: Measuring QUIC vs TCP on mobile and desktop
#6If you want to try QUIC yourself, you can use Caddy, which has experimental QUIC support (https://caddyserver.com/docs/cli#quic) powered by quic-go.
(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.)
Re: Measuring QUIC vs TCP on mobile and desktop
#7Am I understanding things correctly? Because QUIC ramps up its bandwidth estimate more aggressively, it fundamentally 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 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 i…
QUIC fundamentally competes on a different level because TCP is broken for modern networks.
From a network usage standpoint, there isn't anything "unfair" about it -- QUIC runs atop UDP, which is also a perfectly acceptable and publicly available Internet protocol. And Chrome will happily use QUIC with non-Google hosts, the real problem is that production-quality QUIC server software is currently rare outside of Google.
Re: Measuring QUIC vs TCP on mobile and desktop
#8>Google has the largest QUIC deployment, and has reported that more than 85% of requests from Chrome browsers to Google servers (about 90% of Chrome bytes received) are now using QUIC, which accounts for 7% of Internet traffic! >Taking a closer look at the congestion window changes (Figure 6), we found that while both protocols use Cubic, QUIC increases its window more aggressively (both in terms of slope, and in ter…
> First AMP and now QUIC. Um, pretty sure QUIC was in the pipeline a few years longer than AMP. Besides, it's literally a protocol in the network stack -- would you say IPv6 is an enemy of the web and underlying internet? Please stop the needless fear mongering.
I pasted that initial quote ("Google has the largest QUIC deployment...") to point out that Google has a significant advantage in owning the most popular web browser and also most of the top-tier web properties in Google search, Gmail, and YouTube. Because they control the whole chain from browser to content, they can release things that make those experiences better for Chrome users (using QUIC) at the expense of non-Chrome users (who get worse TCP performance until everyone else completely adopts QUIC). Then, toss up some banner ads for non-Chrome users who visit YouTube saying, "YouTube too slow? Switch to Chrome!"
>would you say IPv6 is an enemy of the web and underlying internet?
If IPv6 made IPv4 performance worse and was pushed by one company who controls both the browser and the most popular web content, yes, I would.
Re: Measuring QUIC vs TCP on mobile and desktop
#9Am I understanding things correctly? Because QUIC ramps up its bandwidth estimate more aggressively, it fundamentally 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 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 i…
Google makes QUIC available for others to use if desired. QUIC sits on top of UDP so any other service that uses UDP you could make a similar argument they are optimizing for their service. Which everyone should be doing. Your post sounds more like it is driven more by some issue you have with Google then QUIC.
Re: Measuring QUIC vs TCP on mobile and desktop
#10Am I understanding things correctly? Because QUIC ramps up its bandwidth estimate more aggressively, it fundamentally 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 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 i…
QUIC fundamentally competes on a different level because TCP is broken for modern networks . From a network usage standpoint, there isn't anything "unfair" about it -- QUIC runs atop UDP, which is also a perfectly acceptable and publicly available Internet protocol. And Chrome will happily use QUIC with non-Google hosts, the real problem is that production-quality QUIC server software is currently rare outside of Goo…
One of the major downsides to UDP is that it lacks any form of congestion control, so it's hard to justify QUIC's behaviour due to what it's built atop :)
Meanwhile we're not talking about a small slice of bandwidth spent on SIP video calls playing unfairly, we're talking about 70% or more of all Internet traffic suddenly stampeding over every pre-existing protocol, they're the floodgates I'm worried about