Seite 3: Lebenszyklen von Protokollen

Inhaltsverzeichnis

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.