Notes From the Road: IETF 103 Short Takes
Last week, IETF 103 was held in Bangkok. Those lucky enough to attend in person had fun eating durians, attending the Diwali celebration at a famous local temple, or getting patted down by a few sullen Thai law enforcement officers. Since I was attending remotely, I had to content myself with eating tomato soup with sardines at 3 o’clock in the morning… and not getting harassed by the Thai police.
The new HTTP/3 logo from Mike Bishop’s HTTP/QUIC presentation. Just kidding, this won’t be the logo! …I think.
HTTP/3
The unwieldy “HTTP over QUIC” (or HQ for short) is now known as HTTP/3 (or H3). This big change was sudden to many and set the Internet abuzz. Undoubtedly, this step will be considered controversial. And yet, the name change was approved by both QUIC and HTTPbis Working Groups. (See relevant minutes: 1, 2.) Concurrently, it was decided that the HTTPbis WG will take on maintenance of HTTP/3 and QPACK documents after they are published as RFCs.
LiteSpeed first with functional HTTP/3 server
During the QUIC Interop Hackathon that accompanied IETF 103, LiteSpeed Technologies became the first entity to operate a functional HTTP/3 server. On the night of November 6th, a Facebook HTTP/3 client made several successful GET and POST requests to the LiteSpeed HTTP/3 server. After some fixes to the Facebook server, we were able to return the favor on the afternoon of November 8th when the LiteSpeed client fetched resources from the Facebook server.
@litespeedtech and @facebook achieve #QUIC #HQ (or should I say #H3?) interop! Kudos to @__subodh & co!
I think we are here first! 🙂#IETF103
— Dmitri Tikhonov (@dmitri_tikhonov) November 7, 2018
Draft 17 is the last major change
Or so we’ve been told by Martin Thomson and other QUIC luminaries. Here is a (likely incomplete) list of changes which will make the new version incompatible with the previous version:
- Transport parameter values will be encoded using the QUIC variable-length integer format.
- Transport parameters will be renumbered.
- QUIC frames will be renumbered — apparently, for purely aesthetic reasons.
- First byte (a.k.a. octet zero) of both long and short headers will change.
A slide from Martin Thomson’s First Octet presentation.
Farewell to Q043 and earlier
The octet zero change means that servers will not be able to support older versions of Google QUIC — Q043 and earlier — and IETF QUIC at the same time. Ian Swett informed us that Google plans to deploy IETF QUIC Draft-17 at scale at which point they, too, will have to drop support for pre-Q044 QUIC.
The spin bit is in
A diagram from Marcus Ihlar’s Spin Bit presentation
The QUIC Working Group voted to include the spin bit into the specification. Having been the subject of a rather contentious debate at IETF 101 in London, the spin bit is an optional protocol feature.
Chrome’s and Firefox’s stated intent of not implementing the spin bit makes its value questionable. On the other hand, Microsoft, LiteSpeed Technologies, and F5 pledged to support it in both their server and client products and Apple plans to implement it on the client.
Is there life after QUIC?
At the end of the second (and last) QUIC session, we discussed the road ahead. The plan it to freeze the 17th version of the draft family and get many implementations going. The finish line has been moved again, this time to July 2019.
Shall we disband after QUIC is released? There has been talk of rechartering the Working Group to take on new challenges, such as multipath and partial reliability.
Given the rate of protocol changes that are still being worked on, that point still seems pretty far off to me. Now, it’s time to roll up the sleeves and finish our server implementation. Until next time!
Comments