![\"Notes](\"https:\/\/lswp.store\/wp-content\/uploads\/2020\/11\/NFTR-14.png\")
<\/p>\n<\/p>\n
I don\u2019t want to appear hemispheric. – Lars Eggert (taking back his claim that April of next year it will be \u201cspring.\u201d)<\/p><\/blockquote>\n
I participated in IETF 109 on November 16 – 20, 2020. For the full list of meeting materials and notes, see the agenda<\/a>. What follows are my observations and some interesting tidbits.<\/p>\n
ICT<\/h2>\n
No, ICT is not a name of an IETF working group. ICT stands for Indochina Time<\/a>, so named after the Indochinese Peninsula<\/a> 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<\/a>, 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.<\/p>\n
IPPM<\/h2>\n
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<\/a>, 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<\/a>.<\/p>\n
The Chairs liked the presentation and indicated that the draft may find a home in IPPM. I look forward to continuing to contribute<\/a> to this effort.<\/p>\n
Second-Class Citizens No More<\/h2>\n
In some of my previous reports of IETF conferences which I attended remotely, I complained<\/a> 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?!<\/p>\n
TCPM<\/h2>\n
TCPM stands for TCP Maintenance. This Working Group\u2019s meeting lasted two hours, during which several items were discussed:<\/p>\n
Cubic<\/h3>\n
Lars Eggert began updating the Cubic RFC (RFC 8312<\/a>). As usual, an update to an existing RFC bears the monicker \u201cbis,\u201d and so this work is called RFC 8312 bis<\/a>. (A second update to a specification is called \u201ctre.\u201d I don\u2019t know what comes next.) Several participants expressed an interest in this, as the RFC differs from the Cubic paper<\/a>.<\/p>\n
TCP<\/h3>\n
Wesley Eddy discussed the ongoing work on RFC 793 bis<\/a>. Yes, they are really working to update the 40-year-old TCP specification.<\/p>\n
Delayed ACKs<\/h3>\n
The TCP Ack Rate Request (TARR)<\/a> option was presented<\/a> by Carles Gomez of Universitat Polit\u00e8cnica de Catalunya. This is similar to the Delayed ACKs<\/a> extension in QUIC, but for TCP. I have been working on adding the support for Delayed ACKs to lsquic<\/a>, and so a lot of the ideas covered were familiar to me.<\/p>\n
TCPLS<\/h3>\n
Olivier Bonaventure presented TCPLS<\/a> — 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\u2019s performance advantages. Olivier et al.\u2019s recent research paper<\/a> positions TCPLS as TCP\u2019s answer to the challenge posed by QUIC:<\/p>\n
History tells us that TCP has evolved with competing transport protocols. QUIC is today\u2019s competitor,but there is still plenty of room to improve TCP.<\/em><\/p>\n
TCPLS belongs to a new family of experimental protocols. Olivier Bonaventure<\/a> and a few other scholars at the University of Louvain organized into a group to research how to make Internet protocols programmable<\/a>. In Pluginized QUIC<\/a> (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\u2019s quite innovative way to look at extending the QUIC protocol and I hope to find time to play with PQUIC soon.<\/p>\n
TLS<\/h2>\n
The TLS Working Group discussed the fact that, as it turned out, MAC calculation in DTLS is not injective<\/a> 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.<\/p>\n
Implementation Draft<\/h3>\n
Sean Turner, one of the WG chairs, advocated borrowing QUIC WG\u2019s idea of having \u201cImplementation Drafts\u201d to facilitate interoperability work and experimentation. The response was generally positive. I expect the TLS WG GitHub account<\/a> to begin sporting a new Wiki page soon.<\/p>\n
Gross and Sad<\/h3>\n
The word of the day during the TLS WG meeting was \u201cgross.\u201d Someone typed in in the Meetecho chat, someone else repeated it at the mic (\u201cif this design weren\u2019t so gross\u201d), and yet a third person used it within five minutes again.<\/p>\n
I had observed this effect a few conferences ago, where in a QUIC WG meeting everyone started to use the word \u201csad.\u201d Quoth Mike Bishop: \u201cthis feature of the protocol makes me sad.\u201d After Mike, everyone began feeling sad for the next half hour or so.<\/p>\n
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!)<\/p>\n
Finally, it is remarkable how emotionally charged our technical discussions can become. You can tell that IETF is a volunteer effort.<\/p>\n
Meetecho Good<\/h2>\n
Meetecho<\/a> conferencing software was good. It contained all the necessary features:<\/p>\n
\n
- Ability to share screen easily<\/li>\n
- Voting mechanism<\/li>\n
- Queuing mechanism<\/li>\n
- Detachable chat window<\/li>\n
- List of participants with clear indicators of who is speaking and who is in the queue<\/li>\n
- Working group materials list<\/li>\n<\/ul>\n
Voting in Meetecho TLS WG meeting<\/figcaption><\/figure>\n QUIC<\/h2>\n
The QUIC meeting lasted two hours. I do not cover every topic below. Full minutes are here<\/a>.<\/p>\n
WGLC<\/h3>\n
MAAG? (More Acronyms Are Good?) WGLC stands for Working Group Last Call<\/a>. 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.<\/p>\n
Agenda Bash<\/h3>\n
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 \u201cagenda bashing\u201d in IETF argot. This was my first agenda bash — and it was successful.<\/p>\n
Load Balancers<\/h3>\n
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\u2019s load balancer could interop!<\/p>\n
Version Aliasing<\/h3>\n
The QUIC version aliasing Internet Draft<\/a> also bears Martin\u2019s 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<\/a>, on which version aliasing depends.<\/p>\n
QLOG<\/h3>\n
Robin Marx asked the WG<\/a> 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\u2019s 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\u2019s 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.<\/p>\n
Multipath<\/h3>\n
The multipath QUIC discussion proceeded at a high level. Among the questions considered were:<\/p>\n
\n
- What do we mean when we say \u201cmultipath?\u201d<\/li>\n
- Should multipath be in a base or parallel version of QUIC?<\/li>\n
- What happened to \u201cexperiment and get back to the WG?\u201d<\/li>\n
- Should we favor using the QUIC extension mechanism?<\/li>\n
- Do we have the bandwidth to work on this now?<\/li>\n
- Do we need multiple versions of multipath?<\/li>\n<\/ul>\n
Scribing<\/h3>\n
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!<\/p>\n
And in the Darkness Bind Them<\/h2>\n
After the QUIC meeting (at which point it was after 2 AM), I joined in the IETF gather.town<\/a> hangout. gather.town was used during the last IETF as well, but this was the first time I tried it.<\/p>\n
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).<\/figcaption><\/figure>\n 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.<\/p>\n
SAAG<\/h2>\n
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.<\/p>\n
A Man in the Rough<\/h3>\n
Who\u2019s 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\u2019s mailing list dealt with the fact that the current \u201cman-in-the-middle\u201d terminology is imprecise. Christian and some others offered their versions. For example, in Christian\u2019s 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!)<\/p>\n
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.<\/p>\n
History of PKI<\/h3>\n
Ryan Sleevi presented<\/a> the history of PKI<\/a>, 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.<\/p>\n
INTAREA<\/h2>\n
Internet Area Working Group is for general discussion of Internet-related topics that might not fit elsewhere.<\/p>\n
QUIC Tunneling<\/h3>\n
Maxime Piraux<\/a> (of Universit\u00e9 catholique de Louvain and the author of the most excellent QUIC Tracker<\/a>) presented<\/a> three drafts dealing with tunneling over QUIC. His presentation encountered immediate opposition from several members of the working group. \u201cWhy is this being presented in this working group?\u201d asked David Schinazi; \u201cthis work should be done in MASQUE<\/a>.\u201d \u201cIt is exactly like CONNECT, but worse,\u201d stabbed Tommy Pauly. \u00c9ric Vyncke, the Area Director, had to intervene and justify his and the Chairs\u2019 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.<\/p>\n
ICCRG<\/h2>\n
Jana Iyengar chairs this working group<\/a> and he chaired the meeting as well.<\/p>\n
LEDBAT<\/h3>\n
First presentation of ICCRG was on LEDBAT, which sounds like something that would make a good LART<\/a>. In fact, it stands for Low Extra Delay Background Transport and is specified in RFC 6817<\/a>. Praveen Balasubramaniam (Microsoft) updated the group<\/a> on the latest developments in this research area: rLEDBAT and LEDBAT++, which improve on the original design.<\/p>\n
CC Census<\/h3>\n
The Great Internet TCP Congestion Control Census<\/a> 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?<\/p>\n
Each congestion controller has a shape – slide from Ayush\u2019s presentation<\/figcaption><\/figure>\n 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<\/a>.<\/p>\n
BBRv2 Update<\/h3>\n
Neal Cardwell (Google), one of the principal BBR developers, gave updates on the progress of BBRv2 work<\/a> 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.<\/p>\n
Slide from Neal\u2019s presentation<\/figcaption><\/figure>\n Actively working on BBRv2, experimentation continues, stay tuned!<\/p>\n
CC Unfairness<\/h3>\n
![\"IETF](\"https:\/\/lswp.store\/wp-content\/uploads\/2020\/11\/nftr-14-a.png\")
![\"\"](\"https:\/\/lswp.store\/wp-content\/uploads\/2020\/11\/nftr-14-b-1.png\")
![\"IETF](\"https:\/\/lswp.store\/wp-content\/uploads\/2020\/11\/nftr-14-c.png\")
![\"IETF](\"https:\/\/lswp.store\/wp-content\/uploads\/2020\/11\/nftr-14-d.png\")