QUIC: Next generation multiplexed transport over UDP

QUIC: Next generation multiplexed transport over UDP

See more at: https://www.nanog.org/meetings/abstract?id=2586#sthash.PMHBdN2A.dpuf

QUIC is a new transport protocol that runs on top of UDP. It is currently deployed to a significant fraction of Chrome users of Google services. It combines TCP-style congestion control, TLS-grade security, and HTTP/2 multiplexing. Our measurements on real-world traffic show that QUIC significantly decreases page load times and time between pauses in video playbacks. Google will continue scaling up the use of QUIC on the public internet over the next few months, with the goal of sending all Google traffic over QUIC. This talk will discuss how QUIC works, why it's an improvement over TCP, the problems we're anticipating as we deploy at scale, and what we're doing to prevent them. - See more at: https://www.nanog.org/meetings/abstract?id=2586#sthash.PMHBdN2A.dpuf  

New Google proto to replace TCP for Web access. Incorporates TCP Cubic, adds signaling improvements such as retransmissions have new sequence number. Improved congestion control.

Lots of things people want to add to TCP, but it's hard to do. Selective ack, SACK, took 20 years to get to 90 percent deployment in TCP.

QUIC uses port 443. QUIC combines handshake for connection with security and you can send request with first transaction in the first round trip. Lots faster than TCP. QUIC very comparable to TLS, always encrypted. zero RTT handshake. Plans to adopt TLS 1.3 when complete. Signed proof of address.

peering.google.com has QUIC info: https://peering.google.com/about/quicfaq.html

Zero RTT is the biggest single feature - over 50 percent better perf. Better loss recovery as well. 10x fewer timeout based retransmissions vs TCP.

2014: chrome stable, rollout started Jan 2015.
On client side, if UDP is blocked then fall back to HTTP/TCP.
If path MTU too small (QUIC uses 1350B packet) then falls bacl to TCP
There is a Chrome flag to disable

Google can disable QUIC on a per-ASN basis if needed. Don't want to do it, but sometimes have to because of degraded quality of experience reports in Youtibe (most common indicator).

Need to sign up for access to per-ASN QUIC info: https://peering.google.com/portalaccess/

There is a wireshark plugin for QUIC.
Chrome will display QUIC stats with: chrome://net-internals/#quic

Future: Forward error correction. - Experimenting with it, but hard.
Connection mobility - starting to work on that and multipath
Looking at improvements in congestion control. Kept TCP congestion control the same in QUIC for the moment.
Working to support in Apache Traffic Server
Google Chrome and some Google Android Apps are current main users of QUIC

QUIC was presented to IETF in 2013
Mar 2015: QUIC crypto was presented and has informed TLS 1.3 development and will subsume QUIC crypto as a profile in TLS 1.3
Working to move QUIC zero RTT handshale into TLS1.3 so can adopt TLS 1.3 into QUIC
QUIC is open source- all in Chromium source. No separate library so it's all in Chrome at this point.
QUIC designed to improve user experience, lower latency, faster response.

Q: constant encryption is a cost in CPU why choose to do so? A: have reduced CPU load and we (google) choose to encrypt everything.

Note: QUIC will fail at sites with firewalls blocking UDP. So the firewalled world is exacting yet another cost in latency and quality of experience (not that they care)