Seite 2: Transportprotokolle zuhauf

Inhaltsverzeichnis

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.