
Taking a Long Look at QUIC [pdf] - jsnell
https://conferences.sigcomm.org/imc/2017/papers/imc17-final39.pdf
======
hyperpape
_Google’s QUIC protocol, which implements TCP-like properties at the
application layer atop a UDP transport, is now used by the vast majority of
Chrome clients accessing Google properties but has no formal state machine
specification, limited analysis, and ad-hoc evaluations based on snapshots of
the protocol implementation in a small number of environments. Further
frustrating attempts to evaluate QUIC is the fact that the protocol is under
rapid development, with extensive rewriting of the protocol occurring over the
scale of months, making individual studies of the protocol obsolete before
publication._

I had no idea QUIC was so poorly specified (at least outside of the walls of
Google).

~~~
api
Not uncommon for a new protocol. Question is whether they will get around to
it.

~~~
akshayn
I think this is unlikely. Part of the advantage of having built your own
datapath is being able to change it on a whim; I don't see Google giving this
up by agreeing to stick to some fixed specification.

~~~
euyyn
It's to be expected from any protocol for which this is true:

> the protocol is under rapid development, with extensive rewriting of the
> protocol occurring over the scale of months

Once it stabilizes, I don't see a reason why it couldn't go the same route
SPDY -> HTTP/2 did. A faster internet is a win for Google.

(I work at Google, but I'm not aware of the QUIC team's plans).

------
j_s
From the conclusion: _cases where it performs well and poorly— both in
traditional desktop environments but also in mobile and proxy scenarios not
previously tested_

Example: _its benefits diminish or entirely disappear compared to unproxied
TCP in low loss /latency cases, and when there is 1% loss. In the case of high
delay links, QUIC still outperforms TCP [...]. Thus, proxies can help TCP to
recover many of the benefits of QUIC, but primarily in lossy scenarios, and
when the proxy is equidistant from the client and server_

------
mhandley
This paper should probably be read in conjunction with Google's QUIC paper
from Sigcomm 2017, which provides quite a bit more detail about the protocol
and its design decisions:
[https://research.google.com/pubs/archive/46403.pdf](https://research.google.com/pubs/archive/46403.pdf)

------
mda
"Figure 12: QUICv34 vs. TCP for varying object sizes on MotoG and Nexus6
smartphones (using WiFi). We find that QUIC’s improvements diminish or
disappear entirely when running on mobile devices."

Contrary to negative tonne, Figure 12 looks like it favors Quic on almost all
cases?

------
londons_explore
Perhaps that bottom right corner of figure 8 (e) is why Google Drive downloads
perform so abysmally over busy wifi...

