Wednesday, August 23, 2017

Session 5 Paper 1: The QUIC Transport Protocol: Design and Internet-Scale Deployment

Presented by: Jana Iyengar

Authors: Adam Langley, Alistair Riddoch, Alyssa Wilk, Antonio Vicente, Charles Krasic, Dan Zhang, and Fan Yang, Fedor Kouranov, Ian Swett, Janardhan Iyengar, Jeff Bailey, and Jeremy Dorfman, Jim Roskind, and Joanna Kulik, Patrik Westin, Raman Tenneti, Robbie Shade, Ryan Hamilton, Victor Vasiliev, Wan-Teh Chang, and Zhongyi Shi (Googlers or ex-Googlers)

QUIC is Google’s HTTPS protocol since 2014. It is between Google services and the Chrome/mobile apps. QUIC improves application performance, reducing youtube video re-buffering by 15 - 18% and Google's search latency by 3.5 - 8%. QUIC handles 35% Google’s egress traffic, or 7% internet traffic. QUIC stopped servicing traffic during December 2015 - January 2016 due to a security bug, but the amount of traffic served increased drastically in August 2016 when mobile Youtube started to run on QUIC. Google has also founded an IEFT working group formed in Oct 2016 to modularize and standardize QUIC.


QUIC is an integrated replacement for TCP + TLS + HTTPS. A lot of cross-layer optimization strategies have been adopted to improve performance and reduce overhead, such as leveraging flow control over a new transmission abstraction (QUIC stream) to avoid Head-of-line blocking on the TCP layer. QUIC is also developed in user space for better tools and practices, for better integration with tracing and logging, and for quicker deployment and evolution.


The performance improvement of QUIC mainly comes from the tail: for good connections with low latency, the space for improvement is small. However, for poor connections with larger latency, QUIC helps. The benefits come from reduced handshake latency and faster loss recovery, which results from the cross-layer design of QUIC.


Q: QUIC completely removes TCP. Should congestion control be moved from TCP to QUIC?
A; QUIC already has the Cubic congestion control algorithm.


Q: How about fairness? What happens when a QUIC session and a TCP session coexist?
A: Fairness depends on the congestion control algorithm (e.g. CUBIC). QUIC should be TCP friendly since QUIC and TCP both use the Cubic congestion algorithm.


Q: What is the cost of infrastructure to deploy QUIC? Some TCP features are already enabled on NICs. However, QUIC may not be able to leverage these existing features in the hardware.
A; We find the performance improvement overweights.


Q: Can a QUIC session be broken up to utilize between WiFi and cellular network?

A: This would be future work.