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).
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.
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?
I had no idea QUIC was so poorly specified (at least outside of the walls of Google).