Multipath-TCP auf dem Sprung zum Standard

Inhaltsverzeichnis

Olivier Bonaventure ist Professor für Computer Science an der Katholischen Universität Löwen (Belgien). Als Mitverfasser des RFC 6824 "TCP Extensions for Multipath Operation with Multiple Addresses" gehört er mit seinem Team am IP Networking Lab (INL) zu den treibenden Kräften der Multipath-TCP-Entwicklung. heisenetze sprach mit ihm über Stand und Perspektiven des Projektes. Ein umfassender Artikel über die rafinierte Funktionsweise der Technik erschien in c't in der aktuellen Ausgabe 6/2014 (kostenpflichtiger Beitrag).

heisenetze: Wo steht Multipath-TCP zur Zeit?

Bonaventure: In der IETF haben wir den experimentellen RFC 6824 eingebracht und der nächste Schritt besteht darin, ihn auf die Standardisierungsschiene zu setzen. Dazu müssen wir noch klären, wie man die Basis-Sicherheitsmechanismen der jetzigen Experimentalversion am besten verstärken kann.

heisenetze: Wie viele Implementierungen gibt es bereits?

Bonaventure: In der IETF Working Group sind drei Implementierungen diskutiert worden: Eine von Citrix mit dem NetScaler Load Balancer, unsere Implementierung im Linux-Kernel, und eine Implementierung, von der sich herausstellte, dass sie von Apple kam. Daneben gibt es noch eine teilweise Implementierung mit FreeBSD aus Australien. Apple hat Multipath-TCP mit iOS 7 eingeführt. Sie verwenden es anscheinend für Siri, die Spracherkennungs-Anwendung von Apple.

heisenetze: Ist die Implementierung kompatibel, sodass sie auch mit jedem anderen Multipath-TCP-Server außerhalb von Apples Walled Garden verwendbar wäre?

Bonaventure: Apple legt die Socket API der Multipath-TCP-Implementierung nicht offen, sodass jemand, der eine App für iOS 7 schreiben will, Multipath-TCP nicht verwenden kann. Es gibt Anzeichen, dass sich das ändert, aber zur Zeit scheinen nur interne Apple-Anwendungen Multipath-TCP nutzen zu können. Aus den Diskussionen, die wir mit Apple hatten, sind wir jedoch ziemlich sicher, dass Apples Implementierung mit der unseren kompatibel ist.

heisenetze: Auf welche Weise können interessierte User die Vorteile und Leistungsfähigkeit des Protokolls austesten?

Bonaventure: Wir haben auf www.multipath-tcp.org Ubuntu Images des Kernels und stellen fest, dass die Leute die Ubuntu- und Debian-Pakete herunterladen, mit ihnen Tests durchführen und manche auf virtuellen Maschinen aufsetzen. Wir haben eine ältere Version, die auf einem Samsung Galaxy S2 läuft und der jüngste Kernel läuft auf dem Google Nexus 5 Smartphone - was den Vorteil hat, dass damit Kernel-Updates leichter hinzukriegen sind als bei anderen Smartphones.

heisenetze: Baut sich da schon eine Community von Anwendern auf?

Bonaventure: Es gibt etwa 250 Teilnehmer auf der Mailing-Liste für Entwickler, die meisten davon sind aktiv und sieben oder acht Websites haben Multipath-TCP aktiviert. Auf unserer Website Multipath-TCP.org sind sie aufgeführt.

Bei uns im Lab haben wir Multipath-TCP auf einem ssh-Server aktiviert, den Studenten und Mitarbeiter nutzen. Wenn sie sich mit ssh einloggen, machen sie das über Multipath-TCP. Das hat den Vorteil, dass die ssh-Verbindungen offen leiben, wenn man vom WLAN ins Ethernet wechselt oder sich von einem Raum in den anderen begibt und die Geräte dabei neue IP-Adressen erhalten. Das ist schon recht nützlich.

Lange Vorgeschichte

heisenetze: Historisch scheint so etwas wie Multipath-TCP erstmals 1999 in einer US-amerikanischen Dissertation zum Multipath-Routing erwähnt worden zu sein. Den Auftakt in der IETF bildete eine Birth-of-Feather-Sitzung 2009, zehn Jahre später. Warum dauerte es so lange, bis der Gedanke Gestalt annahm?

Bonaventure: Sogar schon früher, 1995, hatte Christian Huitema in der IETF vorgeschlagen, TCP so zu erweitern, dass mehrere Adressen parallel für dieselbe Verbindung verwendet werden können; er nannte das multi-homed TCP. Aber die IETF ist ziemlich langsam und Anfang 2000 wurden neue Eigenschaften der Transportschicht hauptsächlich im Zusammenhang mit dem Stream Control Transmission Protocol (SCTP) statt für TCP diskutiert.

heisenetze: SCTP sollte ähnliche Funktionen ermöglichen, wie sie Multipath-TCP nun bereitstellt. Warum war SCTP nicht erfolgreich?

Bonaventure: Ich glaube, das hat zwei Ursachen. Erstens entschied man sich bei SCTP aus vielen guten Gründen, Anwendungen eine Alternative zu TCP anzubieten - es gibt die Möglichkeit zum Streaming, zur verbindungslosen, nichtzuverlässigen Übertragung, und so weiter. Deshalb musste SCTP eine andere API bereitstellen, was zur Folge hat, dass Anwendungen, die SCTP nutzen sollen, eigens angepasst werden müssen. Das ist bei Multipath-TCP heute nicht der Fall.

Der zweite Grund ist, dass SCTP - das die Neuentwicklung eines Transportprotokolls auf saubere Art angeht - eine andere Protokollnummer auf dem IP-Layer verwendet, damit ein Empfänger feststellen kann, dass ein IP-Paket ein SCTP-Segment enthält.

Dummerweise gibt es im Internet verschiedene Arten von Middleboxen - Firewalls, NATs und solche Dinge. Und sehr oft, wenn eine Middlebox ein Paket sieht, das sie nicht versteht, wird sie das Paket verwerfen. Viele Middleboxen verstehen nur TCP und UDP. Wenn man deshalb bei den meisten NATs, die die Leute zu Hause haben, nicht mit TCP oder UDP über IP kommt, wird man vom NAT blockiert, weil der kein SCTP versteht und keine Portumsetzung für SCTP macht. Erst seit kurzem gibt es einen Draft, der erklärt, wie man die Portumsetzung bei SCTP hinbekommt.

Das Ergebnis war so etwas wie ein Teufelskreis: Das Protokoll ist sauber und ordentlich, aber man braucht eine andere API, wenn man es verwenden will. Und Entwickler wissen, dass viele Middleboxen es dummerweise nicht unterstützen. Sie wagen nicht, es einzusetzen, weil ihre Anwendung eventuell nicht in der Lage ist, sich durch das Netz zu verbinden. Wenn umgekehrt nur wenige Anwendungen das Protokoll nutzen, dann gibt es keinen Anreiz für die Entwickler von Middleboxen, ihre Geräte so zu überarbeiten, dass sie SCTP unterstützen. Und ohne Unterstützung in den Middleboxen wird niemand die Anwendungen entwickeln oder migrieren.

MPTCP-bewusste Middleboxen

heisenetze: Multipath-TCP ist gezielt so entwickelt worden, dass die notwendigen Signalisierungsinformationen auf ihrem Weg möglichst unbeschadet die Passage durch Middleboxen überleben, gleichwohl ist die Rede von "MPTCP-bewussten Middleboxen". Was ist darunter zu verstehen?

Bonaventure: Die Idee ist, dass man Middleboxen im Netz hat, die Multipath-TCP verstehen und darauf basierend zusätzliche Dienste oder Features bereitstellen. Es gab dazu einige Diskussionen in der IETF und unsere Gruppe hat Mitte Dezember zwei Paper zum Thema auf der ACM CoNEXT'13 Konferenz in Santa Barbara präsentiert.

Eines der vorgestellten Beispiele ist ein Multipath-TCP Protokollkonverter. Das ist eine Middlebox, die auf einer Seite Multipath-TCP mit dem Client spricht, etwa einem Smartphone und zum Server auf der anderen Seite normales TCP verwendet. Mit diesem Protokollkonverter kann man Multipath-TCP auf dem Smartphone aktivieren und für das sogenannte Mobile Data Offloading verwenden, das heisst, wenn gleichzeitig WLAN und 3G (oder 4G alias LTE) verfügbar sind, könnte der Verkehr über das WLAN und den Mobilfunk zum Konverter gehen, wo die Umwandlung in normales TCP stattfindet, um den Webserver zu erreichen, mit dem man interagiert.

Das könnte für Netzbetreiber und Nutzer ein interessanter Ansatz sein, schnell in den Genuss der Vorteile von Multipath-TCP im Zugangsnetz zu kommen und nicht erst warten zu müssen, bis alle Content Distribution Networks und alle Inhalteanbieter ihre Server auf Multipath-TCP umgestellt haben.

heisenetze: Alle Middleboxen nachzurüsten, scheint ein recht schwieriger Prozess zu sein, der lange braucht, um wirksam zu werden.

Bonaventure: Ja, aber diese Middlebox kann neue Dienste anbieten und wir sehen das Interesse bei den Mobilfunkbetreibern. Viele 3G- und 4G-Betreiber möchten Verkehr vom Mobilnetz in WLANs verlagern, die unter ihrer Hoheit stehen. Ein typisches Beispiel in Europa sind die Betreiber, die Fon eingeführt haben, um Millionen von WLAN-Hotspots einzurichten; die können sie nun nutzen, um den Verkehr ihrer Kunden zu verlagern.

IPv4 und IPv6

heisenetze: Die IPv4-Optionen eignen sich nicht dazu, dem Zielhost eine Multipath-TCP-Anforderung zu signalisieren, weil die meisten Router im Internet Pakete mit Optionen im Header schlicht verwerfen. Wie ist das mit IPv6? Wäre das Internet transparenter für IPv6-Pakete mit einem erweiterten Header, der die Signalisierungsinformation übermittelt?

Bonaventure: Da muss man Theorie und Praxis unterscheiden. Theoretisch wären wir in der Lage, einige Multipath-TCP-Informationen an IPv6-Optionen zu übergeben, die von der Größe her keiner Beschränkung unterliegen. Das würde zwar das Prinzp der Protokollschichten durchbrechen, aber das wäre ja nicht das erste Mal, dass wir gegen das Layering-Prinzip verstoßen.

Aber das Problem sind wieder die Middleboxen im Netz, die Pakete mit unbekannten Optionen verwerfen würden; bei vielen Firewalls ist das die Grundeinstellung. Der Punkt ist, dass viele Geräte ein empfangenes Paket ohne Optionen effizienter mit der Hardware verarbeiten können, während ein Paket mit Optionen sehr oft von der Software verarbeitet werden muss, was nicht so effizient ist.

In der IETF gibt es momentan Diskussionen darüber, ob man die IPv6-Optionen verwenden kann. Eine der Hauptanwendungen von Optionen in IPv6 ist die Unterstützung der Fragmentierung von Paketen. Da wurde kürzlich von den RIPE Labs ein Test durchgeführt, ob die IPv6-Fragmentierung korrekt über das Internet funktioniert. Das Ergebnis war, dass auf ungefähr 10 Prozent der getesteten Pfade die IPv6-Fragmentierung nicht einwandfrei funktioniert. Das zeigt, dass die Erweiterungsheader nicht immer unbeschadet überleben.

heisenetze: Das Problem ist also im Grunde dasselbe wie bei IPv4?

Bonaventure: Leider, ja.

heisenetze: Aber Multipath-TCP läuft genauso über IPv6 wie über IPv4?

Bonaventure: Ja, es ist völlig blind gegenüber der darunterliegenden Netzwerkschicht. Es funktioniert mit beiden.

Anwendungsbewusst

heisenetze: Multipath-TCP muss unabhängig von jeder Anwendung auf der Transportschicht konfiguriert werden. Das heisst, die Entscheidung, welche Netzschnittstelle genutzt werden soll, fällt auf dem Transport-Layer und nicht durch die jeweilige Anwendung?

Bonaventure: Zur Zeit, ja, weil die Multipath-TCP-Implementierung die reguläre Socket API anbietet. In der IETF-Spezifikation gibt es jedoch eine API, die einer Anwendung die Steuerung von Multipath-TCP erlauben sollte, aber das ist noch nicht implementiert worden. Langfristig sollte es daher eine API geben, die Anwendungen eine bessere Kontrolle von Multipath-TCP ermöglicht. Dafür brauchen wir jedoch etwas Feedback von Anwendungsentwicklern, um herauszufinden, was ihnen vorschwebt oder was sie brauchen.

heisenetze: Sind bereits Nutzungsszenarien absehbar, wo das von Vorteil wäre?

Bonaventure: Es gibt einige einfache Einsatzfälle. Zum Beispiel ein Smartphone, das für ein Update große Dateien herunterlädt; da könnte die Anwendung dann sagen, dafür möchte ich nicht 3G, sondern nur das WLAN nutzen. Das wäre ein API-Aufruf, der von der Anwendung kommen könnte.

Man könnte auch an eine Anwendung denken, wo man die Konnektivität aufrechterhalten möchte, aber nur selten Pakete abschickt, wie zum Beispiel bei einem Chat. Da könnte man sagen, Ich will immer 3G nutzen und nicht WLAN.

Andere Anwendungen wollen vielleicht beides, indem sie die Auswahl zwischen WLAN und 3G beeinflussen, etwa den Verkehrsanteil der einen Schnittstelle im Verhältnis zu der anderen. Die Entscheidung, ob beide Schnittstellen aktiv sein sollen, oder nur eine aktiv ist, während die andere passiv mitläuft oder die zweite erst beim Ausfall der ersten aktiviert wird, könnte von der Anwendung getroffen werden.

Momentan ist alles offen. Wir werden sehen, was den Anwendungsentwicklern vorschwebt.

heisenetze: Ganz allgemein wird es für Endnutzer neben dem gewöhnlichen, nicht-priorisierten Zugang zu einer bestimmten Website immer öfter eine schnelle, priorisierte Spur geben. Mit Multipath-TCP könnte also die Anwendung zwischen dem schnellen Netzzugang und dem gewöhnlichen umschalten, je nachdem, welche Verbindung den besseren Mehrwert fürs Geld bietet?

Bonaventure: Ja, das ist möglich. Nehmen Sie zum Beispiel an, dass ein Netzbetreiber 3G- und WLAN-Dienste anbietet. Da hat man WLAN als sehr billigen Dienst, und 3G bliebe im passiven oder im Backup-Modus, sodass man auf 3G nur zur Fortsetzung laufender Verbindungen umsteigt, wenn das WLAN-Signal wegfällt.

Man kann sich auch einen Dienst für Geschäftskunden vorstellen, bei dem WLAN und 3G immer beide aktiv sind und Multipath-TCP dazu dient, aus beiden die beste Leistung herauszuholen. Wenn etwa ein WLAN Access Point nur über eine langsame DSL-Leitung mit dem Internet verbunden ist, könnte die Anwendung automatisch 3G zuschalten. Im Labor funktioniert das schon. Wenn beides verfügbar ist, WLAN und 3G, misst unsere Implementierung immer die Round-Trip-Time sowie die Stausituation auf jedem Pfad und kann auf dieser Grundlage entscheiden.

heisenetze: Ist es nicht so, dass die Betreiber den WLAN-Teil solch eines Zweifach-Zugangs gar nicht mögen, weil ihnen der kein Geld bringt?

Bonaventure: WLAN mag ihnen vielleicht kein Geld bringen, aber sie sparen Geld, weil sie die teuren 3G/4G-Netze entlasten können, die sich nicht so einfach erweitern lassen wie die lizenzfreien WLANs.

Es gibt Prognosen, dass in England die 4G-Netze im Jahr 2020 verstopft sein werden. Angesichts des Wachstums videobasierter Dienste erwarten viele Betreiber, dass sie der Belastung nicht mehr gewachsen sein werden und 3G und 4G nicht schnell genug ausbauen können, um mit der steigenden Netzlast durch Smartphones und Tablets mitzuhalten. Deshalb wollen sie den Verkehr auf WLANs umleiten.

Jeder Verkehr, den sie an WLANs abgeben können, verringert daher den Investitionsaufwand, den CAPEX, in ihre 3G- oder 4G-Netze.

Home-Gateway mit MPTCP

heisenetze: Lässt sich Multipath-TCP auch daheim, auf Verbindungen vom Home Gateway zu einzelnen Endgeräten wie Smart-TVs, Tablets und Smartphones, verwenden?

Bonaventure: Ein möglicher Einsatzfall wäre ein Home Gateway, das zwei WLAN-Schnittstellen verwendet, zum Beispiel eine mit 2,4 GHz und eine mit 5 GHz und ein Tablet beide Schnittstellen nutzt und Multipath-TCP auf beiden WLAN-Netzen gleichzeitig läuft.

Ein anderer Einsatzfall hängt mit dem Protokollkonverter zusammen, den ich vorhin erwähnte. Das wäre ein Home Gateway mit zwei Netzzugängen, die Multipath-TCP bündelt. Einer könnte ADSL sein, der andere Kabel oder 4G. Auf der Heimnetz-Seite operiert es mit regulärem TCP.

Wir haben einen Multipath-TCP-Demonstrator für ein Home Gateway mit Linux. ADSL liefert eine schwache Anbindung mit 10 und 1 MBit/s im Down- und Uplink. Dann verbinden wir ein Smartphone über USB mit diesem Home Gateway, wobei das Smartphone als LTE-Modem arbeitet. Das Home Gateway kombiniert die beiden Netzzugänge und mit ADSL/4G zusammen erreichen wir 54 MBit/s im Downlink und bis zu 10 MBit/s im Uplink.

Das ist ein Use Case, den wir mit Betreibern diskutieren, weil er den Endnutzern - zum Beispiel Telearbeitern - mehr Kapazität bringt. Wenn man zuhause arbeitet, braucht man manchmal mehr Kapazität zum Hochladen und da leistet das Smartphone als 4G-Modem gute Dienste. Sobald man das Haus verlässt, nimmt man das Smartphone mit und Multipath-TCP wird auf dem Home Gateway deaktiviert. Bei uns im Lab funktioniert das schon.

Ist das Internet verkalkt?

heisenetze: Nach der Erfahrung mit der überaus komplexen Entwicklung des MPTCP-Protokolls - wie schätzen Sie die Zukunft des Internet ein? Viele glauben, dass es "verknöchert" ist und dass es immer schwieriger wird, neue Funktionen hinzuzufügen. Glauben Sie, dass das Internet seine Hoch-Zeit bereits hinter sich gelassen hat und sich jetzt auf einem Pfad schrumpfender Möglichkeiten befindet?

Bonaventure: Da bin ich optimistischer als ich es noch vor einigen Jahren war. Wir haben endlich IPv6 so weit gebracht, dass es eingesetzt wird. Das hat viele Jahre gedauert, vielleicht zuviele, aber endlich wird es genutzt. Über die Jahre ist die Umstellung gelungen. Die Einführung eines neuen Netzprotokolls ist also möglich.

Auf der Transportschicht haben wir mit Multipath-TCP gezeigt, dass - obwohl es schwierig ist - größere Veränderungen der Transport Layer zu bewerkstelligen sind. Wie bei der Umstellung auf IPv6 liegt auch hier das Kernproblem der Einführung eines neuen Protokolls darin, unter Beibehaltung der Konnektivität die Einführung schrittweise angehen zu können.

Also, ich glaube, das Internet wird sich weiterhin entwickeln. Da gibt es unterschiedliche Richtungen und angesichts der Größe des Internet wird die Entwicklung ziemlich langsam sein, aber sie passiert.
(dz)