This is an old revision of the document!
Day 1 / Track 2 / Talk 3 Tutorial: QUIC Tutorial Instructors: Jana Iyengar and Ian Swett Report by: Evangelos Haleplidis
Jana from Fastly, started his QUIC tutorial by going through the history of the QUIC protocol. The QUIC protocol begun at Google around 2014 and was between google services and Chrome and mobile apps. The inital results showed improvements in application performance. Now more than 35% percent of Google's egress traffic is using QUIC. QUIC was introduced to the IETF around 2016 to modularize and standardize QUIC.
The QUIC standard is over UDP and uses TLS encryption. QUIC design goals are the following: 1. Deployability and evolvability. QUIC uses encryption to remove the issues of middleboxes. Jana recounted an issue with the flipping of a bit, QUIC was blocked by firewalls. 2. Low latency secure connection establishment. QUIC mostly creates establishes connections with 0-RTT and sometimes with 1-RTT. 3. Streams and multiplexing. Lightweight abstrations within a connection to avoid head-of-line blocking. 4. Better loss recovery and flexible congestion control. 5. Congestion migration
QUIC provides much improvement when there is not good infrastructure. Currently there is 2 years work in the IETF with a strong focus on security, privacy and to ovoid ossification.
Jana then moved to discussion about the current implementation status, with QUIC having multiple implementations efforts and each implementation has its own API to QUIC. Jana focused his presentation on the quicly implementation.
The quicly implementation is written for H20, an optimized http2 server. Question: Is encryption per packet? Answer: Yes, to not worry about HOL blocking.
Quicly uses picotls, a TLS 1.3 library written for H20, with a codec-style API to aboid bufferbloat, very useful for QUIC.
Question: Google controls both ends. Does this apply to Quicly/Fastly? Answer: IETF is useful for interoperability. It's about the clients.
Jana described the quicly API. It has a codec-style API and is bufferless. Apps define their own send/receive buffer. Quicly doesn't do packet forwarding but provides helper functions with apps implementing their own forwarding. Quicly uses streams to read and write data.
Site: https://www.netdevconf.org/0x13/session.html?tutorial-QUIC github: https://github.com/h2o/quicly
Slides: Videos: