Notes from the Road: QUIC Interim London

“PLEASE TAKE NO ACTION!”
– PSA on Cloudflare’s intercom during a fire drill, 5/23/2019, London QUIC Interim Meeting

The QUIC Working Group met for its regular Interim Meeting last week. This time, it was hosted by Cloudflare at its headquarters in London. Once more, the author attended the meeting remotely.

Interop Results

As usual, a two-day interoperability hackathon preceded the interim meeting proper. The Interop was held Monday and Tuesday. The number of QUIC implementations has grown to about two dozen. There are now QUIC implementations in C, C++, Erlang, Go, Java, Objective-C, Python, Rust, and TypeScript. Most of them already implement the month-old (that’s old!) Internet-Draft 20 QUIC transport and about half of them do HTTP/3.

Our own implementation, lsquic, successfully fetched a resource using HTTP/3 from ten servers; eight HTTP/3 clients succeeded fetching a resource from our server implementation. Two implementations already support server push. This is on our to-do list.

Alan Frindell (Facebook), our old friend and editor of the QPACK draft, found a bug in our QPACK library, ls-qpack. A drawback of having an early implementation is that one becomes subject to an unusual category of bugs: specification changes. In this case, one of the default QPACK settings changed from 4096 to 0 – but the code did not. On the bright side, the bug was easy to fix.

Connection ID Grows

The Interim Meeting commenced on Wednesday with discussion of Connection ID length.

Over a year ago in Melbourne, the proposal to grow the CID from 8 bytes was first floated. Since then, the CID transformed from fixed to variable length and grew to a maximum of 18 bytes. Martin Duke (F5) has been working on QUIC Load Balancer specification and ran into a limitation: 18 bytes is just not enough for a multi-tier load balancing solution.

The proposal is to increase the maximum Connection ID size from 18 to 48 bytes. This change will have a significant effect on the wire format, as four bits no longer suffice to encode 49 (0 through 48) values.

[SIDEBAR] An acute reader has noticed that four bits are not enough to represent 19 (0 through 18) values, either. The way it currently works is that the set [0 – 15] is mapped to 0, [4 – 18].

An impact to our implementation will be unfortunate. We represent CID as a struct: four-byte integer to represent the CID length and 18-byte buffer to hold the ID. Together with padding, this structure weighs in at 24 bytes. Given that lsquic uses 8-byte CIDs, the overhead is 200%. The forecast CID growth will increase this overhead to 550%. To take this arithmetical exercise a bit further: each IETF QUIC connection averages eight source CIDs and eight destinations CIDs. This means that there will be (52-8)*16=704 bytes of overhead per connection.

HTTP Priorities

HTTP/3 has inherited HTTP/2 priority scheme – adjusted for the specifics of the QUIC transport. Exclusive dependencies are gone, and placeholders are used in place of zombie requests to keep priority trees stable.

Patrick Meenan (Cloudflare) and others have been researching how well – or, rather, how poorly – web browsers and web servers utilize HTTP/2 priorities. The answer is: overall, priorities are not leveraged effectively. In large part, this is due to problems in the HTTP/2 priority design.

Patrick Meenan, Robin Marx (Hasselt University), and Ian Swett (Google) have each made competing proposals, while many others made various suggestions to them, creating what Ian called a prioritization spectrum:

Slide from Ian’s Presentation

The Working Group agreed that further work is needed on this in order to have an effective prioritization that will actually be used. It is possible that prioritization will be done as an extension: that way, it can be changed should a better design appear. Stay tuned.

Version Aliasing

Version aliasing is an attempt to prevent version ossification. QUIC handshake packets expose QUIC version information. In order to prevent middleboxes from allowing (say) QUIC v1, but dropping other versions, it has been proposed that a server may offer the client a selection of version aliases. The server agrees to recognize these aliases for a fixed period of time as equivalent of some other version. The client, then, can use one of these aliases in a subsequent connection attempt.

While the proposal is short, the implementation of this mechanism is sure to have some underwater stones. We hummed in favor of addressing the version ossification problem in v1 and so either this proposal, its variation, or something else entirely will likely make its way into the final QUIC transport draft.

Next Steps

IETF 105 takes place in Montreal at the end of July. Before that time, there may be another virtual (that is, not face-to-face) interop event, depending on when the next version of the QUIC Internet-Drafts drops. The biggest question mark in my mind is the HTTP priorities. We want to get it right – this means doing a lot of work, and a lot of work takes time.