
Measuring QUIC vs TCP on mobile and desktop - josephscott
https://blog.apnic.net/2018/01/29/measuring-quic-vs-tcp-mobile-desktop/
======
_wmd
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 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

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

~~~
_wmd
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

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

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

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

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.

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.

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 _separately_ 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!

[1]
[https://queue.acm.org/detail.cfm?id=3022184](https://queue.acm.org/detail.cfm?id=3022184)

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

~~~
chemag
+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/...](https://chromium.googlesource.com/chromium/src/net/+/master/quic/core/congestion_control/bbr_sender.cc)

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

------
twouhm
I wonder how QUIC compares to KCP[0].

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

------
newman314
I'm still waiting for QUIC support for nginx.

------
mholt
If you want to try QUIC yourself, you can use Caddy, which has experimental
QUIC support
([https://caddyserver.com/docs/cli#quic](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.)

------
fulafel
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?

~~~
apenwarr
It's being actively discussed at the IETF. Here's a doc that's last updated
2018-01-28: [https://datatracker.ietf.org/doc/draft-ietf-quic-
transport/](https://datatracker.ietf.org/doc/draft-ietf-quic-transport/)

