0x13:reports:d1t2t03-quic-tutorial
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
0x13:reports:d1t2t03-quic-tutorial [2019/04/08 22:11] – 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 | 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 | + | 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 |
- | The QUIC standard is over UDP and uses TLS encryption. | + | The QUIC standard is over UDP and uses TLS encryption. |
+ | 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. | ||
- | Site: https://www.netdevconf.org/ | + | 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. |
- | Slides: | + | |
- | Videos: | + | |
+ | 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, | ||
+ | Question: Google controls both ends. Does this apply to Quicly/ | ||
+ | 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/ | ||
+ | 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? | ||
+ | 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, | ||
+ | |||
+ | Site: https:// | ||
+ | github: https:// | ||
0x13/reports/d1t2t03-quic-tutorial.1554761479.txt.gz · Last modified: 2019/09/28 17:04 (external edit)