Résumé

  • Une connexion MPTCP réduite à un seul sous-flux ne se trouve pas nécessairement dans le même état qu'une connexion passée au TCP classique par mappage infini.
  • Après ce repli, retrouver MPTCP exige une autre connexion. Cela ne garantit ni une négociation réussie ni la possibilité de répéter sans risque le travail de l'application.

Le responsable d'un service peut recevoir deux bonnes nouvelles : la communication n'a pas été interrompue et le réseau dispose de nouveau d'un chemin supplémentaire. Il serait pourtant imprudent d'en déduire que la connexion en cours a retrouvé son fonctionnement multipath. Dans un cas précis prévu par MPTCP, ces événements ne suffisent pas. Le flux a survécu en changeant de régime, et ce changement n'est pas réversible pendant sa durée de vie.

C'est la portée du repli par « mappage infini » décrit par RFC 8684. La règle ne condamne ni la machine ni son interface réseau à rester en TCP classique. Elle porte sur cette connexion. Une autre pourra tenter de négocier MPTCP ; celle qui a déjà effectué ce repli ne pourra pas y revenir.

La nuance a une conséquence de gestion immédiate. Maintenir la communication et restaurer sa capacité multipath ne constituent plus une seule opération. La première peut avoir réussi alors que la seconde suppose de renouveler la connexion, avec des conséquences que la couche transport ne peut pas apprécier à la place de l'application.

Pourquoi il s'agit d'un changement de régime

MPTCP transporte un flux d'octets ordonné au moyen de plusieurs sous-flux TCP. Chaque sous-flux utilise ses propres numéros de séquence. Un signal DSS établit la correspondance avec la numérotation des données à l'échelle de la connexion. Le destinataire peut ainsi reconstituer le flux sans confondre l'ordre local d'un sous-flux avec celui de l'ensemble.

Cette distinction compte aussi pour les accusés de réception. En fonctionnement MPTCP ordinaire, l'émetteur doit conserver les données jusqu'à leur acquittement au niveau de la connexion et de tous les sous-flux sur lesquels elles ont été envoyées. Un acquittement TCP local ne suffit pas : le destinataire peut encore abandonner des données conservées en attente de traitement au niveau de la connexion.

Le mappage infini modifie ce mécanisme. La valeur réservée zéro dans le champ de longueur désigne un mappage valable pour le reste de la connexion. Après le repli, l'émetteur se fonde uniquement sur les acquittements du sous-flux pour libérer son tampon ; le destinataire devrait cesser d'émettre les acquittements de données propres à MPTCP. La communication se poursuit selon le fonctionnement TCP classique.

Il ne s'agit donc pas simplement de choisir un seul chemin dans un ordonnanceur. Les règles de conservation des données ont changé. Les sections 3.3 et 3.7 de RFC 8684 permettent de situer cette frontière. Elles ne donnent toutefois à aucun de ces acquittements la valeur d'une confirmation d'exécution applicative.

Le protocole ne choisit pas toujours le repli

Réduire le mécanisme à « erreur de somme de contrôle, donc retour à TCP » conduirait à une autre erreur. MPTCP distingue plusieurs situations. Des équipements intermédiaires peuvent retirer des options ou modifier la charge utile, compromettant la correspondance entre les deux espaces de séquence. Mais la réponse dépend des sous-flux encore utilisables et de l'état des données.

Avec plusieurs sous-flux, un échec de somme de contrôle peut entraîner la fermeture du seul sous-flux concerné. Les données dont le mappage a échoué ne sont pas acquittées au niveau de la connexion ; elles sont retransmises ailleurs. Les chemins restants peuvent ainsi préserver MPTCP. Ce traitement n'est pas le renoncement global à la capacité multipath.

Lorsqu'il ne reste qu'un sous-flux, un repli sans fermeture préalable exige que les données non acquittées en vol soient connues comme contiguës. Le simple nombre de sous-flux ne prouve pas cette propriété. Des retransmissions provenant d'un sous-flux disparu sans fermeture propre peuvent compliquer l'état restant.

Le signal MP_FAIL repère le début du mappage ayant échoué. Dans le cas de repli approprié, l'échange ramène aussi le sens inverse au TCP classique. Si les données ne sont pas contiguës, la procédure peut passer par une réinitialisation et la création d'un autre sous-flux auquel un mappage infini est aussitôt appliqué. Cet autre sous-flux appartient encore à la connexion ancienne. Il ne rétablit pas sa capacité multipath.

Ces conditions évitent de présenter le repli comme une réparation universelle. La perte d'options lors de la négociation initiale, leur disparition pendant le transfert et l'altération d'un mappage déjà utilisé ne se traitent pas toutes de la même manière. De plus, sans somme de contrôle négociée, la détection d'une modification de charge utile à cette fin demande un signal provenant d'une autre couche. La somme de contrôle n'est ni une authentification cryptographique ni une preuve d'intention malveillante.

Ce qu'un tableau de bord doit pouvoir distinguer

Après le mappage infini, un seul sous-flux peut émettre et les autres doivent être terminés. Le retour ultérieur à MPTCP est interdit dans cette connexion. Un compteur affichant « un » peut donc recouvrir deux états très différents : un MPTCP encore capable de développer d'autres sous-flux, ou un TCP classique qui n'a plus cette possibilité.

Un inventaire d'adresses ne résout pas automatiquement le problème. RFC 6897 décrit une interface applicative abstraite : activer MPTCP avant l'établissement, interroger le support après celui-ci, obtenir la liste des sous-flux établis. Le document ne prouve pas l'existence, dans un système d'exploitation actuel donné, d'une notification fiable du repli sous les noms symboliques qu'il propose.

Il souligne également qu'une liste de sous-flux peut devenir obsolète. Les appels hérités qui interrogent les adresses conservent celles du premier sous-flux, même s'il n'est plus utilisé. L'adresse familière dans un journal ne constitue donc pas un relevé du chemin actuel. Les rappels automatiques envisagés pour une interface avancée relevaient de travaux futurs, pas d'une garantie offerte par l'interface de base.

Les sources doivent rester à leur place. La fiche de RFC 8684 indique une Proposed Standard de mars 2020 remplaçant la version antérieure de MPTCP. L'erratum vérifié corrige un exemple TCP Fast Open concernant un acquittement prématuré ; il ne modifie pas l'interdiction de revenir à MPTCP en section 3.7. RFC 6897 est, selon sa fiche, un document Informational de mars 2013, et sa recherche d'errata ne renvoie aucune entrée correspondante. Aucun de ces constats ne mesure le comportement d'un parc en production.

La continuité ne décide pas du renouvellement

La nécessité d'une nouvelle connexion pour retrouver MPTCP découle de cette interdiction de retour. Elle ne promet pas que la tentative suivante réussira. Les mêmes obstacles peuvent subsister ; la présence d'un autre chemin ne prouve pas qu'il sera exploitable.

Il faut alors choisir une frontière de renouvellement compatible avec le travail en cours. Laisser finir un transfert peut être préférable à une interruption destinée à améliorer sa protection future. Une session longue peut appeler une autre politique. Dans les deux cas, les règles de reprise appartiennent à l'application : un flux d'octets fiable n'apporte pas à lui seul la certitude qu'une opération peut être recommencée.

La réflexion de Lu Heng sur le problème d'agence invite à rapprocher le pouvoir de décision de ses conséquences. Son texte sur la raison d'être de BTW privilégie la description des structures. Appliqué ici, ce regard n'accuse pas le mécanisme de repli : il rend visible la décision qu'un succès de compatibilité laisse encore à prendre.