Zusammenfassung

  • Multipath TCP liefert der Anwendung einen zuverlässigen, geordneten Bytestrom, obwohl die Endpunkte ihn über einen oder mehrere gewöhnliche TCP-Subflows transportieren können.
  • MP_CAPABLE handelt die Verbindung aus, MP_JOIN authentisiert einen zusätzlichen Subflow, und die gemeinsame Datensequenz erlaubt nach einem Ausfall die erneute Übertragung über einen anderen Pfad.
  • Zwei Schnittstellen beweisen keine Resilienz: Pfade können denselben Engpass teilen, eine Middlebox kann Optionen entfernen, und die Endpunktpolitik entscheidet, ob der zweite Weg aktiv, Reserve oder ungenutzt ist.

Ein Socket überlebt den WLAN-Rand

Der Wechsel des Zugangs sieht wie eine Adressänderung aus. Eine Adresse verliert ihre Funktion, eine andere wird erreichbar. Für die Anwendung ist jedoch nicht die Adresse das wertvolle Objekt, sondern der bereits aufgebaute Zustand und die Folge von Bytes, die zuverlässig und in richtiger Reihenfolge ankommen soll.

RFC 8684 trennt Verbindung und Pfad. Eine MPTCP-Verbindung gehört zu einem Anwendungssocket, kann aber mehrere Subflows enthalten. Jeder Subflow verhält sich auf seinem Weg wie TCP. Darüber bewahrt die Verbindung Zuverlässigkeit und Ordnung. Das Ende eines Subflows muss deshalb nicht das Ende der gesamten Verbindung sein.

Diese Möglichkeit bleibt bedingt. Beide Endpunkte müssen MPTCP aushandeln, mindestens ein brauchbarer Subflow muss bestehen oder aufgebaut werden können, und der gemeinsame Zustand muss erhalten bleiben. Das Protokoll stellt die Mechanik bereit; es bestätigt weder Funkabdeckung noch physische Trennung oder Qualität des Ersatzwegs.

Ein weiterer Pfad ist eine Zulassungsentscheidung

Der erste Subflow trägt den MP_CAPABLE-Austausch. Die Endpunkte bestätigen ihre Unterstützung und tauschen Schlüsselmaterial für die Verbindung aus. Versteht der Gegenüber MPTCP nicht oder verhindert ein Gerät unterwegs die Optionen, kann die Verbindung auf normales TCP zurückfallen.

Eine zusätzliche Adresse tritt nicht automatisch bei. Der neue Handshake führt MP_JOIN: Ein Token benennt die bestehende Verbindung, Nonces und ein HMAC aus den ursprünglichen Schlüsseln bestätigen dieselben Gegenstellen. Eine lokale Regel darf den Subflow trotzdem ablehnen. Der zweite Pfad wird zugelassen, bevor er Transport leisten darf.

ADD_ADDR meldet eine weitere Adresse, REMOVE_ADDR zieht sie zurück. Adresskennungen helfen, wenn ein NAT Header umschreibt. Die Meldung schafft aber nur einen Kandidaten. Sie beweist keine Erreichbarkeit, Unabhängigkeit, Kosten oder Leistung.

Damit ist die Kontrollgrenze sichtbar. Das Netz stellt Erreichbarkeit her und beeinflusst den tatsächlichen Weg. Die Endpunkte entscheiden über MPTCP, Subflow-Teilnahme und lokale Politik. Eine unveränderte Anwendung kann nur einen normalen Socket sehen, während Pfad- und Kostenentscheidungen darunter stattfinden.

Ein gemeinsames Hauptbuch für alle Bytes

Jeder Subflow behält seine TCP-Sequenznummern. MPTCP ergänzt eine 64-Bit-Datensequenz für die gesamte Verbindung. Das DSS ordnet Bytes eines Subflows diesem gemeinsamen Raum zu und bestätigt Fortschritt auf Verbindungsebene.

Diese zweite Buchführung ermöglicht Erholung. Liefert ein Subflow Daten nicht, können dieselben Verbindungsbytes auf einem anderen Subflow mit neuer Zuordnung erneut gesendet werden. Die Anwendung erhält weiter einen einzigen zuverlässigen, geordneten Strom und muss nicht zwei unabhängige Verbindungen zusammenführen.

Ordnung kann zugleich bremsen. Eine Lücke auf dem langsamen Pfad kann spätere Bytes zurückhalten, obwohl sie über den schnellen Pfad bereits ankamen. Paketscheduler, erneute Übertragung auf einem anderen Weg und Überlastungssteuerung bestimmen, ob mehrere Pfade Kapazität oder nur Wartezeit hinzufügen. RFC 8041 behandelt dies als praktische Betriebsfrage.

Auch der Reservepfad hat einen Preis

Ein Subflow kann regulär oder Reserve sein; MP_PRIO kann die Priorität ändern. Hinter diesem kleinen Signal steckt eine wirtschaftliche Entscheidung. Mobilfunk kann die Verbindung retten und nach Volumen kosten. Satellit kann erreichbar und langsam sein. Zwei Festnetzzugänge können im selben Kanal oder Upstream zusammentreffen.

RFC 6182 warnt ausdrücklich: Mehrere Adresspaare bedeuten nicht zwingend disjunkte Pfade. Die Architektur zielt auf Durchsatz und Resilienz, wahrt das TCP-Dienstmodell und soll andere Nutzer an gemeinsamen Engpässen nicht unfair benachteiligen. Das sind Entwurfsziele, keine Messwerte einer konkreten Installation.

Entscheidend ist daher die ausgehandelte Verbindung: tatsächlich aufgebaute Subflows, aktive und Reserve-Rollen, getrennte Ausfallbereiche, Fortschritt der Verbindungsbestätigungen und Bytes, die einen anderen Weg nehmen mussten. Schnittstellen zu zählen misst Möglichkeiten, nicht Kontinuität.

Rückfall ist ein eigenes Ergebnis

Middleboxes können TCP-Optionen entfernen, Adressen umschreiben oder Daten unvereinbar verändern. RFC 8684 beschreibt sichere Reaktionen: Der erste Subflow kann auf TCP zurückfallen, ein fehlerhafter zusätzlicher Subflow kann geschlossen werden, und ein Pfad ohne gültige Zuordnungen gilt als defekt.

Eine Anwendung kann also funktionieren, obwohl multipath nicht aktiv ist. Wer nur Anwendungserfolg überwacht, verwechselt zwei Fälle: Die Verbindung überlebte über einen anderen Subflow, oder MPTCP lief nie und gewöhnliches TCP blieb intakt. Wird die Verbindung größer als ein Pfad, muss auch der Betriebsnachweis größer werden.

Quellen