Multipath TCP pour Linux (2022)

 (mptcp.dev)
1 points par GN⁺ 2024-04-21 | 1 commentaires | Partager sur WhatsApp

Vue d’ensemble de Multipath TCP

  • Multipath TCP (MPTCP) est une extension du TCP standard, décrite dans la RFC 8684
  • Il permet à un appareil d’utiliser simultanément plusieurs interfaces pour envoyer et recevoir des paquets TCP via une seule connexion MPTCP
  • MPTCP peut agréger la bande passante de plusieurs interfaces ou privilégier l’interface offrant la latence la plus faible
  • Il permet aussi le basculement en cas de panne d’un chemin, avec réinjection fluide du trafic sur d’autres chemins

Cas d’usage de MPTCP

  • Le fait de pouvoir utiliser plusieurs chemins en parallèle ou simultanément avec MPTCP ouvre de nouveaux cas d’usage par rapport au TCP :
    • Seamless handovers : passage d’un chemin à un autre sans interrompre la connexion. Apple utilise principalement MPTCP sur ses smartphones pour cette raison depuis 2013.
    • Best network selection : utilisation du chemin « optimal » selon certains critères comme la latence, la perte, le coût ou la bande passante.
    • Network aggregation : utilisation simultanée de plusieurs chemins pour augmenter le débit. Exemple : combiner réseau fixe et réseau mobile pour envoyer un fichier plus rapidement.

Concepts de MPTCP

  • Lorsqu’un nouveau socket est créé avec le protocole IPPROTO_MPTCP (spécifique à Linux), des sous-flux (ou chemins) sont créés à partir de connexions TCP classiques utilisées pour transmettre les données via une seule interface
  • Des sous-flux supplémentaires peuvent ensuite être négociés entre les hôtes
  • De nouveaux champs sont ajoutés au champ des options TCP du sous-flux TCP principal afin que l’hôte distant puisse détecter l’utilisation de MPTCP
  • Parmi eux figure l’option MP_CAPABLE, qui indique à l’autre hôte d’utiliser MPTCP s’il le prend en charge
  • Si l’hôte distant ou une middlebox intermédiaire ne prend pas en charge MPTCP, les options MPTCP n’apparaissent pas dans le champ des options TCP du paquet SYN+ACK retourné
  • Dans ce cas, la connexion est « rétrogradée » en TCP classique et se poursuit sur un seul chemin

Ce fonctionnement est rendu possible par deux composants internes : le Path Manager et le Packet Scheduler.

Path Manager

  • Le Path Manager gère les sous-flux, de leur création à leur suppression, ainsi que l’annonce des adresses
  • En général, le client initie les sous-flux, et le serveur annonce des adresses supplémentaires via les options ADD_ADDR et REMOVE_ADDR
  • À partir de Linux v5.19, il existe 2 Path Managers contrôlés par le paramètre sysctl net.mptcp.pm_type :
    • in-kernel (type 0) : applique les mêmes règles à toutes les connexions (voir ip mptcp)
    • userspace (type 1) : contrôlé par un démon en espace utilisateur (par ex. mptcpd), avec possibilité d’appliquer des règles différentes selon la connexion

Packet Scheduler

  • Le Packet Scheduler a pour rôle de choisir, parmi les sous-flux disponibles, lequel sera utilisé pour envoyer le paquet de données suivant
  • Il peut maximiser l’utilisation de la bande passante disponible, ne sélectionner que le chemin ayant la plus faible latence, ou appliquer d’autres politiques selon la configuration
  • À partir de Linux v6.8, il n’existe qu’un seul Packet Scheduler, contrôlé par les paramètres sysctl de net.mptcp

Principales caractéristiques de MPTCP (à partir de Linux v6.10)

  • prise en charge du protocole IPPROTO_MPTCP dans l’appel système socket()
  • remplacement de MPTCP par TCP si le pair ou une middlebox ne prend pas en charge MPTCP
  • gestion des chemins via un gestionnaire de chemins dans le noyau ou en espace utilisateur
  • options de socket habituellement utilisées avec les sockets TCP
  • fonctions de débogage incluant compteurs MIB, prise en charge de diag (utilisée par la commande ss) et tracepoints

L’avis de GN⁺

  • MPTCP est une technologie très utile lorsqu’un terminal est connecté à plusieurs réseaux. Elle peut être exploitée efficacement pour le handover 5G-Wi-Fi ou l’agrégation de réseaux hétérogènes.
  • Mais cela impose une implémentation côté serveur et côté client prenant en charge MPTCP, ainsi qu’un réseau intermédiaire compatible MPTCP. Sa généralisation prendra probablement du temps.
  • Le protocole QUIC de Google offre aussi des fonctions multipath similaires. Comme QUIC est plus simple et fondé sur UDP, il pourrait se diffuser plus rapidement. Une concurrence entre MPTCP et QUIC est à prévoir.
  • Contrairement à l’implémentation Linux de MPTCP, dépendante du noyau, Apple implémente MPTCP de son côté en espace utilisateur et l’intègre à iOS et macOS. Google pourrait adopter une approche similaire.
  • Pour que le contrôle des chemins et les politiques d’ordonnancement de MPTCP soient optimisés selon les besoins des applications, un échange d’informations via une API entre l’application et MPTCP semble nécessaire. Il ne semble pas encore exister de solution standardisée à ce sujet.

À lire aussi

1 commentaires

 
GN⁺ 2024-04-21
Discussion sur Hacker News
  • Quand j’ai entendu parler de MPTCP pour la première fois en 2013, les applications mobiles géraient encore mal les changements de réseau, donc je pensais que cela aiderait énormément à améliorer l’expérience utilisateur ; il est très décevant de voir que, 10 ans plus tard, cela n’a pratiquement pas attiré l’attention
  • Je ne sais pas lequel est le plus triste entre l’espace d’adressage 32 bits d’IPv4 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 reviendrais en arrière pour changer ces deux choses
  • L’usage pratique de MPTCP, c’est d’utiliser ensemble les réseaux mobile et Wi‑Fi pour augmenter la vitesse, mais à cause de mon forfait data mobile, je le laisse toujours désactivé, donc cela ne m’est d’aucune utilité
  • C’est dommage qu’il n’y ait pas de liens vers des projets qui utilisent MPTCP, comme des dérivés d’OpenWrt. Pendant 2 ans, j’ai encadré au GSOC un étudiant qui patchait la prise en charge de MPTCP dans OpenWrt
  • S’il existe un repli transparent, je me demande pourquoi un opt-in explicite de l’application est nécessaire. Il semblerait plus logique que le kernel le gère de façon transparente pour toutes les connexions TCP, afin de prendre des décisions globales sur l’agrégation de chemins et la préférence de lien
  • En travaillant sur le support, le débogage et la modification de la pile réseau Linux et des pilotes, je suis surpris par le faible taux d’adoption de MPTCP. Comme SCTP, tout ce qui a essayé de remplacer le TCP existant semble destiné à n’être utilisé que par une minorité de développeurs pendant que le reste du monde l’oublie
  • J’ai trouvé un article qui explique les différences d’architecture entre MPTCP et QUIC, ainsi que le protocole MPQUIC proposé par les auteurs. QUIC multiplexe des flux applicatifs sur un unique flux UDP, tandis que MPTCP découpe un flux unique en plusieurs sous-flux TCP. MPQUIC combine les deux fonctions en multiplexant des flux applicatifs sur plusieurs sous-flux UDP
  • Apple prend aussi en charge MPTCP et l’utilise pour Siri
  • Il semble assez contraignant que, si une middlebox intermédiaire ne prend pas en charge les options MPTCP, le paquet SYN+ACK n’inclue pas d’option MPTCP. La seule exigence pour la middlebox est-elle simplement de transmettre l’option MPTCP telle quelle ?
  • MPTCP peut être utile pour les paramètres de sécurité et de confidentialité. Par exemple, si le trafic est réparti sur plusieurs canaux uplink, il devient plus difficile pour le pare-feu du gouvernement chinois de reconstituer le trafic afin de le bloquer