Measuring QUIC vs TCP on mobile and desktop

Post by _wmd » Thu, Feb 01, 2018, 1:21 AM UTC

jacksmith21006 wrote: post #9

_wmd wrote: post #4

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

Post by minikites » Thu, Feb 01, 2018, 1:27 AM UTC

trevyn wrote: post #12

minikites wrote: post #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 ter…

This has nothing to do with Google's politics. TCP is broken for modern networks , and the faster we ditch it for a protocol capable of reliable pipes with low latency and high throughput, the better off we'll all be.

Post by trevyn » Thu, Feb 01, 2018, 1:32 AM UTC

_wmd wrote: post #10

trevyn wrote: post #7

Earlier quoted context omitted.

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

Post by trevyn » Thu, Feb 01, 2018, 1:38 AM UTC

minikites wrote: post #13

trevyn wrote: post #12

Earlier quoted context omitted.

This has nothing to do with Google's politics. TCP is broken for modern networks , and the faster we ditch it for a protocol capable of reliable pipes with low latency and high throughput, the better off we'll all be.

Not all networks are modern, what about the unreliable networks in most of the developing world?

Post by gsich » Thu, Feb 01, 2018, 1:52 AM UTC

halfteatree wrote: post #5

minikites wrote: post #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 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.