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 initial 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 abstractions 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. Quicly has no intermediate buffer. The fetch is happening when there is time to send.
Q: Is there overhead if you use hardware? A: Yes.
Q: Streams are unidirectional or bidirectional? A: Quic has both
Q: Streams are negotiated? A: Quic advertises maximum number of streams and apps use streams as needed.
Q: Congestion control? A: Stream based.
Q: Optimization for CDN? A: This should be a layer above quic
Jana then moved to the issue of tracing. In regards to wireshark, it is not enough as data is encrypted. You have to record the whole data and decode before looking at wireshark. Tracing happends at endpoints. Tracing is getting traction, there are currently two tools, quic-trace and Quicvis.
quic-trace has input protobuf or json and outputs graphs. quicvis input of json.
Q: Performance? Good for short traces? A: Not know about quic-trace for large traces. Part of the evolution.
The connection ID for the QUIC header is plaintext, but can be changed within the connection, so it does not guarantee that it will be consistent for a single connection.
In regards to the acknowledge, it's about the data and not the packets. There is no packet retransmission, but data retransmission.
Site: https://www.netdevconf.info/0x13/session.html?tutorial-QUIC github: https://github.com/h2o/quicly