Multipath TCP für Linux (2022)

 (mptcp.dev)
1 Punkte von GN⁺ 2024-04-21 | 1 Kommentare | Auf WhatsApp teilen
  • MPTCP ist eine auf RFC 8684 basierende TCP-Erweiterung, bei der eine einzelne Verbindung mehrere Netzwerk-Interfaces gleichzeitig nutzen kann, um Bandbreite, Latenz und Ausfallsicherheit zu verbessern
  • Durch die parallele Nutzung mehrerer Pfade sind Bandbreitenbündelung, die Bevorzugung von Pfaden mit niedriger Latenz und die erneute Einspeisung über andere Pfade bei Ausfällen möglich
  • Unter Linux werden Sockets mit IPPROTO_MPTCP erstellt und gewöhnliche TCP-Verbindungen als subflow aufgebaut; wenn die Gegenstelle oder zwischengeschaltete Geräte dies nicht unterstützen, erfolgt automatisch ein Fallback auf Single-Path-TCP
  • Für die Pfadverwaltung gibt es unter Linux mit Stand v5.19 sowohl einen im Kernel integrierten Ansatz als auch einen User-Space-Daemon-Ansatz wie mptcpd; mit Stand Linux v6.8 gibt es nur einen Paket-Scheduler, der über net.mptcp-sysctl gesteuert wird
  • Mit Stand Linux v6.10 umfasst der Funktionsumfang Unterstützung für socket(), TCP-Fallback, Kernel-/User-Space-Pfadverwaltung, TCP-Socket-Optionen sowie MIB-, ss-Diagnose- und Tracepoint-Debug-Funktionen

Wie MPTCP die TCP-Verbindung verändert

  • Multipath TCP (MPTCP) ist eine Erweiterung des Standard-TCP und in RFC 8684 definiert
  • Eine einzelne MPTCP-Verbindung kann mehrere Interfaces gleichzeitig verwenden, um TCP-Pakete zu senden und zu empfangen
  • Die Bandbreite mehrerer Interfaces kann gebündelt werden, oder es kann bevorzugt das Interface mit der niedrigsten Latenz genutzt werden
  • Fällt ein Pfad aus, kann der Traffic nahtlos über einen anderen Pfad erneut eingespeist werden, um ein Failover durchzuführen
  • Anders als normales TCP, das jeweils nur einen Pfad verwendet, kann MPTCP mehrere Pfade wie 5G und Wi‑Fi gleichzeitig als subflows nutzen

Typische Einsatzfälle

  • Unterbrechungsfreies Handover

    • Es ist möglich, von einem Pfad auf einen anderen umzuschalten, ohne die bestehende Verbindung zu verlieren
    • Apple verwendet Multipath TCP seit 2013 auf Smartphones hauptsächlich aus diesem Grund

  • Optimale Netzwerkauswahl

    • Unter den verfügbaren Pfaden wird je nach Bedingungen wie Latenz, Verlust, Kosten und Bandbreite der „beste“ Pfad ausgewählt

  • Netzwerkbündelung

    • Mehrere Pfade können gleichzeitig genutzt werden, um den Durchsatz zu erhöhen
    • Ein Beispiel ist die Kombination aus Festnetz und Mobilfunknetz, um Dateien schneller zu übertragen

Wie unter Linux Verbindungen zustande kommen

  • Wenn mit dem Linux-spezifischen Protokoll IPPROTO_MPTCP ein neuer Socket erstellt wird, wird ein subflow oder Pfad erzeugt
  • Ein subflow ist eine normale TCP-Verbindung, die Daten über ein einzelnes Interface überträgt
  • Anschließend können nach einer Aushandlung zwischen den Hosts zusätzliche subflows erzeugt werden
  • Im TCP-Optionsfeld des zugrunde liegenden TCP-subflow wurden neue Felder ergänzt, damit der Gegenhost erkennen kann, dass MPTCP verwendet wird
    • Zu diesen Feldern gehört unter anderem die Option MP_CAPABLE, die der Gegenstelle die Verwendung von MPTCP signalisiert
  • Wenn der Gegenhost oder eine zwischengeschaltete middlebox MPTCP nicht unterstützt, enthält das zurückgegebene SYN+ACK-Paket im TCP-Optionsfeld keine MPTCP-Option
    • In diesem Fall wird die Verbindung auf normales TCP zurückgestuft und als Single-Path-Verbindung fortgesetzt

Path Manager und Packet Scheduler

  • Intern trennt MPTCP die Aufgaben zur subflow-Erzeugung, Adressankündigung und Auswahl des Übertragungspfads zwischen Path Manager und Packet Scheduler

  • Path Manager

    • Der Path Manager verwaltet subflows von der Erstellung bis zur Löschung und übernimmt auch die Adressankündigung
    • In der Regel initiiert die Client-Seite die subflows, während die Server-Seite zusätzliche Adressen über die Optionen ADD_ADDR und REMOVE_ADDR ankündigt
    • Mit Stand Linux v5.19 werden zwei Path Manager über den sysctl-Knopf net.mptcp.pm_type gesteuert
      • Typ 0: ein im Kernel integrierter Ansatz, der auf alle Verbindungen dieselben Regeln anwendet. Er ist mit ip mptcp verbunden
      • Typ 1: ein User-Space-Ansatz, der von einem Daemon wie mptcpd gesteuert wird und pro Verbindung unterschiedliche Regeln anwenden kann

  • Packet Scheduler

    • Der Packet Scheduler wählt den subflow aus, der für das Senden des nächsten Datenpakets verwendet wird
    • Er kann die verfügbare Bandbreite maximieren, nur Pfade mit geringerer Latenz auswählen oder andere konfigurierte Richtlinien anwenden
    • Mit Stand Linux v6.8 gibt es nur einen Packet Scheduler, der über den sysctl-Knopf von net.mptcp gesteuert wird

Funktionen mit Stand Linux v6.10

  • Mit Stand Linux v6.10 bietet MPTCP die folgenden Funktionen
    • Unterstützung des Protokolls IPPROTO_MPTCP im Systemaufruf socket()
    • Fallback von MPTCP auf TCP, wenn die Gegenstelle oder eine middlebox MPTCP nicht unterstützt
    • Pfadverwaltung mit einem im Kernel integrierten oder einem User-Space-Path-Manager
    • Üblicherweise verwendete Socket-Optionen für TCP-Sockets
    • Debug-Funktionen einschließlich MIB-Zählern, diag-Unterstützung für den Befehl ss und Tracepoints
  • Detaillierte Änderungen finden sich im ChangeLog

Kommunikation und zugehörige Projekte

Ressourcen für die Kernel-Entwicklung

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-04-21
Meinungen auf Hacker News

  • Von MPTCP hatte ich schon 2013 gehört
    Wenn man bedenkt, dass mobile Apps damals nicht besonders robust gegenüber Netzwerkwechseln waren, dachte ich, die UX-Verbesserung wäre so groß, dass es schnell übernommen würde
    Aber in den letzten 10 Jahren hat es kaum Traktion bekommen, und dass erst jetzt eine Kernel-Option auftaucht, ist ziemlich deprimierend. In der Zwischenzeit haben alle ihre HTTP-Aufrufe mit mehreren Retry-Handlern umwickelt, und mobile Betriebssysteme abstrahieren Netzwerkkonnektivität so stark, dass es sich eher anfühlt, als würde man zeromq nutzen statt TCP

    • Viel Innovationsenergie scheint zu QUIC gewandert zu sein. Denn bei TCP können Middleboxes neue Varianten beliebig kaputtmachen, selbst wenn man sie gut entwirft
      Ein Beispiel siehe https://blog.apnic.net/2021/12/08/efficient-multipath-transp...
    • Ich wollte es mögen, und Apple hat es auch in iOS eingebaut, aber es auf echten Servern zu unterstützen war viel zu schwierig
      Als wir es ohne Load Balancer auf FreeBSD ausgerollt haben, fehlten die neuesten Patches; und selbst wenn sie vorhanden gewesen wären, hätte es erheblichen Aufwand bedeutet, private Netzwerk-IPs nicht als alternative Pfade zu annoncieren
      Unter Linux hinter einem Load Balancer war es viel zu kompliziert, die Streams an die richtige Stelle zu schicken, und die Load Balancer wollten das auch nicht tun
      Zwei Streams gemeinsam zu verarbeiten bringt viel Komplexität in einen High-Throughput-Pfad, was ein großes Risiko ist, und Änderungen erfordern auch einen Neustart
      Selbst wenn man all das erledigt, liegt der Nutzen hauptsächlich bei iOS-Nutzern, die ohnehin tendenziell bessere Netze verwenden
    • Auch SCTP aus dem Jahr 2000 ist einen Blick wert. Auch das wurde bis heute kaum übernommen
      https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr...
    • Als wir Lieferroboter bauten, hatten wir Hoffnungen in MPTCP gesetzt, weil wir mit zwei Mobilfunkmodems sofortiges Failover wollten
      Am Ende haben wir PepLinks SpeedFusion genutzt, um Entwicklungszeit zu sparen, aber die Lizenzkosten waren hoch. Ich hoffe, dass es künftig eine kostenlose Lösung für zwei Mobilfunknetze und Failover unter 50 ms geben wird
      Multipath-UDP + OpenVPN könnte wahrscheinlich ebenfalls eine praktikable Lösung sein
    • Eher deprimierend ist, dass das überhaupt Aufmerksamkeit bekommt, die es nicht verdient. TCP sollte nicht immer weiter mit einzelnen Hacks ergänzt werden, die in modernen Umgebungen nur für ungefähr die Hälfte der Use Cases halbwegs passen, sodass man dann Kombinationen auswählen muss; es sollte durch SCTP ersetzt werden

  • Ich weiß nicht, was trauriger ist: dass der IPv4-Adressraum nur 32 Bit hat oder dass TCP Quell-/Ziel-IP-Adressen im Verbindungstupel verwendet
    Wenn ich eine Zeitmaschine hätte, würde ich zu Cerf und Kahn zurückreisen und sie dazu bringen, beides zu ändern

    • Ich frage mich, wie du TCP ändern würdest
      Meinst du die Struktur, bei der Verbindungen über die IP-Adressen und Ports beider Seiten verfolgt werden, also über vier Felder?
    • Sie würden vermutlich sagen, dass sie uns bereits Source Routing gegeben haben, dass das die Hälfte dessen ist, was du willst, und dass es als Option korrekt spezifiziert ist

  • Schade, dass keine Links zu Projekten fehlen, die MPTCP nutzen, etwa zu OpenWrt-Derivaten
    Ich habe im Rahmen von GSOC zwei Jahre lang Studenten betreut und MPTCP in OpenWrt gepatcht
    https://blog.freifunk.net/2017/05/29/gsoc-2017-add-mptcp-sup...

    • Dieses Projekt könnte interessant sein: https://github.com/Ysurac/openmptcprouter
      Ich habe kürzlich eine Immobilie gekauft, an der ich keinen vollständigen Glasfaseranschluss bekomme, aber über 5G 150–400 Mbit/s erreiche. Ich überlege, zwei 5G-Leitungen zu nutzen und den Traffic per MPTCP bis zu einem VPS zu tunneln, um die Leitungen zu bündeln
    • Wurde kürzlich im Home-Assistant-HAOS-Kernel aktiviert
      https://github.com/home-assistant/operating-system/pull/3248
    • Ein Beispiel für OpenWrt ist dies
      http://www.openmptcprouter.com/
    • Ich frage mich, welchen Vorteil es hat, wenn ein OpenWrt-Router MPTCP unterstützt
      Am wichtigsten scheint mir die Unterstützung auf Webservern und mobilen Geräten zu sein

  • Wenn es transparente alternative Pfade gibt, verstehe ich nicht, warum die Anwendung explizit dafür optieren muss
    Der Kernel sollte das doch transparent für alle TCP-Verbindungen handhaben, damit er globale Entscheidungen wie Pfadaggregation oder Link-Präferenzen besser treffen kann, oder?

    • Soweit ich es verstehe, war das eine Bedingung, die die Maintainer des Linux-TCP-/Networking-Subsystems faktisch erzwungen haben. In den frühen Upstream-Diskussionen[1] war das als Grundregel festgelegt
      Die ältere Multipath-TCP-Implementierung vor dem Upstreaming war als vollständig transparent für Anwendungen gedacht, und das passt meiner Ansicht nach besser zum Zweck des Protokolls
      Natürlich kann MPTCP in vielen Fällen besser sein, wenn es Hinweise von der Anwendung bekommt, aber ein Standard-Systemansatz, bei dem man zum Beispiel einen Subflow über LTE aufbaut, um automatisches Failover bereitzuhalten, ohne Daten über diesen Subflow zu senden, hätte in 95 % der Fälle wohl ausgereicht
      [1] https://lore.kernel.org/all/alpine.OSX.2.21.1707181728570.11...
    • Es zu verwenden bedeutet, dass bei einer einzelnen TCP-Verbindung an jedem Endpunkt mehrere IPs beteiligt sein können. In vielen Fällen ist dafür explizite Unterstützung oder zumindest Bewusstsein in der Anwendung nötig
    • Wenn man zulässt, dass mehrere IPs über dieselbe TCP-Verbindung kommunizieren, können neue Sicherheitslücken entstehen
      Man kann sich zum Beispiel eine Anwendung vorstellen, die beim Verbindungsaufbau die Client-IP gegen eine Whitelist prüft und danach annimmt, dass sie sich nicht mehr ändert

  • Der einzige praktische Nutzen von MPTCP ist für mich, Mobilfunknetz und Wi‑Fi gemeinsam zu verwenden, um die Geschwindigkeit zu erhöhen. Sowohl iOS als auch WeChat unterstützen das.
    Da Mobilfunknetze aber nach Verbrauch abgerechnet werden, lasse ich das immer ausgeschaltet. Für mich persönlich ist MPTCP daher nutzlos.

    • Mit diesem Problem habe ich mich schon beschäftigt. Intern nannten wir es Parkplatz-Bug.
      Das Wi‑Fi-Signal ist noch sichtbar, aber die Verbindung funktioniert nicht richtig. Mit MPTCP erfolgt ein Failover auf Mobilfunk.

  • Ich arbeite daran, den Linux-Netzwerk-Stack und Treiber zu unterstützen, zu debuggen und zu korrigieren, und es überrascht mich, dass das so wenig verbreitet ist.
    Wie bei SCTP und anderen Ansätzen, die normales TCP ersetzen wollten, scheint MPTCP eine Nischentechnologie zu bleiben, die einige Anwendungsentwickler weiter nutzen, während der Rest der Welt sie vergisst.

    • Apple Siri nutzt MPTCP; wenn man die Zahl der Geräte bedenkt, ist es also nicht wirklich nur eine Nische.

  • Ich habe Material gefunden, das die strukturellen Unterschiede zwischen MPTCP und QUIC erklärt und auch das von den Autoren vorgeschlagene MPQUIC-Protokoll vorstellt.
    QUIC multiplext Anwendungs-Streams über einen einzelnen UDP-Flow, während MPTCP einen einzelnen Stream auf mehrere TCP-Subflows aufteilt. MPQUIC kombiniert beide Eigenschaften und multiplext Anwendungs-Streams über mehrere UDP-Subflows.
    [1]: "Multipath QUIC: A Deployable Multipath Transport Protocol" https://www.researchgate.net/publication/327122884_Multipath...
    Jetzt frage ich mich, wie sich diese Protokolle in Produktionsumgebungen vergleichen. Hat jemand beide eingesetzt?

    • MPQUIC wird noch in der IETF diskutiert. Auch beim letzten IETF-Treffen wurden weitere Änderungen besprochen, und leider verlangsamt das die Einführung.
      https://lwn.net/Articles/964377/
      Beide versuchen, dasselbe Ziel zu erreichen. Technisch lässt sich ein sehr ähnliches Verhalten erzeugen. MPTCP ist im Linux-Kernel implementiert, QUIC liegt eher im Userspace.

  • Apple unterstützt es ebenfalls und verwendet es für Siri.
    https://developer.apple.com/documentation/foundation/urlsess...

    • Auch in anderen Apps lässt es sich ziemlich einfach nutzen. Es ist in den Standardfunktionen enthalten.
      2011 war ich überrascht, wie robust unsere VoIP-App lief :D

  • Dass im zurückkommenden SYN+ACK-Paket das MPTCP-Optionsfeld fehlt, wenn auch nur eine der Middleboxes es nicht unterstützt, klingt ziemlich einschränkend.
    Ist die einzige Anforderung an Middleboxes, dass sie die MPTCP-Option unverändert weiterleiten?

  • Es könnte bei Sicherheits- und Privatsphäre-Einstellungen hilfreich sein.
    Denkt man zum Beispiel an die Great Firewall of China: Wenn sich Traffic auf mehrere Uplink-Kanäle aufteilen lässt, würde es für die Firewall dann nicht schwieriger, ihn wieder zusammenzusetzen und Regeln durchzusetzen?

    • Wenn es unbekannter Traffic ist, kann man ihn einfach blockieren oder stark drosseln.