Does Google QUIC have substantially better performance than TCP?

Question

Google QUIC is a new transport protocol. It uses UDP and provides a very nice set of features:

It doesn't need an initial handshake (0-round-trip)
It has security features by design (combination of TLS and TCP)
It brings the concept of streams, which is great for avoiding the head of the line problem and perfect for HTTP2 (https://community.akamai.com/community/web-performance/blog/2017/08/10/how-does-http2-solve-the-head-of-line-blocking-hol-issue)
The congestion control algorithm is in user space and can be replaced easily

In their SIGCOMM17 publication, they've discussed some performance benefits of QUIC, but my question is:

Do we have a real need to abandon traditional TCP-based technologies and move to QUIC? What is a killer application for QUIC? Is there anyone else apart from Google guys who uses QUIC or at least feel he or she should do that?

My feeling is that we had opportunities to achieve most of those promised benefits by using existing systems like TCP fast open or Multipath TCP.

There was [a good talk I watched about QUIC recently](https://www.youtube.com/watch?v=BazWPeUGS8M) that said (IIRC) Google found that it mostly helped to reduce tail latency, and had a large impact mostly in areas with worse connections. — Veedrac, Mar 09 '18 at 16:36

score 3 · Accepted Answer · answered Mar 09 '18 at 18:13

QUIC is a good alternative for HTTP transport when fetching small objects and TCP's handshake overhead doesn't really pay. Additionally, it may have an advantage when TCP stumbles because of high packet loss.

TCP still pays off when transferring substantial amounts of data as it handles packet loss, congestion, ... by itself (which QUIC also does but in a less well-known/accepted way).

Time will tell if this approach catches.

Does Google QUIC have substantially better performance than TCP?

1 Answers1