5 ms·

Taking a Long Look at QUIC [pdf]

51 points by jsnell 9y ago

j_s 9y ago
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
hyperpape 9y ago
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 9y ago
  Not uncommon for a new protocol. Question is whether they will get around to it.
  - akshayn 9y ago
    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 9y ago
      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).
    - JulienSchmidt 9y ago
      After Google presented the protocol to the IETF several months ago, a working group was formed: https://datatracker.ietf.org/wg/quic/about/ https://datatracker.ietf.org/wg/quic/about/ / https://quicwg.github.io/ 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.
mhandley 9y ago
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 9y ago
"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 9y ago
Perhaps that bottom right corner of figure 8 (e) is why Google Drive downloads perform so abysmally over busy wifi...

51 points by jsnell 9y ago

j_s 9y ago

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

hyperpape 9y ago

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 9y ago
Not uncommon for a new protocol. Question is whether they will get around to it.
- akshayn 9y ago
  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 9y ago
    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).
  - JulienSchmidt 9y ago
    After Google presented the protocol to the IETF several months ago, a working group was formed: https://datatracker.ietf.org/wg/quic/about/ https://datatracker.ietf.org/wg/quic/about/ / https://quicwg.github.io/ 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.

mhandley 9y ago

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 9y ago

"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 9y ago

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