Multipath TCP

Multipath TCP (MPTCP) est un effort continu du groupe de travail sur Multipath TCP de l'Internet Engineering Task Force (IETF) qui vise à permettre à  TCP d'utiliser plusieurs chemins d'accès afin de maximiser l'utilisation des ressources et l'augmentation de la redondance tout en restant compatible avec les équipements actuels (firewall, NAT, ...)^[1].

En janvier 2013, l'IETF a publié les spécifications de Multipath comme une norme expérimentale dans la RFC 6824^[2].

Avantages

La redondance offerte par Multipath TCP rend accessible le multiplexage inverse de ressources, ce qui permet d'améliorer la cadence (throughput) de TCP jusqu'à atteindre la somme des cadences en profitant des performances des différents canaux physiques au lieu de n'en utiliser qu'un seul, comme c'est le cas en TCP standard. Multipath TCP est en plus rétro-compatible avec le TCP classique. 

Multipath TCP est particulièrement utile dans le contexte des réseaux sans fil ^[3],[4] - une utilisation particulièrement intéressante est de profiter simultanément d'une connexion Wi-Fi et d'un réseau de téléphonie mobile.

Outre les gains en débit de multiplexage inverse, des liens peuvent être ajoutés ou supprimés lorsque l'utilisateur se déplace dans ou hors d'une zone de couverture sans perturber le fonctionnement de bout en bout de la connexion TCP. Le problème de la liaison de transfert intercellulaire est donc résolu par l'abstraction de la couche de transport, sans mécanismes spéciaux à ajouter au niveau de la couche réseau ou de la couche liaison de données . Le transfert intercellulaire peut ensuite être mise en œuvre au niveau des postes clients sans nécessiter une fonctionnalité spéciale dans chaque sous-réseaux , conformément au principe de bout-à-bout utilisé sur internet.

Multipath TCP apporte également des avantages de performance dans les centres de données^[5]. Contrairement à la liaison de canaux Ethernet utilisant l'agrégation de liens (802.3ad), le Multipath TCP peut équilibrer une seule connexion TCP à travers de multiples interfaces^[6].

Multipath TCP présente la même interface utilisateur que TCP. Il modifie TCP de sorte qu'il présente une interface standard pour les applications, alors qu'en fait, la diffusion de données à travers plusieurs subflows, ce qui permet d'utiliser MPTCP de manière transparente^[7].

Implémentation

En juillet 2013, le groupe de travail sur MPTCP a signalé cinq implémentations indépendantes de Multipath TCP^[8], y compris l'implémentation de référence^[7] dans le noyau Linux^[9],[10].

Les implémentations actuellement disponibles sont :

• Le noyau Linux (l'implémentation de référence) de l'Université catholique de Louvain^[7],
• FreeBSD (IPv4 uniquement) à partir de Swinburne University of Technology^[11],
• F5 Networks, Inc. BIG-IP LTM^[12],
• Citrix Netscaler^[13],
• Apple iOS 7, publié le 18 septembre 2013 est la première application à grande échelle de déploiement commercial de Multipath TCP^[14].
• Apple Mac OS X 10.10, publié le 16 octobre 2014^[15].
• OverTheBox d'OVH Télécom, présentée en 2015, est une solution permettant aux utilisateurs d’agréger plusieurs connexions pour sécuriser leur accès à Internet et démultiplier leur bande passante^[16],[17].

En juillet 2014, Oracle rapporte qu'une mise en œuvre sur Solaris est en cours d'élaboration. En juin 2015, le travail est toujours en cours^[18].

Au cours de la réunion du groupe de travail sur MPTCP à l'IETF 93, SungHoon Seo a annoncé que KT avait déployé depuis la mi-juin, un service commercial qui permet aux utilisateurs de smartphones, d'atteindre un débit de 1 Gbit/s à l'aide d'un service de proxy utilisant MPTCP sur un smartphone Samsung Galaxy S6 avec le système d'exploitation Android^[19].

Structure d'un segment TCP

La structure d'un segment multipath TCP est décrite en détail dans la RFC 6824.

Les structures de données utilisées par Multipath TCP sont situés dans les champs d'options TCP, dans une option de longueur variable dont l'identifiant est le numéro 30 réservé par l'IANA^[20].

L'option multipath TCP a l'identifiant 30, une longueur variable et un contenu qui commence par un champ de 4 bits, pour lequel l'IANA a créé et la volonté de maintenir un sous-registre intitulé MPTCP Option de sous-types dans le cadre du registre sur Protocole de contrôle de transmission (TCP). Ces sous-type de champs sont définis comme suit :

Valeur	Symbole	Nom	Description
0x0	MP_CAPABLE	Multipath Capable	Indique que la session TCP actuelle supporte MPTCP.
0x1	MP_JOIN	Joindre deux connections	Indique qu'une connexion TCP précédemment établie est un sous-flux de la session MPTCP courante.
0x2	DSS	Numéros de séquences de d'acquittement (à l'aide d'un système de mapping)	Décrit la position et l'acquittement des données dans son ensemble (les numéros de séquence et d'acquittement classiques restent utilisées pour décrire la position dans chaque subflow).
0x3	ADD_ADDR	Ajouter une adresse	Demande d'ajouter une nouvelle adresse à la session MPTCP.
0x4	REMOVE_ADDR	Supprimer une adresse	Supprime une adresse (spécifiée par son identifiant) de la session MPTCP.
0x5	MP_PRIO	Changement de la priorité d'un sub-flow	Change la priorité d'un subflow (par exemple parce qu'un lien comme une connexion 3G implique des coûts d'utilisation).
0x6	MP_FAIL	Définir un lien de secours	Demande de n'utiliser un lien qu'en cas de problème, si les autres liens sont indisponibles.
0x7	MP_FASTCLOSE	Fermeture rapide	Ferme l'ensemble de la session MPTCP (car les signaux RST et FIN servent à fermer les subflows individuellement).
0xf	(PRIVÉ)	Usage réservé pour certains tests

Les valeurs 0x8 par 0xe sont actuellement non-attribuées.

Opérations du protocole

Spécifications détaillées

Le détail des spécifications du protocole est fourni dans la RFC 6824. Plusieurs articles peuvent fournir une introduction au protocole^[21],[22].

Description simplifiée

Différence entre TCP et MPTCP

L'idée de base de multipath TCP est de définir une façon d'établir un lien entre les deux hôtes et pas entre deux interfaces (comme en TCP standard).

Par exemple, Alice a un smartphone avec des interfaces 3G et WiFi (avec les adresses IP 10.11.12.13 et 10.11.12.14) tandis que Bob a un ordinateur avec une interface ethernet (avec adresse IP 20.21.22.23).

Dans une application TCP standard, la connexion doit être établie entre deux adresses IP (TCP définit la source et la destination comme des tuples adresse IP, port). Il n'est donc possible d'utiliser qu'un seul lien. Une application multipath TCP peut tirer profit de l'utilisation des chemins différents (un chemin, aussi appelé sub-flow est une connexion TCP standard entre deux interfaces) pour parler d'Alice à Bob.

Le but des différentes opérations du protocole (définies dans la RFC 6824) sont (parmi autres) :

• pouvoir gérer quand et comment ajouter/supprimer des chemins (par exemple s'il y a une connexion perdue ou fortement congestionnée) ;
• être compatible avec les anciens matériels supportant le TCP classique (tels que certains pare-feu qui peuvent rejeter automatiquement les connexions TCP si les numéros de séquence ne sont pas successifs) ;
• définir un juste contrôle de congestion entre les différents liens et les différents hôtes (surtout  ceux qui ne supportent pas MPTCP par rapport à ceux qui le supportent) ;

Illustration d'une session MPTCP complète

Ceci est fait en ajoutant de nouveaux mécanismes aux transmissions TCP :

• le système de sub-flow est utilisé pour rassembler de multiples connexions TCP standard (qui sont entre deux interfaces). Au cours de la connexion TCP, nous identifions les sous-flux. Lors de la transmission, une application peut ajouter ou de supprimer certains sous-flux (grâce aux sous-type  0x3 et 0x4 défini précédemment) ;
• l'ajout de numéros de séquences et d'acquittement pour les données, dans le  champ d'option pour restituer les données à partir de plusieurs sous-flux dans le bon ordre et sans corruption (sous-type 0x2) ;
• un nouveau système de retransmission est utilisé pour mettre en œuvre le nouveau système de contrôle de congestion tout en rendant le protocole fiable et rapide. 

Contrôle de congestion

Plusieurs mécanismes de contrôle ont été définis pour Multipath TCP. Leur principale différence avec les systèmes de contrôle de congestion TCP classiques est qu'ils ont besoin de réagir à la congestion sur les différents chemins sans être injustes pour les applications qui ne profitent que d'un chemin TCP (car elles ne supportent pas multipath TCP par exemple). Quatre stratégies de contrôle de congestion sont actuellement supportées dans l'implémentation de référence au sein du noyau Linux. 

• L'algorithme du linked increase classique, défini dans RFC 6356
• L'algorithme du linked increase opportuniste^[23]
• L'algorithme wVegas de contrôle de congestion basé sur le délai
• L'algorithme de link increase équilibré ^[24]

Alternatives

Stream Control Transmission Protocol

Stream Control Transmission Protocol (SCTP) est un protocole de transport fiable initialement prévu pour les télécommunications de signalisation. Il prend en charge l'utilisation simultanée de plusieurs liens d'accès et permet à une application d'influencer la sélection des interfaces d'accès à un flux de base. Il prend également en charge de la mobilité via la renégociation d'accès. Par conséquent, SCTP est une autre solution sur la couche de transport au problème de mobilité. Il offre une granularité de type 3 avec concurrence mais avec plus de contrôle du flux que multipath TCP. Il supporte aussi la mobilité d'une manière similaire à Multipath TCP^[25].

Bien que cette alternative puisse paraître très avantageuse, elle se base sur une technologie relativement peu déployée (par rapport à TCP) pour des applications non spécialisées^[26].

IMS SIP

Dans l'architecture du "IP multimedia subsystem (IMS), le Protocole d'initiation de session (SIP) peut prendre en charge l'utilisation simultanée de plusieurs adresses IP de contact pour l'enregistrement d'un ou plusieurs agents utilisateurs IMS. Cela permet la création de plusieurs chemins de signalisation IMS. Sur ces chemins, des messages de signalisation portant un message Session Description Protocol (SDP) peuvent négocier les flux de données. SDP permet de (re-)négocier des flux d'une session de média sur plusieurs chemins. Cela permet donc d'activer un transport à plusieurs chemins cette fois-ci au niveau de la couche transport (avec granularité des flux et accès concurrents). Une extension à plusieurs chemins du Real-time Transport Protocol (RTP) est actuellement en cours de discussion au sein de l'IETF. Multipath RTP peut offrir de la granularité de flux avec des accès concurrents et de la mobilité (via IMS, la signalisation SDP ou le protocole de contrôle RTP). ^[25]

Cependant, son déploiement à grande échelle pour une utilisation sur tous types de terminaux nécessiterait de grand changements de l'architecture réseau.

D'autres protocoles et expériences

Au niveau de la couche session, le « Mobile Access Router » est un projet expérimenté en 2003 proposant l'agrégation de plusieurs accès sans fil avec des technologies hétérogènes en respectant un équilibrage du trafic transparent vis-à-vis de la performance de chaque technologie^[27].

Les schémas d'accès parallèles^[25] utilisés pour accélérer les transferts en profitant du service d'octet afin d'établir des connexions entre de multiples serveurs qui disposent du même contenu répliqué ne sont pas équivalents à Multipath TCP car ils impliquent une utilisation de la couche application et car ils sont limités à des contenus de taille connue. 

RFC

• RFC 6181 - Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses
• RFC 6182 - Architectural Guidelines for Multipath TCP Development
• RFC 6356 - Coupled Congestion Control for Multipath Transport Protocols
• RFC 6824 - TCP Extensions for Multipath Operation with Multiple Addresses
• RFC 6897 - Multipath TCP (MPTCP) Application Interface Considerations
• RFC 7430 - Analysis of Residual Threats and Possible Fixes for Multipath TCP (MPTCP)

Notes et références

1. (en) « Multipath TCP working group » (consulté le 27 juin 2016)
2. (en) « TCP Extensions for Multipath Operation with Multiple Addresses », Request for comments n^o 6824, janvier 2013
3. (en) Christoph Paasch, Gregory Detal, Fabien Duchene, Costin Raiciu et Olivier Bonaventure, « Proceedings of the 2012 ACM SIGCOMM workshop on Cellular networks: Operations, challenges, and future design - Cell Net '12 », Association for Computing Machinery,‎ 2012, p. 31 (ISBN 9781450314756, DOI 10.1145/2342468.2342476, lire en ligne)
4. (en) « TCP with feed-forward source coding for wireless downlink networks »
5. (en) Raiciu, Barre, Pluntke, Greenhalgh, Wischik et Handley, « Improving datacenter performance and robustness with multipath TCP », Sigcomm,‎ 2011 (lire en ligne)
6. (en) C. Paasch, G. Detal, S. Barré, F. Duchêne et O. Bonaventure, « The fastest TCP connection with Multipath TCP » (consulté le 20 septembre 2013)
7. (en) « The Linux kernel MultiPath TCP project » (consulté le 28 novembre 2014)
8. (en) « Survey of MPTCP Implementations (Internet-Draft, 2013) » (consulté le 20 septembre 2013)
9. (en) Barre, Paasch et Bonaventure, « MultiPath TCP: From Theory to Practice », IFIP Networking,‎ 2011 (lire en ligne)
10. (en) Raiciu, Paasch, Barre, Ford, Honda, Duchene, Bonaventure et Handley, « How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP », Usenix NSDI,‎ 2012 (lire en ligne)
11. (en) « Multipath TCP for FreeBSD v0.1 » (consulté le 23 septembre 2013)
12. (en) « Release Note: BIG-IP LTM and TMOS 11.5.0 », f5 Networks, 30 mai 2014 (consulté le 30 mai 2014)
13. (en) John Gudmundson, « Maximize mobile user experience with NetScaler Multipath TCP », Citrix, 28 mai 2013 (consulté le 20 septembre 2013)
14. (en) « Apple seems to also believe in Multipath TCP » (consulté le 20 septembre 2013)
15. (en) « MPTCP Roams free (by default!) – OS X Yosemite » (consulté le 16 septembre 2015)
16. « Agrégation de liens avec OverTheBox », sur ovhtelecom.fr
17. Hugo Bonnaffé, « Under The Box : découvrez les dessous d’OverTheBox », sur ovh.com, 9 février 2016
18. (en) Shoaib Rao, « Some comments on RFC 6824 » (consulté le 25 juin 2015)
19. (en) « Commercial Mobile MPTCP Proxy service launch »
20. (en) « IANA Protocol Registry TCP Option Kind Numbers » (consulté le 24 septembre 2013)
21. (en) Christoph Paasch et Olivier Bonaventure, « Multipath TCP », Communications of the ACM, vol. 57, n^o 4,‎ avril 2014, p. 51–57 (DOI 10.1145/2578901, lire en ligne)
22. (en) Costin Raiciu, Janardhan Iyengar, Olivier Bonaventure, Hamed Haddadi (dir.) et Olivier Bonaventure (dir.), Recent Advances in Reliable Transport Protocols, ACM SIGCOMM, 2013 (lire en ligne)
23. (en) Ramin Khalili, Nicolas Gast, Miroslav Popovic, Utkarsh Upadhyay et Jean-Yves Le Boudec, « Proceedings of the 8th international conference on Emerging networking experiments and technologies - CoNEXT '12 », Association for Computing Machinery,‎ 2012, p. 1 (ISBN 9781450317757, DOI 10.1145/2413176.2413178)
24. (en) Qiuyu Peng, Anwar Walid, Jaehyun Hwang et Steven H. Low, « Multipath TCP: Analysis, Design and Implementation », Association for Computing Machinery,‎ 2013 (arXiv 1308.3119, lire en ligne)
25. (en) P. Rodriguez et E. Biersack, « Dynamic parallel access to replicated content in the Internet » [archive du 27 septembre 2013], IEEE/ACM Transactions on Networking, 1^er juillet 2002
26. (en) « Why is SCTP needed given TCP and UDP are widely available? », sur isoc.org, 10 septembre 2007 (consulté le 28 juin 2016)
27. (en) R. Chakravorty, I. Pratt et P. Rodriguez, « Mobile Access Router », University of Cambridge, Microsoft Research, 1^er juillet 2003

• Portail de l’informatique