Multipath TCP für Linux (2022)

Überblick über Multipath TCP

• Multipath TCP (MPTCP) ist eine Erweiterung des Standard-TCP und in RFC 8684 beschrieben.
• Es ermöglicht Geräten, mehrere Schnittstellen gleichzeitig zu verwenden, um TCP-Pakete über eine einzige MPTCP-Verbindung zu senden und zu empfangen.
• MPTCP kann die Bandbreite mehrerer Schnittstellen bündeln oder die Schnittstelle mit der geringsten Latenz bevorzugen.
• Außerdem ist Failover möglich, selbst wenn ein Pfad ausfällt, und der Datenverkehr wird nahtlos auf andere Pfade umgeleitet.

Anwendungsfälle für MPTCP

• Durch MPTCP können mehrere Pfade parallel oder gleichzeitig genutzt werden, wodurch im Vergleich zu TCP neue Anwendungsfälle entstehen:
  • Seamless handovers: Wechsel von einem Pfad auf einen anderen bei aufrechterhaltener Verbindung. Apple nutzt MPTCP aus diesem Grund seit 2013 vor allem auf Smartphones.
  • Best network selection: Nutzung des „besten“ Pfads anhand bestimmter Kriterien wie Latenz, Verlust, Kosten oder Bandbreite.
  • Network aggregation: Gleichzeitige Nutzung mehrerer Pfade für höheren Durchsatz. Beispiel: Kombination aus Festnetz- und Mobilfunknetz, um Dateien schneller zu übertragen.

MPTCP-Konzepte

• Wenn mit dem Protokoll IPPROTO_MPTCP (nur Linux) ein neuer Socket erzeugt wird, entsteht ein Subflow (oder Pfad), der aus einer normalen TCP-Verbindung besteht und zum Übertragen von Daten über eine einzelne Schnittstelle verwendet wird.
• Zusätzliche Subflows können später zwischen den Hosts ausgehandelt werden.
• Dem TCP-Optionsfeld des primären TCP-Subflows werden neue Felder hinzugefügt, damit der entfernte Host erkennen kann, dass MPTCP verwendet wird.
• Zu diesen Feldern gehört die Option MP_CAPABLE, die dem anderen Host mitteilt, MPTCP zu verwenden, falls es unterstützt wird.
• Wenn der entfernte Host oder eine zwischengeschaltete Middlebox MPTCP nicht unterstützt, enthalten die TCP-Optionen des zurückgegebenen SYN+ACK-Pakets keine MPTCP-Option.
• In diesem Fall wird die Verbindung auf normales TCP „zurückgestuft“ und läuft über einen einzelnen Pfad weiter.

Dieses Verhalten wird durch zwei interne Komponenten ermöglicht: den Path Manager und den Packet Scheduler.

Path Manager

• Der Path Manager ist für Subflows von ihrer Erstellung bis zu ihrer Löschung zuständig und übernimmt auch die Adressankündigung.
• Normalerweise initiiert die Client-Seite die Subflows, während die Server-Seite zusätzliche Adressen über die Optionen ADD_ADDR und REMOVE_ADDR ankündigt.
• Stand Linux v5.19 gibt es zwei Path Manager, die über den Sysctl-Schalter net.mptcp.pm_type gesteuert werden:
  • in-kernel (Typ 0): Wendet dieselben Regeln auf alle Verbindungen an (siehe ip mptcp).
  • userspace (Typ 1): Wird von einem Userspace-Daemon (z. B. mptcpd) gesteuert und kann für jede Verbindung unterschiedliche Regeln anwenden.

Packet Scheduler

• Der Packet Scheduler wählt unter den verfügbaren Subflows denjenigen aus, über den das nächste Datenpaket gesendet werden soll.
• Er kann die Nutzung der verfügbaren Bandbreite maximieren, nur den Pfad mit der geringsten Latenz auswählen oder je nach Konfiguration andere Richtlinien festlegen.
• Stand Linux v6.8 gibt es nur einen Packet Scheduler, der über Sysctl-Schalter unter net.mptcp gesteuert wird.

Wichtige Merkmale von MPTCP (Stand Linux v6.10)

• Unterstützung des Protokolls IPPROTO_MPTCP im Systemaufruf socket()
• Fallback von MPTCP auf TCP, wenn Gegenstelle oder Middlebox MPTCP nicht unterstützen
• Pfadverwaltung mit einem kernelinternen oder Userspace-Path-Manager
• Socket-Optionen, wie sie üblicherweise bei TCP-Sockets verwendet werden
• Debug-Funktionen einschließlich MIB-Zählern, diag-Unterstützung (verwendet im Befehl ss) und Tracepoints

Meinung von GN⁺

• MPTCP ist eine sehr nützliche Technologie, wenn Endgeräte mit mehreren Netzwerken verbunden sind. Sie lässt sich effektiv für 5G-Wi-Fi-Handover oder die Bündelung heterogener Netze einsetzen.
• Allerdings müssen sowohl Server als auch Client MPTCP unterstützen, und auch das dazwischenliegende Netzwerk muss MPTCP unterstützen. Es dürfte daher einige Zeit dauern, bis sich die Technologie breit durchsetzt.
• Das QUIC-Protokoll von Google bietet ebenfalls ähnliche Multipath-Funktionen. Da QUIC einfacher ist und auf UDP basiert, dürfte es sich schneller verbreiten. Ein Wettbewerb zwischen MPTCP und QUIC ist zu erwarten.
• Anders als die kernelabhängige MPTCP-Implementierung für Linux implementiert Apple MPTCP eigenständig im Userspace und liefert es mit iOS und macOS aus. Es erscheint möglich, dass Google einen ähnlichen Ansatz verfolgt.
• Damit Pfadsteuerung und Scheduling-Richtlinien von MPTCP optimal auf die Anforderungen von Anwendungen abgestimmt werden können, scheint ein Informationsaustausch zwischen Anwendung und MPTCP über APIs erforderlich zu sein. Eine standardisierte Lösung dafür scheint bisher nicht zu existieren.

[GN⁺]

Hacker-News-Kommentare

• Als ich 2013 zum ersten Mal von MPTCP hörte, dachte ich, es würde wegen der damals schwachen Reaktion mobiler Apps auf Netzwerkwechsel enorm zur Verbesserung der Nutzererfahrung beitragen, aber es ist sehr enttäuschend, dass es auch nach 10 Jahren kaum Beachtung gefunden hat
• Ich weiß nicht, was trauriger ist: der 32-Bit-Adressraum von IPv4 oder die Tatsache, dass TCP in seinem Verbindungs-Tupel Quell-/Ziel-IP-Adressen verwendet. Wenn ich eine Zeitmaschine hätte, würde ich in die Vergangenheit reisen und diese beiden Dinge ändern
• Der praktische Einsatz von MPTCP besteht darin, Mobilfunk- und Wi‑Fi-Netzwerke gemeinsam zu nutzen, um die Geschwindigkeit zu erhöhen, aber wegen mobiler Datentarife habe ich es persönlich immer deaktiviert, daher ist es für mich nutzlos
• Schade, dass keine Links zu Projekten vorhanden sind, die MPTCP verwenden, etwa OpenWrt-Derivate. Ich habe zwei Jahre lang im GSOC einen Studenten betreut, der Support für MPTCP in OpenWrt gepatcht hat
• Wenn es einen transparenten Fallback gibt, frage ich mich, warum ein explizites Opt-in der Anwendung nötig ist. Am sinnvollsten wäre es wohl, wenn der Kernel dies für alle TCP-Verbindungen transparent handhabt und globale Entscheidungen über Pfadaggregation/Link-Präferenzen trifft
• Ich arbeite an Support/Debugging/Anpassungen des Linux-Netzwerk-Stacks und von Treibern und bin über die geringe Verbreitung von MPTCP erstaunt. Es scheint, als seien alle Dinge, die wie SCTP versucht haben, bestehendes TCP zu ersetzen, dazu bestimmt, nur von einer kleinen Zahl von Entwicklern genutzt und vom Rest der Welt vergessen zu werden
• Ich habe ein Paper gefunden, das die architektonischen Unterschiede zwischen MPTCP und QUIC sowie das von den Autoren vorgeschlagene MPQUIC-Protokoll erklärt. QUIC multiplexiert Anwendungs-Streams über einen einzelnen UDP-Flow, und MPTCP teilt einen einzelnen Stream in mehrere TCP-Subflows auf. MPQUIC kombiniert beides, indem es Anwendungs-Streams über mehrere UDP-Subflows multiplexiert
• Apple unterstützt ebenfalls MPTCP und verwendet es für Siri
• Es wirkt ziemlich einschränkend, dass, wenn eine Middlebox die MPTCP-Optionen nicht unterstützt, das SYN+ACK-Paket keine MPTCP-Option enthält. Besteht die einzige Anforderung an Middleboxes darin, die MPTCP-Optionen unverändert durchzureichen?
• MPTCP könnte bei Sicherheits-/Datenschutzeinstellungen hilfreich sein. Wenn man zum Beispiel den Traffic auf mehrere Uplink-Kanäle aufteilt, wird es für die chinesische Regierungs-Firewall schwieriger, den Traffic zum Blockieren wieder zusammenzuführen