Multipath TCP pour Linux (2022)

 (mptcp.dev)
1 points par GN⁺ 2024-04-21 | 1 commentaires | Partager sur WhatsApp
  • MPTCP est une extension de TCP basée sur la RFC 8684, dans laquelle une seule connexion peut utiliser simultanément plusieurs interfaces réseau afin d’améliorer la bande passante, la latence et la tolérance aux pannes
  • Son architecture, qui exploite plusieurs chemins en parallèle, permet l’agrégation de bande passante, la préférence pour les chemins à faible latence et la réinjection sur d’autres chemins en cas de panne
  • Sous Linux, on crée un socket avec IPPROTO_MPTCP et on établit des connexions TCP ordinaires appelées subflows ; si le pair ou un équipement intermédiaire ne le prend pas en charge, la connexion bascule automatiquement en TCP monochemin
  • Pour la gestion des chemins, Linux v5.19 propose un mode intégré au noyau et un mode via un démon en espace utilisateur comme mptcpd ; à partir de Linux v6.8, il n’existe qu’un seul ordonnanceur de paquets, contrôlé via le sysctl net.mptcp
  • À partir de Linux v6.10, les fonctionnalités incluent la prise en charge de socket(), le repli vers TCP, la gestion des chemins dans le noyau ou en espace utilisateur, les options de socket TCP, ainsi que des fonctions de débogage via les MIB, le diagnostic ss et les tracepoints

Comment MPTCP change le mode de connexion TCP

  • Multipath TCP (MPTCP) est une extension du TCP standard, définie dans la RFC 8684
  • Une connexion MPTCP peut envoyer et recevoir des paquets TCP en utilisant simultanément plusieurs interfaces
  • Il est possible d’agréger la bande passante de plusieurs interfaces ou de privilégier celle dont la latence est la plus faible
  • Si un chemin est interrompu, le trafic peut être réinjecté de manière transparente vers un autre chemin afin d’assurer un basculement en cas de panne
  • Là où le TCP classique n’utilise qu’un seul chemin à la fois, MPTCP peut exploiter plusieurs chemins comme la 5G et le Wi‑Fi sous forme de subflows

Cas d’usage représentatifs

  • Handover sans interruption

    • Il est possible de passer d’un chemin à un autre tout en conservant la connexion existante
    • Apple utilise Multipath TCP sur smartphone principalement pour cette raison depuis 2013

  • Sélection optimale du réseau

    • Il choisit le « meilleur » chemin parmi ceux disponibles selon des critères comme la latence, la perte, le coût ou la bande passante

  • Agrégation réseau

    • Plusieurs chemins peuvent être utilisés simultanément pour augmenter le débit
    • Un exemple est la combinaison d’un réseau fixe et d’un réseau mobile pour transférer des fichiers plus rapidement

Comment une connexion s’établit sous Linux

  • Lorsqu’on crée un nouveau socket avec le protocole Linux IPPROTO_MPTCP, un subflow ou path est créé
  • Un subflow est une connexion TCP classique qui transmet les données via une interface unique
  • Ensuite, une négociation entre les hôtes permet de créer des subflows supplémentaires
  • Dans le champ TCP option du subflow TCP sous-jacent, de nouveaux champs sont ajoutés afin que l’hôte distant puisse détecter l’utilisation de MPTCP
    • Ces champs incluent notamment l’option MP_CAPABLE, qui indique au pair que MPTCP est utilisé
  • Si l’hôte distant ou un middlebox intermédiaire ne prend pas MPTCP en charge, le champ TCP option du paquet SYN+ACK renvoyé ne contient pas d’option MPTCP
    • Dans ce cas, la connexion revient à un TCP classique et continue sur un seul chemin

Gestionnaire de chemins et ordonnanceur de paquets

  • En interne, MPTCP répartit la création des subflows, l’annonce des adresses et la sélection des chemins de transmission entre le Path Manager et le Packet Scheduler

  • Path Manager

    • Le Path Manager gère les subflows de leur création à leur suppression, et s’occupe aussi de l’annonce des adresses
    • En général, le côté client initie les subflows, tandis que le côté serveur annonce des adresses supplémentaires via les options ADD_ADDR et REMOVE_ADDR
    • À partir de Linux v5.19, deux path managers sont contrôlés par le sysctl net.mptcp.pm_type
      • type 0 : mode intégré au noyau, qui applique les mêmes règles à toutes les connexions ; lié à ip mptcp
      • type 1 : mode en espace utilisateur, piloté par un démon comme mptcpd, qui peut appliquer des règles différentes selon la connexion

  • Packet Scheduler

    • Le Packet Scheduler choisit le subflow à utiliser pour envoyer le prochain paquet de données
    • Il peut maximiser la bande passante disponible, ne sélectionner que les chemins à plus faible latence, ou appliquer d’autres politiques selon la configuration
    • À partir de Linux v6.8, il n’existe qu’un seul ordonnanceur de paquets, contrôlé par les paramètres sysctl de net.mptcp

Fonctionnalités à partir de Linux v6.10

  • À partir de Linux v6.10, MPTCP fournit les fonctions suivantes
    • prise en charge du protocole IPPROTO_MPTCP dans l’appel système socket()
    • repli de MPTCP vers TCP lorsque le pair ou un middlebox ne prend pas MPTCP en charge
    • gestion des chemins via un path manager intégré au noyau ou en espace utilisateur
    • options de socket couramment utilisées sur les sockets TCP
    • compteurs MIB, prise en charge diag utilisée par la commande ss, et fonctions de débogage incluant les tracepoints
  • Les changements détaillés sont disponibles dans le ChangeLog

Communication et projets associés

Ressources de développement noyau

À lire aussi

1 commentaires

 
GN⁺ 2024-04-21
Avis Hacker News

  • J’avais déjà entendu parler de MPTCP en 2013
    À l’époque, vu que les apps mobiles n’étaient pas très robustes face aux changements de réseau, je pensais que l’amélioration de l’UX serait importante et que l’adoption serait rapide
    Mais en dix ans, cela n’a presque pas gagné de traction, et voir seulement maintenant apparaître une option de noyau est assez déprimant. Entre-temps, tout le monde a enveloppé ses appels HTTP dans plusieurs gestionnaires de retry, et les systèmes d’exploitation mobiles ont tellement abstrait la connectivité réseau qu’on a davantage l’impression d’utiliser zeromq que TCP

    • Une grande partie de l’énergie d’innovation semble s’être déplacée vers QUIC. Avec TCP, même si l’on conçoit une bonne nouvelle variante, les équipements intermédiaires peuvent la casser arbitrairement
      Voir par exemple https://blog.apnic.net/2021/12/08/efficient-multipath-transp...
    • J’aurais aimé l’aimer, et Apple l’a aussi intégré à iOS, mais le prendre en charge côté serveurs réels était trop difficile
      Lors d’un déploiement sur FreeBSD sans load balancer, il n’y avait pas les derniers correctifs, et même s’ils avaient été présents, il aurait fallu pas mal de travail pour éviter d’annoncer des IP de réseau privé comme chemins alternatifs
      Sous Linux, derrière un load balancer, envoyer le flux au bon endroit était trop complexe, et le load balancer ne voulait pas non plus le faire
      Traiter deux flux ensemble ajoute une forte complexité sur un chemin à haut débit, ce qui est risqué, et toute modification nécessite aussi un redémarrage
      Même en faisant tout cela, le bénéfice concerne surtout les utilisateurs iOS, qui ont de toute façon tendance à utiliser de meilleurs réseaux au départ
    • SCTP, sorti en 2000, mérite aussi qu’on s’y intéresse. Lui non plus n’a pratiquement toujours pas été adopté
      https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr...
    • En construisant des robots de livraison, je fondais des espoirs sur MPTCP parce que je voulais un basculement immédiat avec deux modems cellulaires
      Au final, pour économiser du temps de développement, nous avons utilisé SpeedFusion de PepLink, mais les licences étaient chères. J’espère qu’une solution gratuite apparaîtra à l’avenir pour deux réseaux cellulaires et un basculement en moins de 50 ms
      UDP multipath + OpenVPN pourrait probablement aussi être une solution pratique
    • Ce qui est plutôt déprimant, c’est que cela reçoive une attention qu’il ne mérite pas vraiment. TCP ne devrait pas continuer à empiler des hacks plus ou moins adaptés à la moitié des cas d’usage modernes et laisser choisir leur combinaison ; il devrait être remplacé par SCTP

  • Je ne sais pas ce qui est le plus triste entre le fait que l’espace d’adressage IPv4 ne soit que de 32 bits et le fait que TCP utilise les adresses IP source/destination dans le tuple de connexion
    Si j’avais une machine à remonter le temps, je retournerais voir Cerf et Kahn pour leur faire changer les deux

    • Je me demande ce que cela veut dire par changer TCP
      S’agit-il de la structure où il faut suivre une connexion avec les adresses IP et les ports des deux côtés, soit quatre champs ?
    • Ils diraient sans doute qu’ils nous ont déjà donné le source routing, qui représente la moitié de ce que l’on veut, et qu’il est correctement spécifié comme option

  • Dommage qu’il n’y ait pas de lien vers des projets utilisant MPTCP, par exemple un projet dérivé d’OpenWrt
    Pendant deux ans au GSOC, j’ai mentoré un étudiant qui a patché OpenWrt pour MPTCP
    https://blog.freifunk.net/2017/05/29/gsoc-2017-add-mptcp-sup...

    • Ce projet pourrait être intéressant : https://github.com/Ysurac/openmptcprouter
      J’ai récemment acheté un bien immobilier où je ne peux pas faire installer une vraie fibre, mais où j’obtiens 150 à 400 Mbit/s en 5G. J’envisage d’utiliser deux lignes 5G et de tunneler le trafic jusqu’à un VPS avec MPTCP afin d’agréger les liens
    • Cela a récemment été activé dans le noyau HAOS de Home Assistant
      https://github.com/home-assistant/operating-system/pull/3248
    • Voici un exemple avec OpenWrt
      http://www.openmptcprouter.com/
    • Je me demande quel est l’intérêt qu’un routeur OpenWrt prenne en charge MPTCP
      Il me semble que le plus important serait la prise en charge par les serveurs web et les appareils mobiles

  • S’il existe un chemin de secours transparent, je ne comprends pas pourquoi il faut un choix explicite de l’application
    Le noyau ne devrait-il pas gérer cela de façon transparente pour toutes les connexions TCP, afin de mieux prendre des décisions globales comme l’agrégation de chemins ou la préférence de liens ?

    • Je comprends que c’est une condition imposée de fait par les mainteneurs des sous-systèmes TCP/réseau de Linux. Dans les premières discussions d’upstream[1], cela avait été établi comme règle de base
      L’ancienne implémentation Multipath TCP d’avant l’upstream était conçue pour être entièrement transparente pour les applications, et cela me semble mieux correspondre à l’objectif du protocole
      Bien sûr, dans de nombreux cas, MPTCP peut mieux fonctionner avec des indications de l’application, mais une simple approche standard du système — par exemple créer un sous-flux sur une connexion LTE afin de préparer un basculement automatique, sans envoyer de données sur ce sous-flux — aurait suffi dans 95 % des cas
      [1] https://lore.kernel.org/all/alpine.OSX.2.21.1707181728570.11...
    • L’utiliser signifie que, pour une seule connexion TCP, plusieurs IP peuvent être associées à chaque extrémité. Dans beaucoup de cas, cela nécessite une prise en charge ou au moins une conscience explicite côté application
    • Autoriser plusieurs IP à communiquer sur une même connexion TCP peut ouvrir de nouvelles failles de sécurité
      Par exemple, on peut imaginer une application qui vérifie l’IP du client par rapport à une liste blanche au moment de la connexion et suppose ensuite qu’elle ne change pas

  • Pour moi, le seul usage pratique de MPTCP est d’augmenter le débit en utilisant à la fois le réseau mobile et le Wi‑Fi. iOS comme WeChat le prennent en charge
    Mais le réseau mobile est facturé à l’usage, donc je le laisse toujours désactivé. Du coup, personnellement, MPTCP ne m’est pas utile

    • J’ai déjà travaillé sur ce problème. En interne, on l’appelait le bug du parking
      C’est la situation où le signal Wi‑Fi est toujours visible, mais où la connexion ne fonctionne pas correctement. Avec MPTCP, on bascule en secours sur le cellulaire

  • Je travaille sur le support, le débogage et la correction de la pile réseau Linux et de ses pilotes, et je suis surpris que ce soit si peu adopté
    Comme SCTP et d’autres tentatives de remplacement du TCP classique, MPTCP semble rester une technologie de niche que quelques développeurs d’applications continuent d’utiliser, tandis que le reste du monde l’oublie

    • Apple Siri utilise MPTCP ; vu le nombre d’appareils, il est difficile de dire que c’est seulement une niche

  • J’ai trouvé une ressource qui explique les différences structurelles entre MPTCP et QUIC, et présente aussi le protocole MPQUIC proposé par les auteurs
    QUIC multiplexe des flux applicatifs sur un seul flux UDP, tandis que MPTCP découpe un flux en plusieurs sous-flux TCP. MPQUIC combine les deux caractéristiques en multiplexant des flux applicatifs sur plusieurs sous-flux UDP
    [1] : « Multipath QUIC: A Deployable Multipath Transport Protocol » https://www.researchgate.net/publication/327122884_Multipath...
    Je me demande maintenant comment ces protocoles se comparent en environnement de production. Quelqu’un a-t-il utilisé les deux ?

    • MPQUIC est encore en discussion à l’IETF. D’autres changements ont été discutés lors de la dernière réunion de l’IETF, ce qui ralentit malheureusement son adoption
      https://lwn.net/Articles/964377/
      Les deux cherchent à atteindre le même objectif. Techniquement, on peut obtenir des comportements très similaires. MPTCP est implémenté dans le noyau Linux, tandis que QUIC est plutôt côté espace utilisateur

  • Apple le prend aussi en charge et l’utilise pour Siri
    https://developer.apple.com/documentation/foundation/urlsess...

    • D’autres apps peuvent aussi l’utiliser assez facilement. C’est intégré aux fonctionnalités de base
      En 2011, j’ai été surpris de voir notre app VoIP fonctionner de manière assez robuste :D

  • Le fait que, si un seul équipement intermédiaire ne le prend pas en charge, le champ d’options TCP du paquet SYN+ACK renvoyé ne contienne pas l’option MPTCP paraît assez restrictif
    La seule exigence imposée aux équipements intermédiaires est-elle simplement de transmettre telle quelle l’option MPTCP ?

    • Avant de finaliser la spécification, beaucoup de tests ont été menés pour vérifier qu’activer MPTCP ne cassait pas la connectivité
      Il fallait soit que ça passe correctement, soit que ça retombe proprement sur du TCP à chemin unique
      En général, si un équipement intermédiaire laisse passer les options inconnues sans les modifier, et n’exige pas que l’espace de séquence TCP qu’il observe soit continu, MPTCP peut fonctionner à travers lui
      Si cela vous intéresse, il y a deux articles à ce sujet
      [1] https://www.usenix.org/conference/nsdi12/technical-sessions/...
      [2] https://www.researchgate.net/publication/229002024_Is_it_sti...

  • Cela peut aider dans des configurations de sécurité et de confidentialité
    Par exemple, avec le Great Firewall chinois, si le trafic peut être réparti sur plusieurs canaux d’uplink, ne devient-il pas plus difficile pour le pare-feu de le réassembler et d’appliquer ses règles ?

    • S’il ne reconnaît pas le trafic, il suffit de le bloquer ou de le limiter très fortement