Notes From the Road: IETF 101 Part 2
First Session – TLS 1.3
The second meeting of the TLS working group covered position of CIDs in DTLS 1.3, DNSSEC chain extension, and others.
Alessandro Ghedini (Cloudflare) presented his proposal to compress certificate chains using Brotli. Up to 30% savings could be achieved. This optimization is particularly germane to QUIC, as it reduces the reflection attack risk.
Christian Huitema (Microsoft) talked about encrypted SNI. This is an early proposal and will require a security analysis.
Lunch – Africa Initiative
Instead of lunch, I attended the IETF Africa Initiative session organized by Kevin Chege. The initiative aims to increase involvement in the IETF by participants from Africa. Nesredien Suleiman, a professor from at the University of Addis Ababa, presented the results of his own efforts in Kenya. This was followed by a discussion with several insightful comments offered by several African attendees — a professor from the University of Ilorin (Nigeria), an advisor to the Minister of Education of Mozambique, and others. The role of government in effecting positive change was discussed, with Kenya being an example of this working.
Third Session – ACME
The topics discussed at the Automated Certificate Management Environment WG meeting were somewhat obscure to me. ACME is the protocol behind LetsEncrypt — a push to convert all HTTP servers to use TLS. This effort shows no signs of slowing down.
Fourth Session – IETF Plenary
The plenary session began at 5:15 pm and lasted almost four hours. The auditorium was large enough to hold 500-600 people, but not all seats were taken. The divers boards, committees, and chairs of the IETF of associated organizations took turns taking the stage. Awards were presented and speeches were made. Practical matters were also discussed: budget; diversity; technical leadership; cost of registration and visas for people from developing nations. In a memorable exchange, Kyle Rose chastised the IAOC for the lack of cookies (yes, the edible kind) at the conference. Quoth Kyle: “I was reduced to buying cookies with cash!”
I realized what a diverse, yet, at the same time, close-knit community of people IETF really is. It is quite astonishing how this self-organized, self-appointed, and mostly unpaid body of techies is dictating — most of the time successfully — the rules of the Internet game to the world.
First Session – QUIC: The Spin Bit Debate
ECN – Explicit Congestion Notification
First, the working group reviewed some outstanding items of the ECN proposal. It was decided that the ECN will make it into the main draft around June of this year.
Latency Spin Bit
Brian Trammell presented the latency spin bit. This produced two hours of rather heated debate as many people were unwilling to give up even one bit for the spin bit, afraid of information leakage. Network operators — Orange, Verizon, AT&T — insisted that the spin bit would be very useful, especially with the looming packet number encryption. At one point, the microphone queue was over twenty people long.
Spencer Dawkins had to intervene a few times to get the working group focussed again. At the end, it was hummed that Brian’s version of the spin bit was wanted, albeit in a separate draft. Three bits for the spin bit are to be reserved in the current draft and, when and if the spin bit draft is deemed finished, the reference to it will be made.
Second Session – DOH
DOH stands for DNS over HTTP. The DOH Internet Draft lists several reasons when DNS over HTTP may be preferable.
D. K. Gillmor (DKG) presented his Opportunistic DNS idea. It is possible for a web server to push DNS records (of the content type specified in the DOH protocol) if it thinks that the client might need them!
This may allow the client to skip sending DNS requests needed to render the page, thereby loading it faster. Some interest was shown in the room, in particular by Patrick McManus and Mark Nottingham. The latter noted that something like this had already been discussed in the httpbis WG.
Third Session – Transport Area WG
The most interesting (to me) presentation in this session was the Packetization Layer Path MTU Discovery for Datagram Transports. This is because it has applicability to QUIC. In fact, the draft describes how the algorithm it proposes can be used in QUIC.
During Gorry Fairhurst’s presentation, Spencer Dawkins queried Lars Eggert whether QUIC does any sort of path MTU discovery. Lars replied that this is currently not in scope, because he does not have a good feeling of how complicated this is. Gorry said that it would be nice if someone from the QUIC WG reviewed this. David Black (one of the TSVWG chairs) said that he would like QUIC to be upwards compatible with this.
First Session – Internet Congestion Control
BBR @ Google
Nick Cardwell updated the group on the ongoing BRR work at Google.
PCC: Performance-oriented Congestion Control
Michael Schapira stole the show with his presentation. I thought it was the best presentation — both in content and in style — of the whole IETF 101. The video recording is also available — it is well worth watching.
The PCC approach is both novel and logical at the same time. The main idea of PCC is that a packet loss does not necessarily mean congestion — the assumption that underlies all TCP flavors. There are four main causes of packet loss:
- Current flow is the cause of the congestion. The current flow should back off.
- Shallow buffer is overflown. The current flow should back off a little.
- Some other flow is the cause of the congestion. That other flow should back off.
- Loss is random. No action should be taken.
Note that TCP treats all four events the same, whereas only (1) should cause the sender substantially to reduce its CWND.
PCC uses game theory to calculate a utility function value. Experiments are run continuously to see how reducing or increasing CWND affects the utility value. Based on the experiment results, the CWND may be adjusted.
The approach PCC takes is totally unlike TCP — I don’t even think it can be called TCP. On the other hand, PCC can be deployed now, as only the sender logic is modified. Otherwise, it is compatible with TCP.
I would be lying if I said that I understood everything I had heard in all of the presentations. Each working group is highly specialized and it requires a significant amount of involvement to understand, let alone comment on, the particulates. I felt satisfied if I grasped the gist of the discussion — which was most of the time.
The IETF is alive, well, and growing. The Task Force’s work scope is tremendous: from fixing 37-year-old bugs in TCP specification to theorizing about the evolution of the networks; from intra-datacenter protocol improvements to providing satellite Internet access to the developing world. And anyone can get involved!
When it comes to QUIC, there are still many unfinished pieces. If our Working Group is to make the November 2018 deadline, we should stop trying to boil the ocean. Baby steps: let’s start with the Great Lakes.