Developer’s Corner: QUIC Kista Interim Day 2

Explicit Congestion Notification

The second day of the Kista Interim Meeting began with the Explicit Congestion Control (ECN) presentation by Magnus Westerlund. The proposal to add ECN to QUIC has been around since at least January of 2017. A year and a half is a long time in the context of an IETF Working Group! In January of this year, Ingemar Johansson presented the proposal to the WG at the Melbourne Interim but it was still deemed to be lacking. This time around, the result was different. Over the last several months, Magnus and Ingemar (colleagues at Ericsson, our gracious host) prepared a comprehensive presentation along with a GitHub pull request that incorporates ECN into the QUIC protocol.

The Working Group adopted the proposal. Of course, some parts will have to be changed. This is inevitable in a large proposal such as this one. For example, there was a marked pushback against adding a second frame type to carry acknowledgements (named ACK_ECN in the proposal). It looks like the existing ACK frame will be augmented to support additional ECN information. At one point in the discussion, Brian Trammell suggested that we add SMACK (small ACK) and SHACK (short ACK) frames to the protocol. But he was only joking. I think.

QUIC @Facebook

Subodh Iyengar shared experiences implementing and deploying IETF QUIC at Facebook. It is rather impressive that Facebook is running IETF QUIC now, while the protocol is still shifting under our feet. Since HTTP/QUIC is not yet ready, the folks at Facebook use QUIC as the transport for HTTP/1.1. The setup carries 100 billion HTTP requests per day.

Facebook Load Balancer Architecture, taken from Subodh’s slides

I already knew about Facebook’s pioneering ways. During the Seattle Interim in 2017, Alan Frindell told us that Facebook has been running experiments (in production, of course) with the different HPACK successors. Having worked a bit with the Facebook code, I know that they are not afraid to use the hot-off-the-presses C++14 features.

This sort of “lessons learned” disclosure is a very valuable contribution both to the working group and to the implementers of the nascent protocol. The Working Group can see what shortcomings there are in the protocol, so that we can address them early. The implementers avoid committing the same errors, saving valuable time.

Well done, Facebook.

QUIC Load Balancers

Martin Duke presented his QUIC Load Balancers draft. The draft proposes a way for QUIC load balancers to update each other’s state to allow them operating correctly even if there are connection migrations. The load balancers would talk to each other using (naturally) QUIC-LB protocol.

Implicit Stream Open is In

In my first Kista Interim Summary post, I stated that the requirement to open streams in order is without merit. While I still oppose the implicit open, I have come to see the other side’s perspective. Yes, the implicit open carries more information with each STREAM frame, making it simpler to keep track of some things. I still oppose it, for the drawbacks are more significant.

This time around, this issue came to a head and we hummed. Outhummed I was. The consensus is to have implicit open. Well, what’s done is done and life goes on. This issue is comparatively small, and it is not like we were assigning stream IDs out of order anyway.

PNE Negotiation

Packet number encryption (PNE) negotiation, championed by Praveen Balasubramanian, was rejected by the Working Group. Praveen advocated the data center use case, where PNE is unnecessary and only adds processing overhead. The Working Group’s consensus was that PNE is an intrinsic part of QUIC v1. Not having it means a different protocol, which cannot be called QUIC v1.

The Bad

The audio. The audio was bad. The audio was bad as usual, which is also bad. I do not expect a United Nations level of audio setup, but a little extra effort would pay off a lot.

While the chairs’ microphones were good, the two omnidirectional microphones used to pick up comments from the two or so dozen of the other participants failed to serve adequately. Many people are not used to the idea of projecting their voice. Indeed: when you are speaking to people who are fifteen feet away from you, raising your voice is unnecessary. The end result is that I at times had trouble following the discussion.

Next Interim: NYC!

The current plan is to hold the next Interim Meeting in New York City. How convenient: the QUIC brain trust just a train ride away from my house!

“Live from New York, it is the IETF QUIC!”