Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Measuring QUIC vs TCP on mobile and desktop

blog.apnic.net

Post reply on HN
Print view View original

41–47 of 47 posts

Re: Measuring QUIC vs TCP on mobile and desktop

#41

Post by solotronics »

trevyn wrote: post #15
_wmd wrote: post #10

Earlier quoted context omitted.

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

If this was actually a problem, it would be trivial for network operators to prioritize TCP packets over UDP packets. QUIC builds modern congestion control on top of UDP.

I think the problem is that currently there is no prioritizing within IP traffic and possibly this would cause TCP to suck while QUIC over UDP ran fine. This is just a guess based on how TCP congestion and sliding window work and I am very curious to see how these two interact at various percentages in the wild. If anyone knows how to simulate QUIC on Spirent or Ixia test gear please drop me a line and I will lab this up.

Re: Measuring QUIC vs TCP on mobile and desktop

#42

Post by trevyn »

fulafel wrote: post #36

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?

QUIC replaces TCP and is on IETF standards track.

HTTP/2 replaces HTTP/1.1 (and is a direct descendent of SPDY, which has origins ~2009).

HTTP/2 on TCP gets you some of the benefits that QUIC provides (multiplexing, reduced roundtrips), but HTTP/2 on QUIC is the best of both worlds.

IMO, there's not much noise about QUIC mainly because most people don't care enough about latency to care, and the current lack of production-quality QUIC server software makes caring more complicated than "just enable it", so low demand all around. This should pick up when it gets closer to a ratified standard.

Re: Measuring QUIC vs TCP on mobile and desktop

#43

Post by trevyn »

tybit wrote: post #29
trevyn wrote: post #17

Earlier quoted context omitted.

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

1) "We shared this result with a QUIC engineer, who subsequently informed us that the QUIC team is experimenting with dynamic threshold and time-based solutions to avoid falsely inferring loss in the presence of reordering."

2) "We find that, similar to the desktop environment, in mobile QUIC outperforms TCP in most cases; however, its advantages diminish across the board... The reason for this behavior is that QUIC runs in a userspace process, whereas TCP runs in the kernel." (i.e. putting it in the kernel should help.)

https://conferences.sigcomm.org/imc/2017/papers/imc17-final3...

Re: Measuring QUIC vs TCP on mobile and desktop

#44

Post by sebazzz »

trevyn wrote: post #7
_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…

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…

QUIC runs on UDP, does that mean it does not work on carrier grade NAT we see more and more these days?

Re: Measuring QUIC vs TCP on mobile and desktop

#45

Post by fulafel »

trevyn wrote: post #15
_wmd wrote: post #10

Earlier quoted context omitted.

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

If this was actually a problem, it would be trivial for network operators to prioritize TCP packets over UDP packets. QUIC builds modern congestion control on top of UDP.

We really don't want the prioritisation smarts in the network - End-to-end architecture of the internet, network neutrality and all that.

Re: Measuring QUIC vs TCP on mobile and desktop

#46

Post by wmf »

sebazzz wrote: post #44
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…

QUIC runs on UDP, does that mean it does not work on carrier grade NAT we see more and more these days?

UDP works over virtually all NATs.

Re: Measuring QUIC vs TCP on mobile and desktop

#47

Post by chemag »

apenwarr wrote: post #38

This is a pretty disappointing article. It's really comparing a particular 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. The article points out that both the QUIC and TCP implementations they tested are using CUBIC congestion control, but that's not enough information, b…

+1 to this. QUIC allows using CUBIC BBR [1], so a comparison based on the exact parameters used is actually comparing the exact parameters used.

The performance effects of QUIC implementing congestion control in userland are more interesting. OTOH, QUIC allows deploying new features to users (through cronet) in an efficient way. TCP does not.

[1] https://chromium.googlesource.com/chromium/src/net/+/master/...

> [Disclaimer: I've worked with some of the people who wrote BBR and QUIC, so I'm biased.] Ditto

Post reply on HN