Notes from the Road: IETF 109 Recap

I don’t want to appear hemispheric. – Lars Eggert (taking back his claim that April of next year it will be “spring.”)

I participated in IETF 109 on November 16 – 20, 2020. For the full list of meeting materials and notes, see the agenda. What follows are my observations and some interesting tidbits.

ICT

No, ICT is not a name of an IETF working group. ICT stands for Indochina Time, so named after the Indochinese Peninsula where this timezone is observed. This is also the timezone used to schedule IETF 109 virtual meetings. (For obvious reasons, IETF 109 is completely virtual.) If I lived in Kyzyl, this would be convenient, but because I live in NJ, I had to stay up until the wee hours of the morning to attend some of the meetings.

IPPM

IPPM Working Group deals with IP Performance Measurements. Ian Swett (Google) and Tommy Pauly (Apple) chaired the meeting during which several Internet Drafts were discussed. Of particular interest to me was Explicit Flow Measurements Techniques, an Internet Draft of which I am a co-author. This proposal came out of two competing proposals to utilize two non-encrypted bits in QUIC packet headers to measure and troubleshoot losses in the network. The QUIC WG asked the warring parties to compromise and make a unified draft. It is this hybrid draft that Cociglio Mauro (Telecom Italia) presented to the group.

The Chairs liked the presentation and indicated that the draft may find a home in IPPM. I look forward to continuing to contribute to this effort.

Second-Class Citizens No More

In some of my previous reports of IETF conferences which I attended remotely, I complained that the remote participants are treated as second-class citizens. No more! Wondrously, as soon as everyone had to attend remotely, sound improved (OK, this is probably due to not having to share a microphone per room full of people randomly opening Snickers bars), the discussions began to be better managed, and it was always clear who was speaking. Is the digital future finally here?!

TCPM

TCPM stands for TCP Maintenance. This Working Group’s meeting lasted two hours, during which several items were discussed:

Cubic

Lars Eggert began updating the Cubic RFC (RFC 8312). As usual, an update to an existing RFC bears the monicker “bis,” and so this work is called RFC 8312 bis. (A second update to a specification is called “tre.” I don’t know what comes next.) Several participants expressed an interest in this, as the RFC differs from the Cubic paper.

TCP

Wesley Eddy discussed the ongoing work on RFC 793 bis. Yes, they are really working to update the 40-year-old TCP specification.

Delayed ACKs

The TCP Ack Rate Request (TARR) option was presented by Carles Gomez of Universitat Politècnica de Catalunya. This is similar to the Delayed ACKs extension in QUIC, but for TCP. I have been working on adding the support for Delayed ACKs to lsquic, and so a lot of the ideas covered were familiar to me.

TCPLS

Olivier Bonaventure presented TCPLS — a fusion of TCP and TLS protocols. The idea is to leverage TLS protection and record framing protocol to exchange TCP control data (such as TCP options) and payload in a TLS stream. This integration will allow TCP to match some of the QUIC’s performance advantages. Olivier et al.’s recent research paper positions TCPLS as TCP’s answer to the challenge posed by QUIC:

History tells us that TCP has evolved with competing transport protocols. QUIC is today’s competitor,but there is still plenty of room to improve TCP.

TCPLS belongs to a new family of experimental protocols. Olivier Bonaventure and a few other scholars at the University of Louvain organized into a group to research how to make Internet protocols programmable. In Pluginized QUIC (PQUIC), an endpoint delivers custom QUIC protocol functionality to its peer as eBPF bytecode! In the proof-of-concept example, FEC, or forward erasure correction, is enabled as a plugin. It’s quite innovative way to look at extending the QUIC protocol and I hope to find time to play with PQUIC soon.

TLS

The TLS Working Group discussed the fact that, as it turned out, MAC calculation in DTLS is not injective due to an ambiguous boundary between CID and plaintext. Other topics included issue lists for the ESNI and ECH (Encrypted SNI and Encrypted ClientHello, respectively) drafts.

Implementation Draft

Sean Turner, one of the WG chairs, advocated borrowing QUIC WG’s idea of having “Implementation Drafts” to facilitate interoperability work and experimentation. The response was generally positive. I expect the TLS WG GitHub account to begin sporting a new Wiki page soon.

Gross and Sad

The word of the day during the TLS WG meeting was “gross.” Someone typed in in the Meetecho chat, someone else repeated it at the mic (“if this design weren’t so gross”), and yet a third person used it within five minutes again.

I had observed this effect a few conferences ago, where in a QUIC WG meeting everyone started to use the word “sad.” Quoth Mike Bishop: “this feature of the protocol makes me sad.” After Mike, everyone began feeling sad for the next half hour or so.

This word mirroring effect is probably due to some group dynamic, and it likely even has a name. (If you know the name of this effect, please leave a comment below!)

Finally, it is remarkable how emotionally charged our technical discussions can become. You can tell that IETF is a volunteer effort.

Meetecho Good

Meetecho conferencing software was good. It contained all the necessary features:

• Ability to share screen easily
• Voting mechanism
• Queuing mechanism
• Detachable chat window
• List of participants with clear indicators of who is speaking and who is in the queue
• Working group materials list

Voting in Meetecho TLS WG meeting

QUIC

The QUIC meeting lasted two hours. I do not cover every topic below. Full minutes are here.

WGLC

MAAG? (More Acronyms Are Good?) WGLC stands for Working Group Last Call. This is when Internet Drafts undergo a final review in the working group before being handed off on their way to become RFCs. This is the stage the QUIC and HTTP/3 drafts are at now.

Agenda Bash

A few hours before the meeting was to commence, I emailed the WG proposing that we move the multipath QUIC discussion to the end of the meeting, because it was bound to break out of its timebox. Requesting changes to the agenda is called “agenda bashing” in IETF argot. This was my first agenda bash — and it was successful.

Load Balancers

Martin Duke talked about his QUIC load balancers draft. He has done a lot of work on the document and he implemented a load balancer and some related software, which his employer (F5) allowed him to open-source. It is available on GitHub. Martin asked the WG for feedback and participation. If there were only a server that implemented this protocol with which Martin’s load balancer could interop!

Version Aliasing

The QUIC version aliasing Internet Draft also bears Martin’s name. This is a rather involved mechanism to prevent ossification by having servers and clients share information to make QUIC handshake packets inscrutable on subsequent connections. David Schinazi and Eric Kinnear (representing Google and Apple, respectively) expressed support for this draft. This likely means continued development of this draft along with the QUIC version negotiation draft, on which version aliasing depends.

QLOG

Robin Marx asked the WG for further direction on QLOG development. He has been toiling for years on the QLOG drafts and the QLOG visualization software, qviz. Now it is time for others to pick up the slack. Many members of the WG expressed their admiration for Robin’s work and testified to its usefulness. Matt Joras (Facebook) and others stated that QLOG has become the defacto logging standard. The emerging consensus is either to adopt Robin’s drafts in this working group or to create a new working group, just for QLOG and related technologies. Discussion is bound to continue on the mailing list.

Multipath

The multipath QUIC discussion proceeded at a high level. Among the questions considered were:

• What do we mean when we say “multipath?”
• Should multipath be in a base or parallel version of QUIC?
• What happened to “experiment and get back to the WG?”
• Should we favor using the QUIC extension mechanism?
• Do we have the bandwidth to work on this now?
• Do we need multiple versions of multipath?

Scribing

Robin Marx and I volunteered to be scribes for this meeting. After my initial experience scribing unofficially for the IPPM WG, I was confident that I could do the whole two hours of the QUIC WG meeting. I was lucky to share the load with Robin, who turned out to be an efficient and discerning scribe!

And in the Darkness Bind Them

After the QUIC meeting (at which point it was after 2 AM), I joined in the IETF gather.town hangout. gather.town was used during the last IETF as well, but this was the first time I tried it.

Screenshot of a virtual hallway meeting. Here is the author (pictured at bottom right) chatting with Jana Iyengar (Fastly), Marten Seemann, Robin Marx, Marcus Westerlund , Lars Eggert (NetApp), and Nick Banks (Microsoft).

This VR setup made our chat surprisingly like a hallway conversation in a real-life IETF conference, something that remote participants had always missed out on. Until now. Because everyone was remote, we were all at the same accessibility level and we could all meet and chat, almost like in real life.

SAAG

SAAG is a Working Group for general security-related discussion. The chairs gave an overview of the current work of interest in other Working Groups at the beginning of the meeting.

A Man in the Rough

Who’s the man in the rough? I do not know, either. He manifested as part of a more nuanced man-in-the-middle taxonomy proposed by Christinan Huitema. Earlier discussion on the group’s mailing list dealt with the fact that the current “man-in-the-middle” terminology is imprecise. Christian and some others offered their versions. For example, in Christian’s view, the man in the rough is joined by the man in the middle and the man on the side. (Perhaps after a few too many drinks.) A competing alternative dubs them a malicious messenger; an oppressive observer; and a chaos creator. (This sounds quite alarming!)

Some people rebelled and said that one does not have to invent terminology, it is enough to pick up a book and see what terminology is used in academia and just use that.

History of PKI

Ryan Sleevi presented the history of PKI, going back more than 30 years! His presentation made me realize even more the complexity of PKI. It is important to be aware of previous successes and failures so that we can make better choices going forward.

INTAREA

Internet Area Working Group is for general discussion of Internet-related topics that might not fit elsewhere.

QUIC Tunneling

Maxime Piraux (of Université catholique de Louvain and the author of the most excellent QUIC Tracker) presented three drafts dealing with tunneling over QUIC. His presentation encountered immediate opposition from several members of the working group. “Why is this being presented in this working group?” asked David Schinazi; “this work should be done in MASQUE.” “It is exactly like CONNECT, but worse,” stabbed Tommy Pauly. Éric Vyncke, the Area Director, had to intervene and justify his and the Chairs’ decision to have these documents presented in this working group. It looks like this work, if it is to continue, will continue in the MASQUE Working Group.

ICCRG

Jana Iyengar chairs this working group and he chaired the meeting as well.

LEDBAT

First presentation of ICCRG was on LEDBAT, which sounds like something that would make a good LART. In fact, it stands for Low Extra Delay Background Transport and is specified in RFC 6817. Praveen Balasubramaniam (Microsoft) updated the group on the latest developments in this research area: rLEDBAT and LEDBAT++, which improve on the original design.

CC Census

The Great Internet TCP Congestion Control Census was presented by Ayush Mishra, a second-year PhD student. BBR: first congestion control which does not back up when there is congestion. Measure 20,000 most popular websites on the Internet — study done in 2019. This is not a trivial task. For example: how do you identify congestion control using short downloads of HTML pages?

Each congestion controller has a shape – slide from Ayush’s presentation

Praveen asked about BBRv2 — but BBRv2 does not have a consistent shape and is difficult to identify. More graphs, including BBRv2 are available in the paper.

BBRv2 Update

Neal Cardwell (Google), one of the principal BBR developers, gave updates on the progress of BBRv2 work at Google. They are continuing to develop BBR and related CCs and are inviting researchers to participate in the discussion and experimentation. Neal dedicated a lot of time talking about BBR.Swift, which is a variant of BBRv2 designed for data centers.

Slide from Neal’s presentation

Actively working on BBRv2, experimentation continues, stay tuned!

CC Unfairness

Szilveszter Nádas (Ericsson) talked about congestion control unfairness. Is BBRv2 fair to Cubic? It depends on AQM — CSAQM does a good job keeping BBRv2 and Cubic flows sharing connections fairly. That is to say, it keeps BBRv2 from stomping all over Cubic.

While Szilveszter was speaking, a lively discussion about fairness ensued in the Meetecho chat. Why should a CC be fair to a legacy CC that requires a large queue and causes delays? – asked Christian Huitema. On the other hand, someone else argued, what about those who can’t just pick up and upgrade?

Conclusion

Attending an IETF conference is a great way to learn about a topic, realize just how many things you still do not know about, and to interact with leading experts. So what if I survived on three hours of sleep a night for the past few days? It was worth it!