Measuring QUIC vs TCP on mobile and desktop • Hacker News Board

Re: Measuring QUIC vs TCP on mobile and desktop

#21

Post by halfteatree » Thu, Feb 01, 2018, 1:59 AM UTC

gsich wrote: post #19

halfteatree wrote: post #5

Earlier quoted context omitted.

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

Do you even know the OSI-model? Yes QUIC is a protocol, but not on the same layer as IPv6. So the comparison is useless.

It is one layer above IPv6, but what difference does that make? It's an improvement over an existing protocol to solve real problems.

I don't think anyone can really know the OSI model. I know I frequently use HTTP as a Transport Layer protocol myself, so you got me there. ¯\_(ツ)_/¯

Re: Measuring QUIC vs TCP on mobile and desktop

#22

Post by newman314 » Thu, Feb 01, 2018, 2:10 AM UTC

I'm still waiting for QUIC support for nginx.

Re: Measuring QUIC vs TCP on mobile and desktop

#23

Post by jws » Thu, Feb 01, 2018, 2:13 AM UTC

_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…

I’ve often wondered how much cheating goes on in TCP and who would notice.

Many years ago my company made a VPN which tunneled through TCP† specifically designed for heavily loaded networks. I changed the Linux kernel to cap our back off time to something like 2 seconds because getting to a 2 minute back off just sucks badly when you are encapsulating a bunch of streams. Happy customers. Happy us, no more “the VPN hangs” complaints.

␄

† Yes, "don't do that", but when you have a mission critical unchangeable protocol sending enormous multi fragment UDP datagrams over a network path with a 10% packet loss rate, something has to give.

Re: Measuring QUIC vs TCP on mobile and desktop

#24

Post by IgorPartola » Thu, Feb 01, 2018, 2:18 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

Internet traffic or web traffic? Last I saw, Netflix and streaming video were the biggest slices of the pie.

Re: Measuring QUIC vs TCP on mobile and desktop

#25

Post by glandium » Thu, Feb 01, 2018, 2:26 AM UTC

pixl97 wrote: post #20

gsich wrote: post #18

Earlier quoted context omitted.

Why is TCP broken?

Use TCP on a lossy network. Keep adding more users till you are using a majority of the bandwidth. Watch the network fail in congestion collapse.

Use TCP across continents. See how long it takes for the window size to ramp up until your bandwidth is fully used.

Re: Measuring QUIC vs TCP on mobile and desktop

#26

Post by wmf » Thu, Feb 01, 2018, 2:48 AM UTC

pixl97 wrote: post #20

gsich wrote: post #18

Earlier quoted context omitted.

Why is TCP broken?

Use TCP on a lossy network. Keep adding more users till you are using a majority of the bandwidth. Watch the network fail in congestion collapse.

Does any other protocol do better? The Internet is not a truck.

Re: Measuring QUIC vs TCP on mobile and desktop

#27

Post by twouhm » Thu, Feb 01, 2018, 2:52 AM UTC

I wonder how QUIC compares to KCP[0].

[0]: https://github.com/skywind3000/kcp/blob/master/README.en.md

Re: Measuring QUIC vs TCP on mobile and desktop

#28

Post by wmf » Thu, Feb 01, 2018, 2:58 AM UTC

minikites wrote: post #8

halfteatree wrote: post #5

Earlier quoted context omitted.

> 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 no…

Everything you say is true, yet... the Google approach works and the others don't. If our choice is free and mostly-open protocols from Google or using HTTP/1.1 + TLS 1.1 + TCP w/ CUBIC + IPv4 w/ NAT forever, Google doesn't sound too bad.

This is related to the AV1 vs. MPEG discussion from the other day where people pointed out that we basically have a a choice between free codecs developed by Google/Netflix or codecs that suck you dry from legal fees.

Re: Measuring QUIC vs TCP on mobile and desktop

#29

Post by tybit » Thu, Feb 01, 2018, 3:02 AM UTC

trevyn wrote: post #17

minikites wrote: post #13

Earlier quoted context omitted.

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

QUIC still works better than TCP on these networks, but the benefits are not as dramatic.

That doesn't seem to be supported by the article?

"While it outperforms TCP in a wide range of scenarios, we found that it underperforms in the presence of packet reordering and on resource-constrained mobile devices."

Re: Measuring QUIC vs TCP on mobile and desktop

#30

Post by charleslmunger » Thu, Feb 01, 2018, 3:34 AM UTC

_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…

I'd like to know what the efficiency gap is - you can see in the graph that early on, quic is better saturating the connection, while TCP is still scaling up. The other problem is related to how TCP connections work with HTTP/1.1 or similar protocols - one TCP connection per concurrent HTTP request, where with quic any arbitrary number of requests are all part of the same quic stream. It doesn't seem unfair that adding more TCP connections doesn't make quic reduce its share of bandwidth, any more than adding 1000 concurrent http requests into the quic stream should reduce TCP's share of bandwidth.