Notes From the Road: IETF 103 Short Takes

Notes from the Road: IETF 103 Litespeed and Facebook Complete First HTTP/3 Inter-Operability Test

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.

IETF 103: The Number Three

The new HTTP/3 logo from Mike Bishop’s HTTP/QUIC presentation. Just kidding, this won’t be the logo! …I think.


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.

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:

IETF 103 Handshake Retry

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

IETF 103: Spin Bit

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!

Related Posts