Zusammenfassung

  • Nach dem Rückfall auf gewöhnliches TCP mittels unendlichen Mappings darf dieselbe Verbindung nicht zu MPTCP zurückkehren.
  • Eine MPTCP-Verbindung mit nur einem Subflow ist ein anderer Zustand. Wer die Mehrpfadfähigkeit nach dem Rückfall wiedergewinnen will, benötigt eine neue Verbindung, deren Erfolg nicht garantiert ist.

Eine erfolgreiche Kompatibilitätsmaßnahme kann eine spätere Wiederherstellung erschweren. Das zeigt ein eng umrissener Fall bei Multipath TCP: Die Übertragung läuft weiter, weil die Verbindung auf gewöhnliches TCP zurückfällt. Die Möglichkeit, diese Verbindung wieder über MPTCP-Subflows zu betreiben, ist damit aber beendet.

RFC 8684 zieht diese Grenze beim Rückfall durch ein unendliches Mapping. Danach ist die Rückkehr zu MPTCP innerhalb derselben Verbindung untersagt. Dass ein zweiter Netzanschluss später wieder funktioniert, hebt diese Regel nicht auf. Sie betrifft weder den gesamten Rechner noch alle zukünftigen Verbindungen, sondern genau die Verbindung, die diesen Zustandswechsel vollzogen hat.

Für den Betrieb entsteht eine Trennung zwischen zwei Zielen. Der laufende Datenstrom soll erhalten bleiben. Zugleich soll die erwartete Mehrpfadfähigkeit wieder verfügbar werden. Das erste Ziel kann bereits erreicht sein, während das zweite einen Verbindungswechsel verlangt. Über dessen Folgen kann die Transportschicht nicht stellvertretend für die Anwendung entscheiden.

Der Wechsel betrifft mehr als die Zahl der Pfade

MPTCP stellt einen geordneten Bytestrom bereit, dessen Daten über einzelne TCP-Subflows laufen. Jeder Subflow besitzt einen eigenen Sequenznummernraum. Die Verbindung hat zusätzlich einen Daten-Sequenznummernraum. Ein DSS-Signal vermittelt die Zuordnung zwischen beiden, damit empfangene Bytes auch bei Übertragung über verschiedene Subflows korrekt eingeordnet werden können.

Auch Empfangsbestätigungen gelten auf unterschiedlichen Ebenen. Im gewöhnlichen MPTCP-Betrieb darf der Sender Daten nicht allein deshalb aus seinem Puffer entfernen, weil ein Subflow sie bestätigt hat. Er benötigt die Bestätigung auf Verbindungsebene und auf sämtlichen Subflows, über die diese Daten gesendet wurden. Der Empfänger kann ein TCP-Segment bereits bestätigt haben und später dennoch zwischengespeicherte Daten für die Verbindung verwerfen, etwa bei Speicherknappheit.

Das unendliche Mapping verwendet den reservierten Datenlängenwert null, um die Zuordnung für den Rest der Verbindung festzulegen. Nach dem Rückfall darf sich der Sender zum Leeren seines Puffers nur noch auf Subflow-ACKs stützen; der Empfänger sollte keine MPTCP-Data-ACKs mehr senden. Die weitere Übertragung folgt den Regeln des gewöhnlichen TCP.

Damit ändert sich die Grundlage der Datenhaltung. Es handelt sich nicht bloß um einen Scheduler, der vorübergehend einen einzigen Weg bevorzugt. Die Abschnitte 3.3 und 3.7 von RFC 8684 beschreiben diese Transportgrenze. Keine der dort behandelten Bestätigungen belegt jedoch den Abschluss eines Geschäftsvorgangs in der Anwendung.

Nicht jeder Fehler beendet MPTCP

Das Verfahren berücksichtigt Zwischenstationen, die Optionen entfernen oder Nutzdaten verändern. Solche Eingriffe können die Beziehung zwischen den Sequenznummern des Subflows und denen der Verbindung beschädigen. Eine ausgehandelte Prüfsumme kann einschlägige Fehler erkennbar machen. Sie ist aber keine kryptografische Authentisierung und kein Nachweis einer böswilligen Ursache.

Bestehen mehrere Subflows, kann ein Prüfsummenfehler zur Schließung des betroffenen Subflows führen. Die Daten des fehlerhaften Mappings werden nicht auf Verbindungsebene bestätigt und über andere Subflows erneut übertragen. MPTCP kann auf diese Weise weiterbestehen. Jeden Prüfsummenfehler als Rückfall der gesamten Verbindung zu bezeichnen, wäre daher falsch.

Bei nur einem Subflow hängt ein Rückfall ohne vorherige Schließung von einer weiteren Bedingung ab: Die noch unbestätigten Daten unterwegs müssen nachweislich zusammenhängend sein. Die Anzahl der Subflows sagt darüber nichts Verlässliches aus. Es können etwa Wiederholungsübertragungen von einem zuvor unsauber geschlossenen Subflow enthalten sein.

MP_FAIL nennt die Daten-Sequenznummer am Beginn des fehlerhaften Mappings. Im einschlägigen Rückfallverfahren wird auch die Gegenrichtung auf gewöhnliches TCP zurückgeführt. Für nicht zusammenhängende Daten beschreibt die Spezifikation einen Sonderfall mit Reset und gegebenenfalls einem neuen Subflow, der unmittelbar ein unendliches Mapping erhält. Dieser neue Subflow gehört weiterhin zur alten Verbindung. Er stellt keine erneuerte Mehrpfadverbindung dar.

Auch fehlende Optionen bei der ersten Aushandlung und beschädigte Mappings in einer bereits laufenden Übertragung sind auseinanderzuhalten. Manche Situationen verlangen, den problematischen Subflow aufzugeben. Das Verfahren ist kein bedingungsloser Rettungsschalter für jede beschädigte Verbindung. Wurde keine Prüfsumme ausgehandelt, braucht die Erkennung einer Nutzdatenänderung für diesen Zweck ein Signal aus einer anderen Schicht.

Zwei Zustände mit demselben Zählerstand

Eine weiterhin als MPTCP arbeitende Verbindung kann nur einen Subflow besitzen und dennoch später weitere aufbauen. Nach dem unendlichen Mapping darf dagegen nur einer senden; die übrigen müssen beendet werden. Die Rückkehr zu MPTCP in derselben Verbindung bleibt ausgeschlossen. Ein Zählerstand von eins kann somit zwei sehr unterschiedliche Zukunftsmöglichkeiten verdecken.

Ein Adressverzeichnis beseitigt diese Unsicherheit nicht automatisch. RFC 6897 beschreibt eine abstrakte Anwendungsschnittstelle. Ihr Grundmodell sieht vor, MPTCP vor dem Verbindungsaufbau anzufordern, die Unterstützung danach abzufragen und die Adressen bestehender Subflows zu ermitteln. Daraus folgt nicht, dass ein bestimmtes heutiges Betriebssystem die genannten symbolischen Operationen oder eine zuverlässige Benachrichtigung über einen späteren Rückfall bereitstellt.

Das Dokument warnt zudem vor veralteten Subflow-Listen. Herkömmliche Adressabfragen behalten die Angaben des ersten Subflows bei, selbst wenn dieser nicht mehr verwendet wird. Die vertraute Gegenstellenadresse im Protokoll ist deshalb kein Beleg für den gegenwärtigen Pfad. Erweiterte Rückrufmechanismen im Anhang waren Gegenstand künftiger Arbeit, nicht zugesicherte Eigenschaften der Basisschnittstelle.

Diese Quellen haben unterschiedliche Rollen. Der Eintrag zu RFC 8684 nennt eine Proposed Standard vom März 2020, welche die frühere MPTCP-Version ablöste. Das verifizierte Erratum korrigiert eine verfrühte Datenbestätigung in einem TCP-Fast-Open-Beispiel, nicht das Rückkehrverbot in Abschnitt 3.7. RFC 6897 ist hingegen als Informational vom März 2013 eingeordnet; die Errata-Abfrage ergab keine passenden Einträge. Aus diesen Dokumenten lassen sich Entwurfsgrenzen ableiten, keine aktuellen Messwerte eines produktiven Gerätebestands.

Eine neue Verbindung ist notwendig, nicht hinreichend

Dass zur Wiedergewinnung von MPTCP eine andere Verbindung erforderlich ist, folgt aus dem Verbot der Rückkehr in der alten. Es garantiert weder eine erfolgreiche neue Aushandlung noch nutzbare zusätzliche Pfade. Die Zwischenstation oder Netzbedingung, die zum Rückfall führte, kann weiterhin vorhanden sein.

Ein begrenzter Transfer lässt sich möglicherweise auf der erhaltenen Verbindung abschließen. Bei einer langlebigen Sitzung kann eine ausdrücklich festgelegte Wechselgrenze sinnvoll sein. Welche Arbeit fortgesetzt und welche wiederholt werden darf, bestimmt jedoch die Anwendung. Ein neuer Socket klärt nicht nachträglich, ob ein Vorgang auf dem alten bereits ausgeführt wurde.

Lu Heng fragt in seiner Analyse des Prinzipal-Agent-Problems nach dem Verhältnis zwischen Entscheidungsmacht und Folgen. Sein Text zum Zweck von BTW stellt die Beschreibung der Struktur in den Vordergrund. Hier bedeutet das, den Nutzen des erhaltenen Datenstroms anzuerkennen, ohne die noch offene Entscheidung über seine Ablösung unsichtbar zu machen.