Missing Link: Auch Internetprotokolle haben ihren Lifecycle
Deutsche Forscher dominieren in der Internet Engineering Task Force (IETF). heise online hat mit zwei von Ihnen über den "Zoo von Protokollen" gesprochen.
(Bild: asharkyu/Shutterstock.com)
Die EU-Kommission präsentierte 2022 eine neue Strategie zu den Desideraten europäischer Standardisierungspolitik und im Bundesinnenministerium wird darüber nachgedacht, wie man mehr deutsche Firmen in Standardisierungsorganisationen "tragen" könnte. Dabei gibt es in der in einer Woche in Yokohama tagenden Internet Engineering Task Force (IETF), einen Bereich, in dem deutsche Forscher fast schon dominieren. Ein Gespräch mit einem der aktuellen Vorsitzenden der TCPM-Arbeitsgruppe, Michael Tüxen (Hochschule Münster) und seinem Vorgänger, Michael Scharf (Hochschule Esslingen), über alte und neue Transportprotokolle fürs Internet.
heise online: Herr Tüxen, Herr Scharf, Sie haben bis im vergangenen Jahr die TCPM-Arbeitsgruppe gemeinsam geleitet. Es gibt aber weitere deutsche Entwickler, die im Bereich Transportprotokolle aktiv sind. Mirja Kühlewind war längere Zeit Area Director für Transport. Der aktuelle IETF-Vorsitzende, Lars Eggert, hat lange die Arbeitsgruppe geleitet, die das neue Transportprotokoll Quic standardisiert hat. Sind Transportprotokolle eine deutsche Domäne?
Michael Scharf: Tatsächlich haben viele Personen in der Transport Area einen deutschen Hintergrund. Das kommt wohl daher, dass die Transport Area der Bereich in der IETF die ist, die am offensten ist für akademische Beiträge. Daher finden viele, die aus den Universitäten oder dem Wissenschaftsbereich allgemein kommen, darüber den Einstieg in die IETF. Ich selbst bin als Doktorand in die IETF gekommen und das ist auch bei einigen anderen so gewesen. Deutschland hat außerdem eine starke Forschungslandschaft, traditionell auch in der Industrieforschung. Also es gibt viel große Player, die in Deutschland Forschungseinrichtungen unterhalten, und auch darüber finden die Leute zur IETF. Ich selbst war Forscher bei den Firmen Alcatel-Lucent und Nokia.
Und Sie, Herr Tüxen?
Michael Tüxen: Tatsächlich, das stimmt. Auch Michael Welzl kommt genau aus diesem Bereich. Ich komme selbst von Siemens und bin über SCTP (Stream Control Transmission Protocol) in die Transport Area gekommen. Bei Siemens war das aber gar nicht Forschung, sondern Produkt nahes Systems-Engineering.
Akademische Avenue
Aber in dem Bereich Applications, also Anwendungen oder Routing, diese sind nicht so deutsch bespielt?
Michael Scharf: Für den IETF-Bereich Application kann ich wenig sprechen. Aber ich habe in meiner Industriezeit auch Routing gemacht. Da muss man einfach sagen, die großen Entwicklungsabteilungen und Forschungseinrichtungen hier sind klar Nordamerika. Das spiegelt sich klar in der IETF wider. Fürs IP-Routing ist es ein wenig anders. Da gibt es Ecken, wo deutsche oder europäische Entwickler unterwegs sind. Das ist meistens nicht das Core-Routing, sondern die Gebiete, wo es in Europa auch Industrie gibt. Im Bereich optische Übertragungsnetze, wo es in Europa klassische Hersteller gibt, die bis heute aktiv sind. In den entsprechenden Arbeitsgruppen sieht man daher wieder viele Europäer, die wesentlichen Spieler sogar sind Europäer – und da sind auch immer wieder Deutsche dabei. Im Routing ist es klar nach Themen gegliedert. Da, wo es eine europäische Industrie gibt, gibt es auch europäische Vertreter in der IETF. Da, wo in Europa keine Entwicklung stattfindet, trifft man auch niemanden in der Standardisierung.
Michael Tüxen: Es gibt schon noch Firmenvertreter. Was ich aber bemerkt habe, ist, dass im Transportbereich ein Trend gerade bei deutschen Teilnehmern ist, von der Industrie in die Hochschulen zu wechseln. Michael Scharf und ich kommen von der Industrie und sind jetzt an Hochschulen, und auch Martin Stiemerling und Rolf Winter haben das gemacht.
Unterstützten die Hochschulen die IETF-Tätigkeit denn?
Michael Tüxen: Meine Hochschule unterstützt das. Aber das ist unterschiedlich.
Michael Scharf: Als Hochschulprofessor hat man viele Freiheiten und die nehme ich mir, um in der IETF weiter aktiv zu sein. Eine aktive Unterstützung, etwa durch eine Finanzierung, gibt es gerade nicht. Ich muss allerdings dazu sagen, ich habe die Transport Area-Tätigkeiten auch in der Industrie nie als Firmenvertreter gemacht. Das war immer mein privates Steckenpferd.
Wie wird man IETF Arbeitsgruppen Chef?
Mit der Standardisierung von Quic hat ein großer Player, nämlich Google, ein wichtiges neues Transportprotokoll in die IETF gebracht. Ist das das Ende des akademischen Charakters der Transport Area? Und spiegelt sich das auch darin, dass nun Ian Swett, einer der Quic-Entwickler von Google, TCPM-Chair ist?
Michael Tüxen: Also die Wahl treffen nicht wir. Das macht der Area-Director. Man müsste also in diesem Fall den Transport Area-Director (AD) fragen, wie er ausgewählt hat. Das kann eine fachliche Nähe sein, oder eben nicht. Manchmal geht es auch um ein generisches Thema. Es gibt auch die Taktik, dass man jemand neuen hinzunimmt, damit die Mitglieder der WG noch was lernen.
Dass ein Quic-Entwickler aus dem Haus Google TCP mit reformieren soll, wäre also nichts Ungewöhnliches und der Verdacht, dass da mehr dahintersteckt, gehört ins Reich der Verschwörungstheorien?
Michael Scharf: Da muss ich mal einhaken. Es gab durchaus schon ähnliche Fälle in der Vergangenheit. Michael Tüxen zum Beispiel ist ein sehr bekannter SCTP-Entwickler, und er ist doch TCPM-Chair geworden. Aus meiner Sicht ist das eine taktisch kluge Entscheidung. Denn die verschiedenen Transportprotokolle, TCP, SCTP und Quic, haben viele Gemeinsamkeiten und da braucht man Experten für jedes Protokoll. Ich selbst bin zum Beispiel kein SCTP-Experte. Wir haben aber Algorithmen, die über die verschiedenen Protokolle hinweg funktionieren müssen. Und da macht es sehr viel Sinne, Leute mit Detailkenntnis der einzelnen Protokolle zu haben. Sieht man es verschwörungstheoretisch, hätte Michael Tüxen niemals TCPM-Chair werden dürfen. Tatsächlich war es klug und so sehe ich das auch jetzt. Es ist auf jeden Fall gut, Leute zu haben, die die Gemeinsamkeiten von Quic und TCP kennen.
Michael Tüxen: Es gibt noch einen anderen Aspekt. Dadurch, dass ich im SCTP-Bereich entwickle, liefere ich vor allem dort eigene Drafts. Der Interessenkonflikt, dass ein Chair gleichzeitig noch ein Dokument schreibt, kann damit vermieden werden.
Transportprotokolle zuhauf
Sprechen wir kurz über SCTP, worin unterscheidet es sich von TCP?
Michael Tüxen: SCTP geht zurück auf die Zeit um 2000. Telefonvermittlungsstellen haben über ein spezielles Netz Signalisierungsinformation ausgetauscht, das Nummer 7 Netz. Und das wollte man auf IP migrieren. Dafür brauchte man ein Transportprotokoll, das die Netzwerk-Fehlertoleranz bietet und dabei mehr bietet als TCP. Daher wurde SCTP entwickelt. Ursprünglich lief das über UDP, so wie heute Quic. Aber im Rahmen der Standardisierung ging man dann nativ auf IP.
Was hat SCTP noch für eine Bedeutung?
Michael Tüxen: Es wurde designt für Telefon-Signalisierung, und wird da immer noch benutzt, etwa in 5G-Netzen. Für Endnutzer ist es nicht sichtbar. Der andere Use-Case, für den es eigentlich nicht gemacht wurde, sind WebRTC-Data-Channel. Wenn man nicht die Audio- und Videokommunikation, sondern die Datenkommunikation bei WebRTC anschaut, geht das über SCTP. Da ist der wesentliche Grund, dass man eine Transportverbindung hat, die dann Congestion-Control regelt und mehrere Data-Channel hat, also mehrere Kommunikationskanäle, die Ordering bieten. Das sind die Streams. Das Feature Multistreaming ist da der Punkt. Multihoming ist da irrelevant.
Eine Zeit lang wurde an einer sicheren Variante von TCP gearbeitet, TCPinc. Die Idee war, dass Sicherheit in TCP integriert werden sollte und damit hätte man vorweggenommen, was Quic heute bietet. Warum wurde aus TCPinc nichts?
Michael Scharf: Es gibt inzwischen nur noch relativ wenig Datenverkehr, der rein TCP ist. Meist tritt TCP in Kombination mit TLS-Verschlüsselung auf. Unverschlüsselter Transport ist eine Seltenheit geworden. Man muss heute TCP und TLS zusammen betrachten.
Bei TCPinc war eine der Fragen, was ist der große Vorteil von TCPinc, also einer integrierten Lösung, im Vergleich zu TCP und TLS. Ich denke, auf der technischen Ebene ist der Vorteil überschaubar. Alles, was man mit TCPinc machen kann, geht auch über TLS. Da die Leute gerade schon auf TLS gewechselt hatten, war die Motivation gering, noch ein Protokoll zu implementieren, das praktisch das gleich macht. TCPinc war technisch gar keine so uninteressante Lösung. Sie wurde aber erst zu einem Zeitpunkt fertig, als TLS schon in vielen Applikationen eingefügt war. Quic bietet ähnliche Funktionen wie TCP und TLS zusammen in einem Protokollstapel. Zu den Unterschieden gehören etwa schnellere Handshakes. Aber im Großen und Ganzen ist die Funktionalität von Quic ähnlich wie TCP und TLS.
Würde man in die 80er zurückgehen und TCP mit dem heutigen Wissen noch mal entwickeln, dann würde man vielleicht eine Lösung finden, die TCP und TLS oder eine andere Sicherheitslösung enger miteinander verzahnt. Im öffentlichen Internet werden beide Protokolle inzwischen fast immer gemeinsam verwendet.
Michael Tüxen: Außerdem braucht man für TCPInc eine modifizierte TCP-Implementierung.
Renovierungsarbeiten
Wie TCP wurde auch SCTP gerade "renoviert", da waren Sie wieder Mitautor, Herr Tüxen. Was wollte man erreichen?
Michael Tüxen: RFC 2960 ist schnell entstanden, innerhalb von einem Jahr. Der Modus für das Update war so, dass wir Fehler unterschiedlichster Art in einem Draft sammeln. Wenn wir ein stabiles Bild haben, wird daraus ein neuer SCTP-RFC gemacht. Daraus wurde erst RFC 4960 und im vergangenen Jahr RFC 9260. Da werden aber keine neuen Funktionalitäten eingebaut. Wir haben bei 9260 in geringem Maß zwar kleine separate RFCs integriert, aber es gibt keine großen funktionalen Änderungen und ältere Implementierungen bleiben kompatibel. Bei der Renovierung von TCP war es anders. Der TCP-RFC war doch deutlich älter und stammte aus einer Zeit, wo bei IP noch andere Dinge gemacht wurden. Das hat man einfach herausgenommen, angepasst an die aktuelle Situation. Aber auch hier wurde die Funktionalität nicht wesentlich geändert.
Michael Scharf: Wenn man wieder ein aktuelles Dokument hat, senkt man auch die Einstiegshürden für jemanden, der sich da neu einarbeiten muss. Die alte TCP-Spezifikation (RFC 793) aus dem Jahr 1981 machte die Lektüre von wenigstens einem Dutzend RFCs notwendig. Nur so konnte man das gesamte Protokoll verstehen. Im neuen TCP-RFC (RFC 9293) hat man versucht, die Spezifikation stärker aus sich heraus verständlich zumachen.
Das Update war auch dringend, weil sich langsam die erste TCP-Entwicklergeneration aus der Standardisierung verabschiedet. Die Basis-RFC sind von 1982 und die Entwickler von damals sind heute praktisch nicht mehr in der IETF aktiv. Man kann also nicht mehr wie früher nachfragen, wenn man auf unklare Stellen in der Spezifikation stößt. Das Wissen geht nach und nach verloren… Eine Neuspezifikation erlaubt es, Wissen noch mal abzufragen bei den TCP-Autoren und zu konservieren. Bei TCP ist das wegen des Alters des Standards besonders wichtig. Immerhin, als die Vorläufer von TCP entstanden, war ich noch nicht mal geboren.
Bei SCTP, Herr Tüxen, kann man Sie immerhin noch fragen, wie habt ihr das damals gemeint?
Michael Tüxen: Genau. Aber da ist die Stabilität der Implementierung eine andere als bei TCP: Aufgrund der kürzeren Historie und des Deployments. Wir haben im Verlauf der letzten Version zum Beispiel relativ kurz vor Schluss noch eine Unklarheit im Text gemeldet, die bei einer Implementierung zu Sicherheitsproblemen führt. Das ist sozusagen der Stabilisierungsprozess.
Transportprotokoll Konkurrenten, Zukunft von TCP
Ist ein gut gereiftes Protokoll – wie reifer Käse oder Wein – runder und was heißt das für den jungen Wein wie Quic? Im Ernst, wird man an den älteren Protokollen TCP, SCTP, UDP weiter arbeiten oder verschiebt sich das mehr nach Quic?
Michael Tüxen: Das hängt von den Use-Cases ab. Bei SCTP ist es so, dass im Signalisierungs-Use-Case eine Entwicklung da ist, Sachen in die Cloud zu bringen. Dazu muss man sich mit Network Address Translation, NAT, auseinandersetzen. Denn die bisherigen Use-Cases kannten keine NATs. Das heißt, die Entwicklung ist eine Anpassung an die Use-Cases. Bei TCP sehe ich die Veränderungen vor allem im Bereich Congestion Control und Loss Recovery, also Stau- und Lastkontrolle. Wenn Quic jetzt einen Großteil der Last im Webbereich wegnimmt, ist das aber vielleicht nicht mehr so relevant. Also andere Use-Cases könnten relevant werden.
Herr Scharf, sie haben schon gesagt, die nächsten Entwicklungsschritte bei TCP werden im Bereich von Staukontrolle und Überlast-Fragen sein. Richtig?
Michael Scharf: Ich denke ja. Ich verfolge TCPM seit 20 Jahren, und schon vor 20 Jahren dachte ich, das Protokoll ist stabil und da wird nicht mehr viel passieren. Aber schon die vergangenen 20 Jahre haben gezeigt, dass sich da viel tun kann. Vor allem in der Überlastregelung. Und, wie Michael Tüxen sagt, wenn neue Anwendungsfälle und neue Technologien hinzukommen, muss man immer wieder schauen, wie man die Überlastregeln anpasse. Da wird es weitere Entwicklungen geben.
Bei der IETF kann man das beeinflussen?
Michael Scharf: Ja, irgendwann wird ein neuer Anwendungsfall auftauchen und eine neue Community bei der IETF ankommen und sagen, wir brauchen hier eine Änderung. Und weil die IETF offen ist, wird sie darauf auch reagieren und RFCs ändern. Die Änderungen werden ganz sicher von außen kommen durch Anwendungsfälle, die wir noch nicht kennen oder die nicht optimal gelöst sind.
Das ist der Unterschied zwischen TCP und Quic in meinen Augen. Quic ist sehr spezialisiert für einen Anwendungsfall, den Webverkehr. TCP war immer ein generisches Protokoll, das unterschiedlichste Anwendungen unterstützen kann. Es ist nicht für alle Anwendungen das Beste, aber bisher für die allen meisten Anwendungen einsetzbar und auch gut genug. Deshalb bin ich ganz optimistisch, dass TCP auch in Zukunft Verwendung finden wird.
Zu der Staukontrolle soll es ja dann eine eigene Arbeitsgruppe geben ...
Michael Tüxen: Ja, die Staukontrolle ist relativ Protokoll-agnostisch. Wenn man genügend Signale bekommt, ist es egal, ob TCP, Quic oder SCTP eingesetzt wird. Die generischen Sachen sollen nun in eine Congestion Control-Arbeitsgruppe gehen. Aber bevor man da an die Arbeit geht, soll in der IETF prozedural geklärt werden, wie man neue Congestion Control-Mechanismen spezifizieren will. Was also der Prozess ist, das zu machen.
Warum?
Michael Tüxen: Wenn bisher jemand zur TCPM-Arbeitsgruppe gekommen ist, hat Michael Scharf ihn gleich zur ICCRG (Internet Congestion Control Research Group) geschickt (lacht). Es gibt eine hohe Hürde für die Standardisierung von Congestion Control in der IETF. Momentan ist der einzige offizielle IETF-Standard New Reno. Bei TCPM wurde die Arbeit, Cubic von einer experimentellen zu einer Standardspezifikation aufzuwerten, abgeschlossen.
Wie unterschiedlich ist es denn, wenn man Staukontrolle bei Festnetz und Mobilfunknetz betrachtet, Mobilverkehr macht ja mehr aus?
Michael Scharf: Rein technisch gibt es einen ganz großen Unterschied. Bei der Staukontrolle gibt es immer zwei große Ansätze. Der Sender kann entweder auf Paketverlust reagieren, das ist das, was seit Van Jacobsens mit Reno gemacht wurde. Als zweite Option kann man mit Verzögerung arbeiten. Man versucht dabei, zu entdecken, wenn Pakete in der Schlange stehen. Diese verzögerungsbasierten Varianten funktionieren im Festnetz sehr gut. Im Mobilfunk ist es schwieriger, weil Mobilfunktechnik und WLAN keine konstante Verzögerung haben. Das heißt, alle verzögerungsbasierten Überlastverfahren haben hier Schwierigkeiten. Das hat man immer wieder gesehen.
Michael Tüxen: Beim IETF ist gerade auch viel Aktivität in Richtung ECN-Markings, dass man nicht nur Verlust als Indikator nimmt, sondern auch ECN-Markings.
Was ist das?
Michael Tüxen: Wenn ein Router unter Last kommt, kann er Pakete wegwerfen. Aber man kann auch eine Variante wählen, dass er im Lastfall zwar weiterleitet, aber die Pakete eben markiert, um zu sagen, ich bin unter Last. Wenn das auf IP und Transportniveau unterstützt wird, können die Router entsprechend reagieren. In diese Variante wird aktuell einige Energie investiert.
Lebenszyklen von Protokollen
Kann ein Transportprotokoll sterben?
Michael Scharf: Da fällt mir DCCP (Datagram Congestion Control Protocol) ein. Das ist ein Transportprotokoll, das mal für Multimediaanwendungen standardisiert wurde. Das ist von wenigen Ausnahmen abgesehen nie geflogen. Es kann immer passieren, dass in der IETF entwickelte Protokolle nicht abheben.
Wenn es mal fliegt, stirbt es also nicht?
Michael Scharf: Doch. Es gibt Beispiel für Anwendungsprotokolle, die durch etwas Moderneres oder Anderes abgelöst wurden. Mir würde im Chatbereich zum Beispiel XMPP (Extensible Messaging and Presence Protocol, Jabber) einfallen. Im Telefoniebereich wird es spannend werden zu beobachten, was mit SIP (Session Initiation Protocol) passiert. Es gibt Beispiele, dass Protokolle genutzt werden, und dann an ihren Lebensabend kommen. FTP ist auch so ein Beispiel. Ich will nicht ausschließen, dass das irgendwann auch auf Transportprotokolle zutreffen könnte. Bei TCP dürfte das aber noch sehr, sehr lange dauern. Weil manche der Anwendungsfälle so speziell sind und es auch in vielerlei Hardware steckt. Es kann aber passieren, dass bestimmte Anwendungsfälle nicht mehr vorkommen. Gerade im Webbereich ist es sehr wohl möglich, dass wir TCP in 10 Jahren nur noch in exotischen Bereichen sehen werden. Protokolle, das würde ich sagen, haben einen Lebenszyklus.
Michel Tüxen: Die Geschwindigkeit ist sehr abhängig vom jeweiligen Bereich. Im Webbereich sehen wir beispielsweise alle zehn Wochen neue Browser Versionen von den größeren Herstellern. Die Signalisierung im Mobilfunkbereich ist weniger schnelllebig. Da weiß man, dass man Dinge für 10 oder 15 Jahre kompatibel regeln muss. Dann dauert das Sterben ein wenig länger, und man muss noch eine Weile nachpflegen, bis alle Geräte und Anwendungen ausgephased sind. In der Standardisierung kann das schneller gehen, dass Leute sagen, da brauchen wir nichts mehr machen. Das ist dann der erste Indikator für ein Sterben.
Ein Internet ohne TCP, werden wir das noch erleben?
Michael Scharf: Ich habe immer schon Späße in der IETF gemacht, was wohl das letzte TCP Segment sein wird, das übertragen wird. Meine Vermutung wäre, TCP Segment mit SYN Flag zum Verbindungsaufbau, weil der letzte Host, der noch TCP sprechen will, vergeblich versucht jemand anderen zu finden. Ich würde aber auch vermuten, es wird noch sehr lange dauern.
Michael Tüxen: Über IPv4 oder IPv6 (lacht)?
Michael Scharf: Ich würde persönlich keinen Bierkasten darauf verwetten, dass es ein IPv6-Paket ist. Aber die Protokolle sind sehr, sehr lang im Einsatz. Es gibt Anwendungsfälle von Transportprotokollen, wo Produkte 10 bis 15 Jahre im Einsatz sind, auch im IoT-Bereich. Dann ist Innovation sehr langsam.
Michael Tüxen: Die Rückwärtskompatibilität ist sehr wichtig. Im Prinzip kann ein aktueller TCP-Stack noch mit dem Original-TCP-Stack kommunizieren, der vor 40 Jahren implementiert wurde. Also modulo Performanz und modulo Bugs. Aber im Prinzip können die noch miteinander.
Von generischen zu Spezial Transport Protokollen
Wohin gehen die Arbeiten mit Webtransport? Es gibt dazu eine eigene Arbeitsgruppe. Inwiefern geht das weg von diesen Klassiker-Protokollen? Und warum braucht es noch Webtransport, wo wir doch nun Quic haben?
Michael Tüxen: Das, was das Bild verändert gerade, ist, dass wir von einem generischen Transportprotokoll mit Optimierungen für einen Bereich – über deren mögliche negative Effekte für anderes dann heiß diskutiert wird – zu Transportprotokollen, die speziell optimiert sind für einen einzigen Use-Case. Oder vielleicht noch eine Variante für einen anderen Use-Case. Das verschiebt die Möglichkeiten bei der Optimierung. Man kann noch besser auf eine spezifische Anforderung eingehen.
Es wird also ein größeres Spektrum an Transportprotokollen geben? Und ich suche aus?
Michael Tüxen: Vielleicht nicht ein größeres Spektrum an ganz unterschiedlichen Protokollen, aber Varianten davon. Also ich will jetzt nicht sagen, dass nach Quic jemand was ganz anders macht.
Aber man kann eine Quic-Variante in diese oder eine Erweiterung in eine andere Richtung machen. Nicht nur vom Protokoll und von der Implementierung her. Typischerweise ist auf einem Host ein TCP-Stack vorhanden, als Teil des Betriebssystems. Bei Quic kann jede Anwendung ihren eigenen Transportstack mitbringen. Das heißt, die eine kann daraufhin optimieren, die andere dahin.
Mann kann also Quic für Media machen oder Quic für DNS.
Michael Scharf: Eines sollte man noch anmerken. Wir betrachten immer standardisierte Protokolle. Die Konkurrenz sind immer auch proprietäre Verfahren. Quic-Varianten können also auch solche proprietären Protokolle ersetzen. Was sich aus meiner Sicht in jüngster Zeit geändert hat, ist, dass wir mehr standardisierte Protokolle zur Auswahl haben. Die aufwändige Entwicklung eigener, nicht standardisierter Protokolle wird auch angesichts der Kosten vielleicht schwerer zu rechtfertigen sein. Warum einen großen Entwicklungsaufwand in Kauf nehmen, wenn fertige, getestete und robuste Open Source-Protokolle zur Verfügung stehen. Natürlich kann man auf der Basis der Protokolle auch proprietäre Anwendungen fahren. Aber was vielleicht weniger passieren wird, ist, dass jemand eine rein proprietäre Staukontrolle auf einem UDP-basierten Protokoll entwickeln wird – und das gab es in der Vergangenheit immer mal wieder.
Das wäre positiv?
Michael Scharf: Das ist ein positiver Effekt, denn wir müssen berücksichtigen, die Algorithmen sind komplex. Das im ersten Anlauf richtigzumachen, ist nicht leicht. Wenn jemand für einen speziellen Anwendungsfall ein proprietäres Anwendungsprotokoll entwickeln will, hätte der vielleicht etwas Eigenes gemacht. Jetzt hat er mit Quic ein sehr mächtiges, standardisiertes Protokoll mit vielen Features. Man darf also nicht nur schauen wie viel Verkehr geht von TCP auf Quic, das wird passieren. Wir sollten auch beobachten, wie viele Dinge wechseln von einem proprietären Verfahren auf eine Transportschicht, die standardisiert und gut getestet ist.
Dominante Player
Ist die Dominanz der großen Firmen ein Trend?
Michael Scharf: Ich würde hier nicht nur auf die großen Firmen im Web abstellen. Wir sollten nicht nur auf Google und andere große Firmen blicken. Es gibt immer einzelne Bereiche, wo große Player ihre Marktmacht durchdrücken können. Aber es gibt auch Bereiche, Kommunikationsnetze etwa, wo ganz andere Firmen eine Markt-beherrschende Stellung haben. Und auch da wurden in der Vergangenheit immer wieder proprietäre Protokolle eingesetzt. Meist funktioniert das, aber oft musste in der Protokollentwicklung mehrfach nachregelt werden. Und dadurch, dass der Zoo an Protokollen größer wird, haben wir die Chance, dass auch die Use-Cases dieser Player abgedeckt werden. Es wäre gut, wenn neue Use-Cases auch abgedeckt werden von dem, was wir haben.
Michael Tüxen: Bei den Protokollmechanismen stimme ich dir zu. Wenn die Protokolle von zwei unterschiedlichen Anbietern kommen, müssen die interoperabel sein. Da muss man standardisieren. Bei Staukontrolle müssen sie aber nicht unbedingt standardisieren – wenn man da BBR und Google anschaut. Da ist keine Standardisierung da. Sondern da entwickelt eine Gruppe für ihre Use-Cases. Man ist dann immerhin so nett und gibt gewisse Stände in die IETF. Aber das müssten sie nicht. Die könnten auch agieren, ohne das zu tun. Welchen Benefit jemand hat, der seine Staukontrolle zur IETF bringt, ist nicht immer ganz klar.
EU-Kommission wünscht mehr Standards made in .eu
Die EU-Kommission möchte gerne, dass Europa stärker in der Standardisierung aktiv ist. Da ist die Rede von europäischen Werten in der Standardisierung. Allerdings stehen in den entsprechenden Dokumenten der EU in der Regel die ITU und ETSI. Die IETF aber nicht. Was kann die EU unterstützend leisten, vielleicht auch im Sinne von Mittelständlern?
Michael Scharf: Die IETF hat keine gute Lobby in der Politik. Da unterscheidet sie sich von anderen Standardisierungsorganisation. Zum Teil liegt das einfach an der Struktur der IETF. Hier tragen individuelle Entwickler bei. Andere SDO bestehen aus Firmenkonsortien, die auch mit einer bestimmten Lobbyarbeit auf die Politik zugehen.
Ich bin immer ein wenig vorsichtig, wenn die Politik in Europa sagt, wir müssen jetzt mehr Standardisierung machen. Das hat sie in den vergangenen 10 Jahren immer wieder versucht, auch mit großen Forschungsprogrammen. Meiner Beobachtung nach funktioniert Standardisierung nicht isoliert. Es hilft Europa wenig, wenn man sagt, wir schicken jetzt einfach mal 100 Standardisierer los. Die Industrie, die Use-Cases und die Anwender müssen da sein und die Wertschöpfung. Standards sind ein Teil dieses Ganzen. Was wir natürlich gesehen haben, Europa hat in den vergangenen 10 bis 20 Jahren die Telekom- und Internet-Branche vernachlässigt. Da kommt der Niedergang der europäischen Telekommunikationsindustrie her. Das dreht sich jetzt vielleicht ein bisschen. Man muss sich mehr darauf besinnen, wer Geräte herstellt. Da könnte sich wieder etwas verändern.
Michael Tüxen: Gerade beim IETF, wenn man das als Fokus hat, ist für die Standardisierung sehr wichtig, dass man auch eine Implementierung hat. Zumindest prototypischer Art. Noch besser wäre aber ein Deployment in was auch immer für einen Bereich. Im Transportbereich ist die Zusammenarbeit mit Mittelständlern eher schwierig. Eine eigene Transportmodifikation ist für sie nicht interessant. Aber gerade diese Implementierungsnähe – die das IETF hat im Gegensatz zu anderen Standardisierungsgremien –, macht das etwas schwieriger im Forschungsbereich, weil da praktische Implementierungen nicht so gefragt sind. Da geht es eher um Forschungsergebnisse.
Interessiert sich die aktuellen Studierendengenerationen überhaupt noch für IETF und Protokollstandardisierung? Oder gibt es wegen des geringen Industrie-Interesses auch keine Nachfrage von Studierenden. Oder sind Sie, Entschuldigung, fast schon historische Relikte einer Zeit, als es Siemens und Alcatel-SEL gab?
Michael Tüxen: Mein Industrie-Hintergrund ist ja Telefonsignalisierung über IP und das mache ich weder in der Lehre noch bei Abschlussarbeiten. Ich orientiere mich eher daran, was beim IETF aktuell gemacht wird. Dann habe ich vielleicht nicht unbedingt einen Mittelständler als Ansprechpartner, aber für Abschlussarbeiten muss das auch nicht sein. Es gibt auch durchaus Studierende, die sich dafür interessieren. Die sind nicht durch einen Industriepartner motiviert, sondern durch den Inhalt. Und da ist die IETF-Nähe gut, weil man mal einen Draft ausprobieren kann. Für ITU und ETSI kann ich mir das weniger vorstellen. Bei diesen Gremien war ich zu Siemenszeiten noch aktiv. Das ist zu langwierig.
Michael Scharf: Man kann durchaus Studierende gewinnen für solche Themen. Im letzten Jahr haben Studierende der Hochschule Esslingen eine prototypische Implementierung einer neuen Spezifikation der TCPM Arbeitsgruppe entwickelt. Das sind auch gute, weil aktuelle Themen. In meinem Fall sind das auch keine rein akademischen Arbeiten. In Stuttgart haben wir vielleicht keine Telekommunikationsindustrie, aber sehr viel Maschinenbau und Automobilindustrie. Außerdem werden die ganzen Techniken für viele Branchen, die einen ganz anderen Hintergrund haben, immer wichtiger. Da kommen neue Anwendungsfälle her, für unseren jüngsten Prototyp war es die Automobilindustrie.
Die Internettechniken und Protokolle werden immer relevanter in Gebieten, für die sie nicht entworfen wurden. Das sind Industrieanlagen und die Automobilindustrie. Oft ist die IETF in den entsprechenden Kreisen nicht bekannt. Aber mit der Digitalisierung werden Protokolle, aber auch die IETF wieder relevant werden. Es ist noch etwas früh, weil sowohl Techniken als auch Unternehmen sind teils noch nicht ganz so weit. Aber das kommt mehr und mehr und in diesen Bereichen hat Deutschland teilweise auch Marktführer.
Wenn, dann sollte man die Zusammenarbeit zwischen Forschung und Industrie fördern?
Michael Scharf: Förderung ist immer sinnvoll. Ich bleibe aber dabei, eine Förderung allein der Hochschulen ist wenig sinnvoll. Da müssten Kollaborationen mit der Industrie gefördert werden. Ich würde dabei nicht nur auf klassische Kommunikationstechnik und Router-Hersteller schauen, sondern auf die Industrie, die wir haben in Deutschland und für die das Internet noch viel relevanter werden wird. Anders als in der Telekom-Industrie, wo man die Marktführerschaft vor 15 Jahren aufgegeben hat, gibt es in anderen Branchen in Deutschland durchaus Marktführer.
Was macht Sinn zu fördern, was wäre Gießkanne?
Michael Tüxen: Ich halte es für sinnvoll zu schauen, wo sind Use-Cases und wo sind Industriepartner, die das deployen könnten. Es wäre auch gut, wenn das dann nicht nur ein proprietäres Produkt wäre, sondern wenn ein generelles Problem gelöst werden könnte.
Herr Scharf, Herr Tüxen, vielen Dank für das Gespräch.
(bme)
