Die Zukunft von TCP hat begonnen

Kommentieren Drucken

Die Belgier haben es und Apple kann es auch: MPTCP.

Überall scheint sich die IT-Welt weiter zu entwickeln, so auch im Netzwerk. Ethernet wurde immer schneller; aus dem Spanning Tree wurde über Zwischenstationen TRILL und SPB; selbst der Dinosaurier IPv4 wankt und weicht langsam der Version 6. TCP scheint das alles nicht zu berühren. Und doch passiert dort gerade etwas wirklich Spannendes: Multipath TCP, kurz MPTCP.

Der Ausgangspunkt für die Entwicklung ist die Tatsache, dass immer mehr Geräte über mehr als ein Interface verfügen. Gemeint sind jetzt nicht Server, die im Bedarfsfall durchaus ein Bonding von Interfacekarten kennen. Gemeint sind Smartphones, Tabletts mit UMTS/LTE und WLAN Interfaces oder auch Laptops mit Ethernet, WLAN und UMTS/LTE. Genutzt wird jedoch immer nur ein Interface pro Verbindung. Grund ist, dass eine klassische TCP Session immer an eine einzelne IP Adresse gebunden ist und eine IP Adresse wiederum an ein Interface.

Das bringt insbesondere zwei Nachteile mit sich:

  1. Ausfallsicherheit
    Verlässt beispielsweise ein Smartphone während eines Downloads den WLAN Bereich, ist entweder der Download vorbei oder die Applikation muss über einen (komplexen) Mechanismen verfügen, den Download über eine neu aufgebaute TCP Sitzung fortsetzen können.
  2. Bandbreite
    In Zeiten von LTE und Flatrates stellt sich auch die Frage, warum es z.B. auf einem Tablett keinen kombinierten Download über LTE und WLAN gibt. Wenn ich beispielsweise einen iTunes Film in HD Qualität herunterladen möchte, muss ich mir das rechtzeitig überlegen, sonst wird es zu spät, weil der Download zu lange dauert. Könnte ich beide Wege (LTE und WLAN) kombinieren, wäre der Download signifikant schneller.

Die Idee hinter Multipath TCP ist nun, mehrere TCP Sessions über verschiedene Interface und IP Adressen so zu bündeln, dass sie aus Applikationssicht wie eine einzige aussehen. Abbildung 1 zeigt das um MPTCP erweiterte DoD Modell.

Das klingt auf den ersten Blick sehr charmant. Aber so ohne ist das nicht. Es gibt eine ganze Reihe von Problemen zu lösen, bevor ein Stack entwickelt werden kann, der sich nahtlos in die heutige TCP/IP Welt einfügt.

Kompatibilität: Host-to-Host
MPTCP wird nicht über Nacht ausgerollt werden. Es werden also Geräte mit und ohne MPTCP-Fähigkeit miteinander kommunizieren. Damit das funktioniert, muss das klassische TCP als Fallback existieren. Streng genommen muss MPTCP sogar erst „nachträglich“ bei Bedarf zugeschaltet werden (vgl. Abbildung 2). So wird sichergestellt, dass TCP immer funktioniert und ein „alter“ Host nicht durch ein „neues“ Protokoll verwirrt wird.

Ein weiterer Fall, der auftreten kann, ist, dass ein Host über ein (sehr schnelles) Interface verfügt, wohingegen der andere Kommunikationspartner zwei (langsamere) Interfaces hat. In der Tat ist damit zu rechnen, dass dieser Fall oft vorkommt: Server mit 10/40/100 Gigabit Ethernet und Client mit WLAN+LTE. In solchen Fällen macht es Sinn, wenn der Client beide Interfaces nutzt, auch wenn der Server nur eines hat (vgl. Abbildung 3).

Kompatibilität: Software / Austausch weiterer IP-Adressen
So schön unabhängig die Schichten des DoD- oder ISO-Modelles auch auf den ersten Blick aussehen, sie sind es leider nicht. Fakt ist, dass die Anwendung die IP Adresse vorgibt, mit der sie kommunizieren will und nicht der Session Layer (TCP) sich eine passende raussucht.

Eine Anwendung, die keine Ahnung von MPTCP hat, wird aber immer nur eine IP-Adresse auswählen, auch wenn sie per DNS mehrere Adressen erfährt.

MPTCP muss also die Fähigkeit beinhalten, weitere Adressen auszutauschen, wenn mehrere Verbindungen aufgebaut werden sollen.
Alternativ kann die Schnittstelle (API) zwischen Application- und Session-Layer erweitert werden, so dass die Anwendung Einfluss auf das Multipathing nehmen kann. Da die Schnittstelle optional genutzt werden kann, bleibt die Kompatibilität gewahrt: kennt eine Anwendung diese API-Erweiterung nicht, wird sie sie nicht nutzen und MPTCP ist frei zu tun, was es will.

NAT/Firewall
Network Address Translation (NAT) ist allgegenwärtig, nicht nur im Enduser Umfeld. Gerade auch Provider müssen immer mehr NAT-Gateways einsetzen. Oft reicht es nicht mal mehr, die Adressen auszutauschen, sondern auch die TCP-Ports müssen geändert werden (NAPT = Network Address and Port Translation). MPTCP muss diesen Fall berücksichtigen: normalerweise wird eine Session an der Portnummer identifiziert. Wenn aber auf einem Weg die Portnummer X genutzt wird und so auch bei dem Empfänger ankommt, während auf einem anderen Weg durch ein NAPT-Gateway aus Port X Port Y wird, reicht allein die Portnummer nicht mehr aus. Eine Verbindungs-ID muss her, die alle Subflows einer TCP-Session zuordnet.

Relevanz von MPTCP
Wahr ist: MPTCP ist noch im Experimentierstadium. Es existieren zwar mehrere RFCs, aber die haben noch den Status „experimental“.
Wahr ist aber auch, dass MPTCP in vielen Jackentaschen schon aktiv ist: seit IOS7 funkt Siri auf MPTCP nach Hause. Auch Kernel-Implementierungen für Linux existieren bspw. von der belgischen „Université Catholique de Louvain“
Netzwerker und insbesondere Troubleshooter sollten sich mit diesem neuen Protokoll auseinander setzen, da es ihr Leben bei der Fehlersuche nicht einfacher machen wird. Aber auch Softwareentwickler sollten sich mit dem neuen API vertraut machen, da sich hier völlig neue Möglichkeiten eröffnen.

Ich glaube, dass bei entsprechender Weiterentwicklung MPTCP sogar das Potential hat, virtuelle Netze, Overlay Techniken und SDN unnötig zu machen. Doch dazu in einem der kommenden Netzwerk Insider und auf dem ComConsult Netzwerkforum 2014 mehr.

zugeordnete Kategorien: IP und IPv6
zugeordnete Tags: ,

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.