The Challenges of 0-RTT in IETF QUIC
summary
IETF QUIC 0-RTT causes real failures and slowdowns: servers hit a 3x amplification limit, multiple packet number spaces hide which keys peers have, and PTO logic plus reordered or buffered 0-RTT packets inflate RTT estimates. Chrome often drops resumption state (Chrome not persisting tickets), certificate revalidation blocks key use, and a client-side handshake bug spins initial pings. Fixes include execute PTO before new data, retransmit across packet number spaces, and process buffered packets more aggressively; result: ~+0.3% mean and ~+0.6% 9th‑percentile win for search.
AI-written summary · about
chapters (8)
- 0:00Start
- 0:12Terminology
- 0:56A 0-RTT Handshake
- 6:22Amplification Limit
- 6:35Fix: Address Validation Token
- 8:25Key PTO Fixes
- 13:09Little Optimizations
- 13:32Lessons Learned
related talks
51mHTTP/3 and QUIC: Who, what, where, when and, WHY?
12mThe QUIC-ematic universe season 2020-2021 preview
34mSecuring the Next Version of HTTP: How QUIC and HTTP/3 Compare to HTTP/2
51mHTTP/2 & Quic - Teaching Good Protocols to Do Bad Things
44mEfficient Forward Security for TLS 1.3 0-RTT
35mLessons Learned from Testing Millions of Servers for Post-Quantum Compatibility
52mWhat's New in TLS 1.3
53mHansel and Gretel do TLS
