Multipath-TCP auf dem Sprung zum Standard
Seite 5: 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.
