Missing Link: IETF standards – about the future of a “zoo of protocols”

In 2022, the EU Commission presented a new strategy on the desiderata of European standardization policy, and the Federal Ministry of the Interior is considering how more German companies could be “carried” into standardization organizations. There is an area in the Internet Engineering Task Force (IETF), which is meeting in Yokohama in a week’s time, in which German researchers are almost dominating. A conversation with one of the current chairmen of the TCPM working group, Michael Tüxen (Münster University) and his predecessor, Michael Scharf (Esslingen University), about old and new transport protocols for the Internet.

heise online: Mr. Tüxen, Mr. Scharf, up until last year you jointly headed the TCPM working group. But there are other German developers who are active in the field of transport protocols. Mirja Kühlewind was Area Director for Transport for a long time. The current IETF chairman, Lars Eggert, has long led the working group that standardized the new transport protocol Quic. Are transport protocols a German domain?

Michael Scharf: In fact, many people in the Transport Area have a German background. This is probably because the Transport Area is the area in the IETF that is most open to academic contributions. Therefore, many who come from the universities or the scientific field in general find their way into the IETF through this. I myself came to the IETF as a doctoral student and that was also the case with some others. Germany also has a strong research landscape, traditionally also in industrial research. So there are a lot of big players who maintain research facilities in Germany, and that’s how people find their way to the IETF. I myself was a researcher at Alcatel-Lucent and Nokia.

And you, Mr. Tüxen?

Michael Tüxen: Indeed, that’s true. Michael Welzl also comes from this area. Coming from Siemens myself, I got into the transport area via SCTP (Stream Control Transmission Protocol). At Siemens, however, that wasn’t research at all, but product-related systems engineering.

Academic Avenue

But in the Applications area, i.e. applications or routing, these are not recorded in German?

Michael Scharf: I can’t speak much for the IETF application area. But I also did routing in my industrial days. You just have to say that the large development departments and research facilities here are clearly North America. This is clearly reflected in the IETF. It’s a little different for IP routing. There are corners where German or European developers are on the move. This is usually not the core routing, but the areas where there is also industry in Europe. In the field of optical transmission networks, where there are classic manufacturers in Europe who are still active today. In the corresponding working groups you can see many Europeans, the main players are even Europeans – and there are also Germans again and again. In the routing it is clearly structured according to topics. Where there is a European industry, there are also European representatives in the IETF. Where there is no development in Europe, you won’t find anyone in standardization either.

Michael Tüxen: There are still company representatives. But what I noticed is that in the transport sector there is a trend, especially among German participants, to switch from industry to universities. Michael Scharf and I come from industry and are now at universities, as did Martin Stiemerling and Rolf Winter.

Did the universities support the IETF activities?

Michael Tüxen: My university supports that. But that varies.

Michael Scharf: As a university professor, I take a lot of liberties and I take them to remain active in the IETF. There is currently no active support, such as financing. However, I have to say that I have never done the transport area activities in industry as a company representative. That was always my private hobbyhorse.

How does one become an IETF working group leader?

With the standardization of Quic, a major player, namely Google, brought an important new transport protocol to the IETF. Is this the end of the Transport Area’s academic character? And is that reflected in the fact that Ian Swett, one of Google’s Quic developers, is now TCPM-Chair?

Michael Tüxen: We don’t make the choice. The area director does that. In this case, you would have to ask the transport area director (AD) how he made the selection. This may or may not be a professional proximity. Sometimes it’s also about a generic topic. There is also the tactic of adding someone new so that the members of the shared flat can learn something.

What is missing: In the fast-paced world of technology, there is often the time to re-sort all the news and background information. At the weekend we want to take it, follow the side paths away from the current, try different perspectives and make nuances audible.

So it wouldn’t be unusual for a Quic developer from Google to help reform TCP, and the suspicion that there’s more behind it belongs in the realm of conspiracy theories?

Michael Scharf: I have to intervene here. There have certainly been similar cases in the past. Michael Tüxen, for example, is a well-known SCTP developer, and he has become a TCPM chair. From my point of view, this is a tactically smart decision. Because the various transport protocols, TCP, SCTP and Quic, have a lot in common and you need experts for each protocol. For example, I am not an SCTP expert myself. But we have algorithms that have to work across the different protocols. And so it makes a lot of sense to have people with detailed knowledge of the individual protocols. If you look at it from a conspiracy theory perspective, Michael Tüxen should never have become TCPM Chair. In fact, it was smart and that’s how I see it now. It’s definitely good to have people who understand the similarities between Quic and TCP.

Michael Tüxen: There is another aspect. Because I develop in the SCTP area, I mainly deliver my own drafts there. The conflict of interest that a chair is writing a document at the same time can thus be avoided.

To home page