IETF 103 Bangkok

The MAMI project was back at the IETF for the last time — as a project, anyway — last month at IETF 103 in Bangkok. Join us on a trip through the week!

the IETF 103 venue in Bangkok

Hackathon: Loss-Latency Tradeoff in Mobile Networks

Most of us arrived on the Friday before the meeting in order to attend the now already traditional hackathon. This time we set up a table to pull together a few different projects related to measurement and measurability. Friends of the project Fabio Gulgarella and Mauro Cociglio ran an experiment running on a 2-bit variant of the spin-bit they dubbed “delay sample”. Thomas Fossati, as main representative of the MAMI project, has been doing some measurements on the impact of the LoLa bit on the mobile network.

This is another instance of the “one-bit signalling” topic we’ve been working on in MAMI – notably, a Loss/Latency Tradeoff (LoLa) bit was present in the original PLUS proposal. These experiments are concerned with mapping the LoLa signal to a dedicated low-latency bearer in the LTE core and air interface. This is different from how mobile networks are deployed today, to actively ignoring or bleaching any end-user signal, and bundling all flows to and from the Internet into a single “default” bearer, whose buffering characteristics that are not compatible with low-latency traffic. The established behaviour is partly rooted in the desire to prioritise operators’ voice services over competing over-the-top services, but that market consideration has lost relevance in the recent years.

It looks like the incentives are now aligned in the direction of allowing more suitable treatment of Internet real-time flows. However, a couple of preconditions need to be satisfied before we can move on from the status quo. First, the real-time flows must be efficiently identified so that they can be put on the right queue especially nearby the bottleneck link, which in 4G mobile networks is typically the air interface. This is at odds with the rise of encrypted and multiplexed transports, which has the potential of increasing the cost/accuracy ratio of DPI over the acceptable threshold. LoLa instead is this simple clear-text signal set by the endpoints which would enable a super efficient classifier. The question is how can we trust the endpoints to set the LoLa signal correctly? What if they lie? Would they get an advantage at the expenses of other flows? The hackathon experiments were aimed at answering these core questions. On one hand we wanted to see whether giving mobile devices a low-latency bearer in addition to the default one would make a difference in terms of QoE. And secondly, we wanted to measure what happens when an endpoint lies about the nature of its flows. So Thomas spent his Saturday and Sunday hacking around the LTE module of NS-3 and getting these fine results which he also presented at the HotRFC session on Sunday night. We got some positive feedback about the idea from a few mobile operators in the room.  Thomas, Gorry Fairhurst and Mirja Kühlewind together with Vz, AT&T, Orange and Three managed to schedule a side meeting for later in the week to discuss both the finer points and an overall coordination strategy also involving and the 3GPP liaison Georg Mayer and Florin.

Hackathon: Path MTU Signaling in QUIC

In addition, Tom Jones worked on Path MTU signaling mechanisms for QUIC at the QUIC hackathon table. Tom’s draft describing “Packetization Layer Path MTU Discovery for Datagram Transports” will also be incorporated in QUIC. MTU discovery is also under discussion in the 6MAN Working Group, where there are two competing proposals to add new mechanisms that allow better signalling of MTU by routers a long the path, Truncate and Hop By Hop:

  • The Truncate proposal adds a MTU Destination Option, the intention of this option is that when a router has to discard a packet for being too large it also truncates the datagram. The MTU Destination Option carries the original packet length allowing the end host to detect this packet as ‘truncated’, and the end host uses this packet to send an ICMP PTB message.
  • The Hop By Hop proposal creates a new IPv6 Hop By Hop option. This option is added to small packets, when a router forwards a packet with this option it examines the MTU field in the option, if the MTU is larger than the routers out going link it updates the MTU field to match this link size.

Tom implemented the HBH proposal at the IETF 103 Hackathon to get a sense of how practical it was to add to a real network stack — he had previously implemented the Truncate proposal on the flight back from IETF102 in Montreal. His inplementation in FreeBSD achieved self-interop between end host and router in the two days. Running code is a core part of the IETF ethos, after IETF 103 we are able to compare how the HBH and Truncate proposals compare and differ in implementation.

Monday: Evolving Transport

On Monday, the official sessions started with an interesting discussion about the evolution of transport and the role of proxies in the Transport area open meeting featured with presentations from Lucas Pardue and Ben Schwartz’s team on HiNT and Helium and a presentation from Thomas on PEPs role and fate in an end-to-end encrypted Internet. One of the takeaways of the session is that if we want to keep PEPs alive, which looks like a sensible thing to do at least in some scenarios (cfr. satellite), we need to re-think the security model in particular how the transport security association is modelled and what is its relationship with the security context that sits at the application layer. QUIC in particular, collapses the two into a single inextricable blob, making proxying an all-or-nothing option, which is far from ideal. The “transport proxy” gang (including us, Lucas and Ben’s team) is going to chat further again in December to discuss next steps.

Then the first TSVWG session on Monday touched a little on the PMTUD work happening in other working groups, as already mentioned above. And we had a presentation by friend-of-the-project Colin Perkins on the Transport Header Encryption Draft, recently adopted by the WG, which explores transport-specific considerations of the trend toward more ubiquitous encryption and encryption deeper down the stack.

Tuesday: Measurement and Analysis for Protocols and the MAMI Lunch

The founded-by-MAMI Measurement and Analaysis for Protocols Research Group (MAPRG) met on Tuesday. This time we had an 2-hour slot (slightly shorter than usually) with interesting talk about UDP checksum issues, QUIC performance over  satellite, comparison of CoAP/MQTT/HTTP in vehicular scenarios, as well as measurements on Certificate Transparency and OCSP Must Staple deployment.

Tuesday also saw our traditional lunch for MAMI and friends:

Tuesday and Wednesday: QUIC and the Spin Bit

Since MAMI is largely focused on transport evolution, and transport evolution work in the IETF is now focused on the completion and deployment of the IETF standard version of QUIC, the “main event” of the IETF for the project was the QUIC working group. QUIC met on Tuesday and Wednesday. Tuesday’s meeting covered smaller issues, including the applicability and manageability drafts, presented by Mirja.

After 18 months of heated discussion and thorough experimentation, the latency spin bit was  been accepted during the second session on Wednesday as a feature of the base QUIC protocol. Implementation and participation in signaling are optional, though several large endpoint implementors indicated they will implement and enable the bit by default. The consensus is to add just the spin bit, without the Valid Edge counter described in our recent IMC paper.

QUIC hums on the Spin Bit (image: @csperkins)

This proposal has been pretty controversial, not so much technically but rather from a political perspective – being a proxy for the wider (and highly flammable) discussion around the tension between protocol encryption and network functions in the IETF. One key takeaway of this whole experience (and a key result of the MAMI project as a whole) is that getting the right balance between opaqueness and transparency a protocol’s wire image should provide is a very tough job and requires a great deal of analysis and experimentation along many different axes.

After three years working on these topics, and despite the hyper-sensitivity to privacy issues in the Internet many of us in the project have, we are even more then ever convinced that a world of completely opaque wires is not a place where we would like to spend our future, and that total privacy and total privatisation of the Internet infrastructure are two sides of the same coin. The Internet is a common good and we need to keep it that way, finding the right balance between what is visible and what is not is a tough job but we need to resist the temptation to use the encryption hammer for things that are not necessarily privacy related – e.g., as anti-ossification techniques. We very much hope that this decision enables now more experimentation and will lead to more experience with these kind of explicit signals which can be the basis for more discussion about additional features that would support measurability.

Wednesday: UDP Options, MARC, and Encrypted SNI

Wednesday morning also saw the second TSVWG Working Group session discussing the status of UDP Options, with Tom presenting an implementation report. Tom also followed up on questions asked on the TSVWG mailing list about the future and suitability of FRAG, LITE and AE UDP Options. This led to an enthusiastic discussion about the suitability and use of UDP Options at all. Tom continued with another presentation, this time on Datagram PLPMTUD, this slot was grouped with presentations from the authors of the 6MAN drafts attempting to address PTMUD. These presentations led to very productive working group discussion on both PLPMTUD and PMTUD, with finding the right MTU for a network still being an open problem.

The video interest group (GGIE) side meeting we presented MARC (mobile assisted rate controller), the congestion controller developed by Morteza and Gorry in the project that uses (among others) the mobile throughput guidance signal from the eNodeB to adapt the sending rate to the (very quickly and widely) changing conditions of the mobile network. There was an entertaining discussion around the topic including a nice digression on how to carry the MTG signal in QUIC using UDP options.

In TLS there was more discussion about the encrypted SNI proposal which is trying to remove one privacy-critical bit of clear-text from the TLS wire image. Of course SNI is relevant to policing middleboxes (enterprise TLS proxies, censorship and parental control filters), hence some of the usual scuffle. There are a couple of issues with the current ESNI proposal, one of which is pretty substantial in terms of the ability to reliably deploy the feature, but there is a huge amount of energy being poured into finding a good solution so hopefully we are going to get something done soon-ish. On another topic, the DTLS 1.3 protocol specification is complete and ready for review by the working group. We need some security analysis there which will take a fair amount of cycles. In the meantime, the DTLS 1.2 connection identifier is done and is currently in working group last call. So this should provide an OK solution (although not ideal because of the higher correlation properties compared to 1.3) until 1.3 is finalised and deployed at scale.

Wednesday: Transport Services (TAPS)

The Transport Services (TAPS) working group, in which MAMI heavily contributes, continues its work to standardize an interface to a modern Internet transport layer. The group had a productive session, solving some of the open issues for the API document. In addition Tommy Pauly, another friend of the project, presented a mapping of the TAPS interface to QUIC, leading to a discussion about mappings for different DNS variants (DoT, DoH, … Do*) as a quite interesting use case for taps, given it could actually provide an opportunity to simplify future mappings of DNS to other transports.

If you’d like to help the TAPS effort as well, it’s now the right time to review the architecture document as the first of the taps trilogy, to be published around IETF 104 in March 2019.

Thursday: ACME, Round Tables, and Not-So-Secret Cabals

The very last session of the meeting was ACME. MAMI has a couple of drafts there: the STAR document, which is going through a second LC as we speak due to some adjustments we had to do related to a pretty big last minute change in the base ACME spec, and the delegation draft, which we have re-written as an ACME profile (as per request in Montreal) which – good news everyone! – we got consensus to adopt by the working group. As per IETF process, the official CfA confirmation is currently on the mailing list and should be over in a few days.

On Thursday, the long-running Post Sockets Secret Cabal met, though now this meeting is less an insurgency bent on overthrowing BSD Sockets and more merely an afterparty for the TAPS meeting where we distribute issues to work on before the next interim.

The Post Sockets Not So Secret Cabal (image: @csperkins)

Thursday also saw our LoLa round table. The meeting went well and it was decided that the coordination for the various activities – which are likely to span more than one SDO – should happen in the Internet Group in GSMA. The activity is in progress, and last week I presented the plan at the GSMA IG plenary.

After that we had a de-brief with the spin-bit folks, including Brian joining remotely via Thomas’ laptop :-), to plan the next steps in measurement experimentation on QUIC. This was a fitting end to the technical part of the meeting in Bangkok, as well as the MAMI project’s official engagement in the IETF.  For us, the IETF crowd of the project, it definitely has been an incredible pleasure working in MAMI and progress these important topics in standardization. MAMI has been a fantastic project, which tackled a core technical and societal tussle with an abundance of courage (and/or recklessness, you choose), with a truly amazing group of people! Thanks everybody!