Differences

This shows you the differences between two versions of the page.

--- 0x13:reports:d1t2t03-quic-tutorial [2019/04/08 22:46] – ehalep
+++ 0x13:reports:d1t2t03-quic-tutorial [2019/09/28 17:04] (current) – external edit 127.0.0.1
@@ Line 4: / Line 4: @@
 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.
+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:
 . 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.
 . Low latency secure connection establishment. QUIC mostly creates establishes connections with 0-RTT and sometimes with 1-RTT.
-. Streams and multiplexing. Lightweight abstrations within a connection to avoid head-of-line blocking.
+. Streams and multiplexing. Lightweight abstractions within a connection to avoid head-of-line blocking.
 . Better loss recovery and flexible congestion control.
 . Congestion migration
@@ Line 26: / Line 26: @@
 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.
+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.
-Site: https://www.netdevconf.org/0x13/session.html?tutorial-QUIC
+Q: Is there overhead if you use hardware?
-github: https://github.com/h2o/quicly
+A: Yes.
-Slides:
+Q: Streams are unidirectional or bidirectional?
-Videos:
+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