IETF 87: Viele Wege führen nach Rom – dank Multipath-TCP

Wenn die Arbeiten in der IETF mptcp-Arbeitsgruppe weiterhin so vielversprechend vorangehen, dann werden die User bald nahtlos während eines Downloads den physischen Übertragungsweg zum Host wechseln können, ohne dabei die End-to-End-Konnektivität zu verlieren. Das jedenfalls schwebt den Schöpfern des Multipath-TCP-Protokolls vor (MPTCP) .

MPTCP ist ein Verfahren, bei dem Hosts die Datenpakete innerhalb einer TCP-Session über mehr als einen Weg leiten können, indem sie zum Beispiel parallel zu einer 3G-Verbindung einen WLAN-Zugang ins Internet nutzen. Dabei merkt der Nutzer gar nicht, auf welchem der beiden Wege die Datenpakete seinen Browser erreichen. Das wäre noch kein Gewinn. Aber im Idealfall addieren sich die Bandbreiten der Leitungen, sodass beispielsweise Downloads schneller werden. Zudem wird die Übertragung robuster, weil Störungen oder der Ausfall eines Übertragungswegs nicht gleich zum Zusammenbruch von Sessions führen. Entsprechend konfiguriert, lässt sich das Verfahren aber auch zur Laststeuerung verwenden, indem im Falle von Lastspitzen oder Staus der Verkehr über einen anderen Pfad geleitet wird.

Manche dieser Funktionen bringen zwar Multi-WAN-Router von Haus aus mit, aber die einfacheren können WAN-Leitungen nicht für eine TCP-Session zusammenfassen und die aufwändigeren schaffen das nur über eine Vermittlungseinheit im Internet, die die Pakete zusammenfasst und wieder als eine TCP-Session zum eigentlichen Ziel weitergibt.

Das MPTCP-Konzept klingt einfach; der Teufel steckt jedoch im Detail. "Wegen der vielen Middleboxes ist das Protokoll komplexer als ursprünglich gedacht", erklärt Olivier Bonaventure, Professor an der Katholischen Universität Löwen und einer der führenden Köpfe hinter der Entwicklung. Middleboxes [-] das sind die "Kisten" in den Weiten des Netzes, die das Internet intransparent machen. Dazu gehören neben Firewalls die Geräte mit Network Address Translation (NAT), die zur Überwindung der Knappheit an IPv4-Adressen globale IP-Adressen mehrfach auf lokale IP-Adressen abbilden und dazu die Portnummern in den TCP-Headern heranziehen, um sie einzelnen lokalen Hosts für die jeweilige Session zuzuordnen.

Inzwischen gibt es "fast so viele Middleboxen wie Router" im Netz, meint Bonaventure unter Verweis auf einschlägige Studien. Sobald aber Middleboxen die TCP-Header verändern, wird es schwierig, den sie tun das aus Host-Sicht auf undurchschaubare Art. Die größten Probleme bereitete es daher, Hosts in die Lage zu versetzen, eine in mehrere TCP-Sessions aufgeteilte wieder als eine zu behandeln und Kennungen sowie Parameter zu definieren, die auf dem Weg durch die Netze unverändert bleiben.

Das ist in der Working Group gelungen. Sie verwendet das Options-Feld, um alle Steuerungsinfos für das Handshaking und zur Identifizierung der Teildatenströme zu übermitteln. Untersuchungen zufolge übersteht das Options-Feld bei rund 9 von 10 TCP-Sitzungen den Weg durchs Netz unbeschadet. Und in den 10 Prozent, wo die Multipath-Steuerdaten abhanden kommen, bleibt immer noch der Rückfall in das reguläre TCP mit dem Singlepath-Modus.

RFC 6824 "TCP Extensions for Multipath Operation with Multiple Addresses" befindet sich im Experimentierstatus und es gibt mehrere Testimplementierungen. Erst kürzlich konnte das Team in Löwen, wie Bonaventure in Berlin berichtete, eine Multipath-TCP-Verbindung mit einer Gesamtkapazität von 52 GBit/s zwischen zwei Hosts demonstrieren. Beide Hosts nutzten je sechs 10-GBit/s-Ethernetkarten zugleich (im Text ist den Autoren ein Fehlerchen unterlaufen, die Grafik stellt den Aufbau korrekt dar). "Für die Anwendung sieht es wie eine reguläre TCP-Session aus", erklärte sein Mitarbeiter Christoph Paasch, der eine Linux Kernel-Implementierung des stabilen MPTCP v0.87-Release vermeldete.

Nigel Williams vom Center for Advanced Internet Architectures (CAIA) der australischen Swinburne University of Technology berichtete von der Alpha-Version einer FreeBSD-Implementierung, die man im Projekt für robuste Fahrzeug/Infrastruktur-Verbindungen (V2I) einsetzen wolle. Jetzt sucht er Tester und Feedback. Und Working Group Chair Philip Eardley meint, die Zeit sei reif, den nächsten Schritt ins Auge zu fassen und RFC 6824 "auf die Standardisierungsschiene zu setzen". (dz)