Notes From the Road: IETF 101 Part 1

I attended the IETF 101 Conference in London a couple of weeks ago. This was my first time attending this conference. What follows are some of my recollections of people, talks, and events.

Sunday 3/18/2018

My trip to the IETF 101 began with being stuck at the Frankfurt Airport due to an unseasonable snow.

My plane, just sitting there. And sitting some more.

I landed at the Heathrow Airport several hours later than planned and arrived at the venue a bit after 5 pm instead of 11 am. This resulted in me missing all the newbie-oriented meetings that I had been hoping to attend. I was able to catch most of the reception, which had free beer (plus) but little actual food (minus).

I listened to the Hot RFC lightning talks instead. There were seventeen short (hence “lightning”) talks squeezed into one and a half hours. Between QUIC over Satellite by John Border and Web Packaging by Jeffrey Yasskin, there was something for everyone.

Monday 3/19/2018

Breakfast

I met Alan Frindell (whom I befriended last year at the Seattle Interim) for breakfast at a nearby cafe. After a thought-provoking QUIC discussion, I headed off to the first session of the day. At the IETF Conference, there are six to eight sessions happening in parallel during each time slot, and so one has to choose which meeting to attend.

First Session – TCP Maint

I sat in at the TCP Maintenance and Minor Extensions Working Group (WG) meeting. There were several presentations, a couple of which stood out to me.

It turns out, RFC 793 (that’s the TCP specification itself from 1981) contains three bugs that have been known about for decades. Fernando Gont recommended that RFC 793 be updated with the fixes, while Lars Eggert, whom I heretofore have known only as the chair of the QUIC WG, proposed that an erratum be added to RFC 793 instead.

Praveen Balasubramanian, another QUIC participant, presented TCP Fast Open (TFO) deployment data as collected by Microsoft. TFO works well in some regions much better than in other regions. For example, TFO worked for only 1.5% of devices in China is compared with 21% success rate overall. See Praveen’s presentation for details.

Second Session – QUIC

The first afternoon session was QUIC. After an update from the editors, we got to the much-anticipated meat of today’s debate — the hand grenade that is QUIC over DTLS that Eric Rescorla (EKR) tossed into our midst just several days ago.

In his slides, EKR enumerated the several issues with the Stream 0 approach. The root cause of the problems, according to EKR, is that TLS depends on QUIC, which in turn depends on TLS. One way to address this is to introduce special frames for crypto streams and crypto ACKs (CREAMs and CRACKs!). A cleaner solution is to use DTLS. The downside of using QUIC/DTLS is that it would require significant changes to QUIC, and even some changes to DTLS.

The discussion was framed using the following questions:

• What is the right architecture for QUIC?
• How do we evaluate the alternatives?

The working group split into two camps: Pro-DTLS Switch, headed by EKR and his fellow Mozillians; and Anti-DTLS Switch, headed by Ian Swett (Google), who at that time joined EKR on the stage. The back-and-forth revolved around two topics: the technical advantages (or disadvantages) of switching to DTLS and the fact that this is quite late in the process to make drastic changes to QUIC. At one point, Spencer Dawkins (Transport Area Director) interrupted the debate to remind the participants that using TLS 1.3 is in the QUIC WG Charter. Eventually, the Anti-DTLS Switch prevailed, as it became obvious that the November 2018 deadline for QUIC would have to slip. As a consolation prize, the chairs promised to appoint a design team potentially to figure out the new architecture.

Martin Thomson (Mozilla) presented his proposal to use two variable-length connection IDs instead of one fixed-length connection ID. This was the result of the work of the design team empaneled at the January Interim meeting. From the current Editor’s Draft:

The long header contains two connection IDs: the Destination Connection ID is chosen by the recipient of the packet and is used to provide consistent routing; the Source Connection ID is used to set the Destination Connection ID used by the peer.

The session wrapped up with two lightning talks: QUIC in the Wild and PLPMTUD. (PL stands for Packetization Layer).

Third Session – Internet Area WG

Among the several presentations, IP Fragmentation Considered Fragile stood out. In it, Ron Bónica highlighted the problems associated with IP fragmentation and proposes a set of common practices for application developers and network operators. To sum it up: avoid IP fragmentation! For details, see the Internet Draft.

Fourth Session – TLS

The last session was the shortest — one hour — but it was the most contentious of all. Under consideration was the TLS Vizability, a proposal to allow a key manager for TLS that would be able to get access to the plaintext exchanged between two endpoints. While first being presented as a solution for data centers, it was eventually acknowledged that state actors may have a good use case for this as well — to snoop. There were several rather heated exchanges that left both Russ Housley (one of the authors) and the WG Chairs a bit exasperated.

Stephen Farrell, the opponent of the proposal, put it this way: “What makes you think it is in the charter of the Working Group to break TLS like this?!”

Even after a plea from the area director, the hum to adopt this draft was inconclusive; if anything, the “Nos” had it. Since the consensus was not reached, any future versions of this draft would have to go through the area director before being put forth before the WG again.

Multicast QUIC Demo

I was able to meet Lucas Pardue at 7 pm at the Hackdemo Happy Hour. Lucas works for BBC Research & Development; his team works on video-related technologies. Multicast QUIC is a technique to transmit video and audio streams to multiple clients using less network resources (fewer streams).

Newcomers’ Dinner

This dinner was conveniently located at a burger joint across the street. I met Jeffrey Yasskin (Google) and Yoav Weiss (Akamai). I talked with Jeffrey about his proposal for web packages, while Yoav shared his expertise in HTTP caching and structured headers. Grizzled veteran programmers and graduate students, we all had a great time saying hello to each other, unashamed of our newbiness.

Tuesday 3/20/2018

First Session – Measurement and Analysis for Protocols

The morning time slot contained several excellent presentations, among them:

• Update on TLS SNI and IPv6 client adoption;
• First look at QUIC in the wild; and
• HTTP server push adoption.

Of particular interest to me was A First Look at QUIC in the Wild. The authors — Oliver Hohlfeld and Jan Rüth of RWTH Aachen University — gather QUIC server support and traffic data and publish it along with some really nice interactive graphs. The eponymous paper has more details.

Second Session – Path Aware Networking

Being a research group, panrg’s work has no immediate applications. Rather, the presentations were mostly an exploration of how things might evolve. Spencer Dawkins’ presentation concentrated on what not to do. Because there have been many ideas that turned out to be bad, why not learn from our own mistakes?

The Path Aware Networking Proposed Research Group has voted to become a full-status research group at the end of its session.

Third Session – HTTPbis

A lot is happening in the HTTP space and there are several interesting proposals, among them

• Secondary certificates;
• Expect-CT header;
• Header common structure (aka structured headers);
• Variants header;
• Cache digests for H2; and
• Client hints.

To see which of these proposals have been adopted by the working group, see the httpbis data tracker.

Secondary Certificates

Secondary certificates is a mechanism whereby a single HTTPS connection can be shared between several origins.

Expect-CT header

CT stands for Certificate Transparency. The Internet Draft describes two use cases for this experimental header. In short, the idea is to make the client detect incorrect certificate configuration on subsequent connections.

Header Common Structure

This draft specify a way to define and use HTTP header fields. This seems to be another cache-related improvement: Mark Nottingham (Fastly) is one of its authors and Yoav Weiss (Akamai) advocated strongly for a scheme just like this one during our Newcomers’ Dinner discussion. Yoav’s concern is compression: splitting the headers into smaller pieces should improve compression performance.

Variants header

The Variants and Variant-Key headers are an alternative way to communicate a secondary key for an HTTP resource. The draft was hummed to be adopted by the working group.

Cache Digests

The draft’s abstract has it best:

This specification defines a HTTP/2 frame type to allow clients to inform the server of their cache’s contents. Servers can then use this to inform their choices of what to push to clients.

The web server should take client hints into account before pushing promises to client.

Client Hints

The client hints are a finer-grained way for a client to specify its preferences — an alternative to the User-Agent header.

London Web Performance Meetup

After the HTTP session wrapped up at 18:15, I caught the Tube to the London Web Performance meetup. The panel consisted of Mark Nottingham (Fastly), Hooman Beheshti (Fastly), Martin Thomson (Mozilla), Jana Iyengar (Fastly), Ian Swett (Google), Mike Bishop (Akamai), and Subodh Iyengar (Facebook).

There were about 20 attendees — among them Lucas Pardue (BBC Research and Development), Yoav Weiss (Akamai), and Barry Pollard (the author of an upcoming book on HTTP/2 (Manning)). The others were web developers for whom, I thought, the panel discussion regarding the various transport-level tradeoffs was a bit over their head. After the discussion, there was beer and pizza, during which I chatted with a few people about QUIC and LiteSpeed. Kazuho Oku gave a lightning talk about client early hints (RFC 8297).

—

Read about Wednesday through Friday in Part Two.