Notes From the Road: IETF 110

Due to the pandemic, IETF 110 was held online. It was the third IETF conference in a row to use the virtual format.

Because the QUIC and HTTP/3 specifications are well on their way to becoming standards, there has not been as much working group activity around these drafts as during previous IETF meetings. Only one QUIC Working Group session was held, and no HTTPbis WG meetings. On the other hand, the new MASQUE working group discussed ways of using QUIC for their novel proxying protocols.

What follows is my take on the discussions that took place during the sessions I attended. It is not an exhaustive list.

QUIC

The QUIC WG meeting — just one in this IETF — was held on Wednesday, March 11. (See minutes).

Working Group Updates

Lars Eggert (NetApp), the outgoing Working Group chair, updated the Working Group on the status of the Internet Drafts. The QUIC transport, TLS, recovery, and invariants drafts are expected to become RFCs in a matter of weeks. The HTTP/3 and QPACK drafts, on the other hand, have to wait a while longer, as they have some dependencies on the HTTPbis Working Group.

As usual, the IETF was preceded by the Hackathon:

Only two or three implementations participated in the interop effort this time around. There are two likely causes:

1. There were no substantial changes to the transport and HTTP/3 protocols since the last interop event. Thus, there was no impetus for many people to test their stacks again.
2. Marten Seemann’s Interop Runner has gained a lot of traction in the past few months. Some people do not bother with the manual interop anymore.

Christian Huitema highlighted the performance testing part of the Hackathon, in which Nick Banks (Microsoft) and his team ran upload and download speed tests of the few participating implementations. (Each had to implement a protocol designed by Nick specifically for the purpose.)

Part of performance test results

Christian noted that there has been significant improvement since last year in UDP performance in both Windows and Linux operating systems. This is an encouraging sign for QUIC, as QUIC performance has long been a sore spot for the implementers (LiteSpeed included). This also means that QUIC is being taken seriously.

Ops Drafts

Brian Trammell (Google) discussed the status of the Operations Drafts. These documents discuss various aspects of the way QUIC is to be used and managed on the Internet. Because QUIC uses UDP, there are expected to be some growing pains.
For example, RFC 4787 recommends the UDP NAT rebinding timeout to be at least 2 minutes, but that is not followed universally. In the wild, a UDP connection can expect to be subject to NAT rebinding after just 30 seconds of inactivity.

In general, the working group consensus is that the Ops Drafts could still use some cooking.

DATAGRAM Extension

The DATAGRAM extension is used to carry data that does not have to be retransmitted. This unreliable channel is used by the HTTP/3 DATAGRAM frames (see discussion in MASQUE). Tommy Pauly (Apple) led the discussion (see slides). (Both QUIC, the transport protocol, and HTTP/3, the application protocol, have DATAGRAM frames. They are not the same; the former is used to carry the latter, but a different application protocol could use the transport DATAGRAM frames, too.)

The zombie issue of the flow ID absence (or presence) in the DATAGRAM frame refuses to die. It was discussed, at some length, again, after it was discussed a few meetings ago and following a day after similar discussion (with the same cast of characters) of the HTTP/3 DATAGRAM frame. In the end, it was decided to keep the flow ID out of the QUIC DATAGRAM.

Several other issues were attended to during the discussion. This extension is on schedule to be finalized this July.

Version Negotiation Extension

The story of version negotiation in QUIC is covered well in the first slide of David Schinazi’s (Google) presentation. Version negotiation was removed two years ago from the Transport Draft because the Working Group could not agree on the design and wanted to make the 2019 deadline (haha!). Instead, as it usually happens, the WG empaneled a design team of David and EKR (Eric Rescorla) to propose something that works.

Their proposal is intricate and somewhat complicated. Participant after participant took turns to state as much. In the end, Matt Joras (Facebook), one of the co-chairs, closed the discussion with the mandate to the design team — and the working group — to propose simpler designs. (Watson Ladd submitted one idea hours later to the mailing list.)

Load Balancing Extension

While everyone agrees that being able to load-balance QUIC servers is a great idea, almost no one has actually done the work. Martin Duke (F5), the co-author and now-long-time champion of the load balancing extension, has been begging, cajoling, imploring, and nudging the Working Group participants to please implement something so that the extension gains some practical experience. “Without implementations,” said Martin, “this draft is at a standstill as there is no way to make progress.”

Ben Schwartz (Google) took issue with the plaintext version of the load balancer protocol: “Doesn’t it break the QUIC security promises?” Martin countered that he sees the plaintext protocol as just one end of the security spectrum continuum. A couple more people voiced their concern regarding the security implications. It is likely that this part of the load balancing specification would have to come out.

Plenary

The Plenary is an IETF-wide meeting in which most of the business of IETF the group is discussed. The assorted committees, bodies, and boards brief IETF as their members rotate in and out, gratitude is expressed, sponsors are acknowledged, and future work is discussed.

The highlight of this meeting for me was Magnus Westerlund’s (Ericsson) address “Evolving and Applying QUIC.” The purpose of the address was to make the whole IETF community aware that QUIC has arrived and it is now time to begin thinking about how to use it. Magnus sounded optimistic as he noted how many companies, large and small, use QUIC already.

Another exciting part was an address by Vint Cerf, who encouraged the IETF to continue to do good work.

MASQUE

The MASQUE Working Group meeting was held on Tuesday, March 9 (see minutes). This is a relatively new working group at the IETF dedicated to “secure proxy protocols and mechanisms based on QUIC.” The meeting was chaired by Eric Kinnear (Apple) and Chris Wood.

HTTP/3 DATAGRAM Extension

During the first hour, Lucas Pardue (Cloudflare) and David Schinazi (Google) presented their Using QUIC Datagrams with HTTP/3 Internet Draft (also see slides). The proposed HTTP/3 datagram frames are meant to be carried inside the QUIC datagram frames (which themselves are an extension to the QUIC protocol). Their payload would be UDP or IP packets in some form to facilitate proxying connections of appropriate types.

The discussion covered mainly these three design topics:

1. Premise: all flows have an identifier
2. Premise: use a new HTTP/3 setting to negotiate the use of flows IDs
3. Decision: associate flows with streams

Flow IDs are meant to demultiplex datagrams from different application components. Whose job is it to do the demultiplexing: the application protocol or the application? Some noted that the flow ID was removed from the transport protocol extension, where it originally lived. The eventual agreement was to let the flow IDs stay.

One proposal would negotiate the use of flow IDs using the H3_DATAGRAM setting. This was quickly shut down as making this more complicated than necessary. Another concern with having this HTTP/3 setting in the first place is that it serves as an advertisement: “Hey, I am a proxy!” This would make such a proxy easy to identify and censor.

Associating flows with streams would make it unnecessary to maintain a separate flow ID namespace. The cons and pros were discussed. In the end, flexibility won out and it was decided (via a MeetEcho poll) to keep flow IDs separate from streams.

Proxying

The reason for the MASQUE WG, at least at this stage, is the proxying applications made possible by the QUIC and HTTP/3 protocols. David Schinazi and Dallas McCall presented their Connect UDP and IP Proxying proposals. The former is akin to the HTTP CONNECT, but using UDP instead of TCP. The latter is a protocol to ferry IP packets over HTTP/3. Both are in the early stages of development.

Some interesting discussion was had regarding the potential benefit (and feasibility) of hiding the Connect UDP functionality from a casual Internet scan. In other words, an HTTP/3 server may be offering a way to proxy UDP connections for clients “in the know.”

The aspect of the IP Proxying proposal that garnered most attention was whether it is better to carry IP packets with the header or just the payload. This discussion will continue on the mailing list.

Conclusion

It’s been some time coming, but the QUIC and HTTP/3 standards — barring some extraordinary turn of events — are going to become RFCs this year!

At LiteSpeed Technologies, we have been honored to have participated in this process, making the Internet better for everybody. We shipped our pioneering implementation to customers; we championed the use of Google QUIC and, later, HTTP/3; and we contributed to the specifications themselves: main transport, HTTP/3, and QPACK header compression as well as several extensions.

We will continue to improve our HTTP/3 stack and pick up new extensions and features that are most useful to our customers. Thank you to those who accompanied us on our journey from a small creek to what is now a river about to enter the ocean.