# 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, ...).
En janvier 2013, l'IETF a publié les spécifications de Multipath comme une norme expérimentale dans la RFC 6824.

## 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$^,$ - 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. 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.
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.

## Implémentation

En juillet 2013, le groupe de travail sur MPTCP a signalé cinq implémentations indépendantes de Multipath TCP, y compris l'implémentation de référence dans le noyau Linux$^,$.
Les implémentations actuellement disponibles sont :
* Le noyau Linux (l'implémentation de référence) de l'Université catholique de Louvain,
* FreeBSD (IPv4 uniquement) à partir de Swinburne University of Technology,
* F5 Networks, Inc. BIG-IP LTM,
* Citrix Netscaler,
* Apple iOS 7, publié le 18 septembre 2013 est la première application à grande échelle de déploiement commercial de Multipath TCP.
* Apple Mac OS X 10.10, publié le 16 octobre 2014.
* 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$^,$.
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.
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.

## 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.
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$^,$.

### Description simplifiée

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) ;
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
* L'algorithme wVegas de contrôle de congestion basé sur le délai
* L'algorithme de link increase équilibré

## 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.
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.

### 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).
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.
Les schémas d'accès parallèles 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)