Taking a Long Look at QUIC [pdf] | Hacker News Reader

Taking a Long Look at QUIC [pdf]

conferences.sigcomm.org

51 pointsjsnell9 comments

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

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

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.

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

After Google presented the protocol to the IETF several months ago, a working group was formed: https://datatracker.ietf.org/wg/quic/about/ / https://quicwg.github.io/ There will soon be a standardized version of QUIC with a fixed specification, probably by the end of next year.

I guess Google will still continue to experiment, but then probably based on the standardized version.

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

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

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

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

Reply on news.ycombinator.com