MPTCP un standard en cours de rédaction (et déjà bien avancé) à l’IETF. L’acronyme signifie MultiPath TCP dont le but est de pouvoir utiliser une même connexion TCP au travers de plusieurs interfaces réseau. Le cas typique d’utilisation est de décharger les réseaux GSM 3G/4G via le Wi‐Fi, vous pourrez ainsi utiliser le Wi‐Fi (par exemple, via le réseau FON ou votre réseau chez vous) et dès que vous n’êtes plus à portée, passer de façon transparente sur le réseau GSM. Une autre application est le partage de plusieurs liens (par exemple, deux câbles Ethernet) pour un serveur de manière transparente. L’intérêt est d’être totalement transparent pour les applications ; en revanche, il faut une implémentation du côté client et serveur pour que ce soit possible.
Même si le standard est en cours d’écriture, il est déjà possible de tester la version actuelle grâce une version modifiée du noyau Linux. Malheureusement, comme il faut un serveur qui implémente le standard pour que ça fonctionne, vous ne pouvez tester l’accès qu’avec le site de démo en MPTCP (ou vous devez monter votre propre serveur). Sur le site, vous trouverez aussi une vidéo de démonstration dans laquelle on peut voir la conservation d’une session SSH avec différentes combinaisons d’interfaces Ethernet, Wi‐Fi et 3G.
NdA : merci à galactikboulay pour son aide lors de la rédaction de cette dépêche.
Fonctionnement
Premièrement, il y a une poignée de main — handshake — TCP classique avec le serveur, seulement, le client envoie une option supplémentaire qui signale qu’il est capable de faire du MPTCP, et le serveur doit répondre avec la même option pour que la communication soit possible. Quand le client dispose d’une nouvelle interface (par exemple, parce qu’il vient de se connecter à un réseau Wi‐Fi), il envoie un SYN classique au serveur via cette nouvelle interface avec l’option JOIN. Pour garder le fonctionnement actuel de TCP et pour ne pas introduire de saut dans les numéros de séquence (que certains équipements réseau n’aiment pas), chaque connexion TCP a son propre numéro de séquence, mais un numéro de séquence global est ajouté dans les options TCP pour reconstruire les messages qui passeraient par les deux interfaces. Garder les numéros de séquence par interface permet de détecter sur quelle interface les paquets sont perdus, et donc d’établir une fenêtre de congestion par interface.
La gestion de la congestion sur MPTCP a pour but que le débit effectif soit au moins aussi bon que le débit maximal sur la meilleure interface. Pour cela, une fenêtre de congestion est gardée pour chaque lien, et, pour chaque ACK, la fenêtre est augmentée d’une certaine valeur (calculée pour permettre une équité avec le trafic TCP normal et le chemin avec le moins de RTT) divisée par la somme de la valeur de toutes les fenêtres disponibles. Pour chaque DROP, la fenêtre est diminuée de la fenêtre de congestion de l’interface divisée par deux (comme pour TCP). Ceci fait que si deux interfaces ont des performances semblables, elles seront toutes les deux utilisées.
L’explication ci‐dessus est une simplification du fonctionnement ; en réalité, c’est un peu plus complexe, car il faut y ajouter une certaine couche de sécurité pour que n’importe qui ne puisse pas se joindre à une connexion MPTCP.
Il est évident que pour les courtes connexions TCP (quelques paquets échangés), MPTCP n’est pas utile, puisque qu’il faut ajouter une deuxième poignée de main TCP (qui ne peut commencer qu’après la fin de la première, car il faut utiliser la commande JOIN). Il y aura sûrement des ajustements à faire dans les implémentations pour déterminer quand cela vaut la peine d’utiliser plus d’une interface pour une connexion.
La différence par rapport à l’agrégation de liens Ethernet — channel bonding —, que la couche réseau ne voit que comme un seul lien, est de pouvoir utiliser des chemins différents par interface, et donc de pouvoir dynamiquement privilégier l’interface avec le moins de problèmes de congestion.
Aller plus loin
- Working group IETF sur MPTCP (333 clics)
- Implémentation MPTCP pour Linux (572 clics)
# Présentation au FOSDEM 2012
Posté par ahuillet (site web personnel) . Évalué à 10.
MPTCP a fait l'objet d'un lightning talk au FOSDEM 2012.
Le PDF et la vidéo sont disponibles à l'adresse suivante : https://archive.fosdem.org/2012/schedule/event/multipathtcp.html
La présentation, 15 minutes, était très intéressante.
[^] # Re: Présentation au FOSDEM 2012
Posté par matttbe (site web personnel) . Évalué à 4.
Il y avait également une présentation en français et peut-être plus vulgarisée lors de la Foire du Libre de Louvain-la-Neuve (par le Louvain-li-Nux) ;)
La vidéo est disponible à cette adresse: https://www.youtube.com/watch?v=j1ySqu7_wCA
[^] # Re: Présentation au FOSDEM 2012
Posté par Big Pete . Évalué à 3.
Une prez aussi ici : how hard can it be designing and implementing deployable multipath TCP- NSDI 12 Elle insiste sur les difficultés de l'implémentation et le problème posé par les middleboxes.
Une alternative, plus expérimentale, plus complexe aussi dans son déploiement mais de mon point de vue plus élégante car elle adresse directement le problème de la séparation entre le nommage et l'adresse des services et pourrait ouvrir des perspectives vraiment intéressantes pour le load-balancing : Serval qui a été aussi présenté au NSDI 12.
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
# RFC 6182
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 10.
Le groupe de travail a déjà sorti un RFC d'architecture : http://www.bortzmeyer.org/6182.html
[^] # Re: RFC 6182
Posté par obo . Évalué à 2.
L'IESG a accepté aujourd'hui de publier le RFC du protocole. Moyennant quelques détails cosmétiques, le RFC sera le dernier draft officiel
# Je sens que je vais me faire traiter de troll mais ...
Posté par Kaane . Évalué à 9.
Quand je lis les specs du MPTCP je n'arrive pas à me sortir de la tête que c'est juste une façon d'obtenir la même chose qu'avec de l'IPv6 Mobile mais sans passer à IPv4.
Je suis bien conscience qu'il y a des différences au niveau du protocole (je connais la dissociation IP/TCP) mais bon, IPv6 mobile était un truc qui devait permettre de rerouter rapidement (et à la volée) une machine (bon OK une interface) qui se déplace sur différents réseaux. MPTCP permet de faire la même (suivre un déplacement sur différent réseaux) chose au niveau connexion/session plutôt qu'au niveau machine.
Le premier problème que je vois est celui du double emploi - grosso-modo 80% des cas d'application de IPv6 mobile sont couverts par MPTCP (c'est à dire en pas se faire jeter et ne pas avoir à se réauthentifier en cas de changement de réseau).
Après pour les cas suivants (être capable de retrouver une machine ou qu'elle soit sur les réseau) il suffit d'écrire un petit démon qui balance un paquet de temps en temps pour permettre le seuivi. (une fosi qu'on aura les bonnes libs MPTCP ce petit démon devra peser dans les 50 lignes de codes et sera probablement donné en exemple dans la lib elle même).
Le second problème que ca pose est celui du déploiement. Le gros avantage d'IPv6 mobile (connexion continue avec un appareil mobile) est en train de partir à la poubelle. A partir de là on peut légitimement se demander si les opérateurs veront un interêt quelconque à déployer IPv6 mobile :Dans un cas j'achète du matos, je fais des tables de routages dynamiques et modifiées plusieurs fois par seconde si j'ai beaucoup de client, dans l'autre je met à jour le firmware de l'existant et je reste en v4 (Je veux pas être méchant mais le choix est vite fait…) Or si les opérateurs mobiles déploient MPTCP à la place de IPv6 mobile - on peut considérer que la norme IPv6 mobile est morte (non pas qu'elle soit super vivante en ce moment, ni qu'elle l'ait jamais été. Déjà IPv6 tout court…)
Le troisième problème que ca pose est celui du hack TCP pour pas passer en IPv6. Il y a 5 ou 6 ans je racontais en rigolant devant un commité d'experts ( https://linuxfr.org/board ) que les boites ne passeraient jamais en IPv6 (trop couteux et pas rentable du tout pour les premiers à faire le pas) et qu'on aurait à la place des hacks TCP qui permettrait de passer de 65536 ports à 16 millions. Comme ça NAT pour tout le monde et on en parle plus. C'était rigolo à l'époque - mais aujourd'hui ca me fait plus rire.
Donc si quelqu'un peut me dire que je me trompe (avec argument à l'appui - les one-liners "tu te trompes" et les "comment peut-on être assez @"!ù!! pour croire que" s'abstenir) ca me rassurerait. Je souhaite sincèrement être passé à coté d'une fonction IPv6 qui ne soit implémentable en 100 lignes de codes avec mptcp.
[^] # Re: Je sens que je vais me faire traiter de troll mais ...
Posté par Kerro . Évalué à 10.
Je ne connais pas bien IPv6 mobile, mais je crois que ça ne permet d'utiliser qu'un seul chemin à la fois. Me corriger si erreur.
MPTCP permet de passer par plusieurs liaisons en même temps. Par exemple j'ai 2 liaisons ADSL, je cumule les débits.
[^] # Re: Je sens que je vais me faire traiter de troll mais ...
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 7.
Tout à fait et c'est pour cela que la comparaison avec IPv6 Mobile est erronée. Mais c'est la faute de l'article original qui, curieusement, mettait davantage l'accent sur la résilience (que SCTP fournit déjà) plutôt que sur la répartition de trafic.
[^] # Re: Je sens que je vais me faire traiter de troll mais ...
Posté par Kaane . Évalué à 2.
Tout à fait et c'est pour cela que la comparaison avec IPv6 Mobile est erronée.
Le problème est que je ne vois pas comment on peut faire des sources mutiples seulement avec de protocole MPTCP. Il va quand même bien falloir modifier les middle box ET les applis pour prendre en compte un changement d'IP.
Parceque mon appli quand elle va répondre à une demande, elle va le faire en "décidant" quelle est la bonne IP pour cette session.
Autant en IPv6 mobile avec mon IP qui se balade (voire qui est présente sur deux réseaux) - tout le niveau décisionnel va être géré par les routeurs. A partir de là mon appli se moque complètement de savoir si c'est une adresse IPv6 standard ou une appli IPv6 mobile. L'intelligence de routage se fait plus tard.
Par contre sur MPTCP il faut que mon appli sache que telle ou telle session correspond à X adresses IP. (Ou alors uen fois de plus qu'il y ait un proxy/daemon MPTCP qui fasse de la traduction d'adresse et qui fasse le load balancing).
[^] # Re: Je sens que je vais me faire traiter de troll mais ...
Posté par claudex . Évalué à 4.
Non, l'appli ne décide pas de répondre en fonction de l'IP, elle décide de le faire sur une socket TCP (je rappelle que MPTCP n'a d'intéret que pour les connexion qui durent un peu).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Je sens que je vais me faire traiter de troll mais ...
Posté par Florent Fourcot . Évalué à 7.
Ben en fait non, il n'y a pas besoin de modifier grand chose.
Tu ouvres ta connexion avec une socket TCP qui passe par l'interface eth0. Ton appli détecte donc cette adresse comme d'habitude, si vraiment elle en a besoin. Ensuite tu rajoutes une seconde interface Wlan0 pour regarder ta vidéo youtube par le WiFi du voisin qui a un abonnement chez chez un FAI avec un lien vers Google pas trop congestionné. Ton appli ne voit rien, c'est fait au niveau du noyau, sur la couche TCP. Et toi tu es content tu vois ta vidéo plus vite en congestionnant deux interfaces à la place d'une seule, merci Kernel. Et ton application, elle n'a vraiment pas à le savoir. Regarde la RFC, l'idée est justement que l'API ne change absolument pas et que tout reste compatible avec l'existant. Du côté serveur, même problématique, si ton application veut vraiment identifier quelqu'un avec son IP celle utilisée lors de l'initialisation sera présentée.
J'ai pas regardé pour les middleboxes et la gestion du NAT. Mais vraiment rien à voir avec de l'IPv6 mobile (qui est certes une bonne idée), c'est pas la même problématique.
[^] # Re: Je sens que je vais me faire traiter de troll mais ...
Posté par obo . Évalué à 4.
Multipath TCP a été conçu pour pouvoir passer à travers différents types de middleboxes. Une bonne source pour comprendre les problèmes posés à l'extensibilité de TCP par les middleboxes est l'article de Micchio Honda et al. Is it still possible to extend TCP ?. Le design de Multipath TCP prend en compte les middleboxes détectées dans cet article. L'article How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP explique les principes du design de Multipath TCP et de son implémentation dans le kernel Linux qui est actuellement l'implémentation la plus avancée.
[^] # Re: Je sens que je vais me faire traiter de troll mais ...
Posté par obo . Évalué à 2.
L'application n'est pas informée des changements d'adresses IP et continue à fonctionner sans aucun problème. L'article Exploring Mobile/WiFi Handover with Multipath TCP décrit en détails les performances de l'implémentation de Multipath TCP sous Linux dans un environnement WiFi/3G
[^] # Re: Je sens que je vais me faire traiter de troll mais ...
Posté par karteum59 . Évalué à 6. Dernière modification le 29 octobre 2012 à 16:19.
Rappelons tout de même que faire fonctionner simultanément deux interfaces radio dans un terminal mobile (e.g. Wi-FI@2.4 GHz et LTE@2.6 GHz) ne va pas sans poser quelques contraintes sur la gestion des interférences et sur la durée de vie de la batterie.
[^] # Re: Je sens que je vais me faire traiter de troll mais ...
Posté par benoar . Évalué à 4.
Erreur, ça peut la faire avec MCoA (Multiple Care-of Addresses), RFC 5648. Après, l'implémentation n'est pas ce qu'il y a de plus génial (des patchs pas remontés upstream pour UMIP).
[^] # Re: Je sens que je vais me faire traiter de troll mais ...
Posté par galactikboulay . Évalué à 5.
Juste une petite remarque: MPTCP n'est pas exclusif à IPv4, ça supporte IPv6 également (voir le message ADD_ADDR). Si j'ai bien compris le draft, une connexion devrait même pouvoir utiliser des adresses IPv4 et IPv6 en même temps.
[^] # Re: Je sens que je vais me faire traiter de troll mais ...
Posté par Maclag . Évalué à 2.
Tu te trompes, et j'ai un argument en appui:
ARGUMENT
/\ …../\ …. /\
Il tient rudement bien!
---------------> [ ]
[^] # Re: Je sens que je vais me faire traiter de troll mais ...
Posté par Sytoka Modon (site web personnel) . Évalué à 6.
IPv6 Mobile est mort avant même de commencer. Je n'ai jamais cru en cette usine à gaz et le peu que j'en ai compris, il ne marchera jamais à grande échelle. C'est comme le multicast, cela ne franchira jamais les routeurs centraux… pour des questions de sécurité.
D'ailleurs, il me semble que RENATER à coupé le multicast il y a peu en interne sur son réseau.
Je pense au contraire que ce nouveau protocole est pensé en fonction de l'existant et qu'il a toutes les chances d'être enfin utilisé. En effet, ce n'est qu'une simple couche au dessus de TCP. On devrait donc pouvoir basculer d'un réseau d'un opérateur vers un autre de manière transparente car si j'ai bien compris, c'est 'en gros' un multiplexage de deux (ou plus) connexions TCP coté client et serveur mais cela ne touche pas la couche routage et commutation finale.
Bref, un protocole qui me semble enfin sensé ;-)
[^] # Re: Je sens que je vais me faire traiter de troll mais ...
Posté par Christophe Turbout . Évalué à 2.
Le protocole IPV6 mobile n'est pas tant une usine à gaz que ça, ce n'est pas si compliqué.
en 2005 et 2007 on avait testé IPV6 mobile. La principale difficulté à l'époque était que les routeurs existants implémentaient des versions de drafts différents donc incompatibles … Pour la partie ipsec et l'échange de clé, il faut avouer que c'était plutôt light niveau sécurité, mais sinon ça fonctionnait.
En interne, dans une grande boîte ou une fac, ça résoud plein de problèmes concrets de personnes mobiles entre plusieurs sites.
[^] # Re: Je sens que je vais me faire traiter de troll mais ...
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Lesquelles ?
Les personnes veulent pouvoir avoir tout depuis n'importe ou !
Moi, il me faudrait pour les utilisateurs IPv6 mobile entre mon laboratoire et leur boite ADSL… Et ça, cela ne marchera jamais.
Donc, en pratique, on monte nos services différemment avec ce genre de contrainte.
# En parlant de TCP...
Posté par cosmocat . Évalué à 6.
Coded TCP :
Comment augmenter le débit jusqu'à 10x en évitant les retransmissions des paquets perdu. En (très) gros, le client les reconstitue en résolvant des équations algébriques simples…
http://hardware.slashdot.org/story/12/10/23/1946248/increasing-wireless-network-speed-by-1000-by-replacing-packets-with-algebra
[^] # Re: En parlant de TCP...
Posté par neologix . Évalué à 6.
Oui, enfin uniquement sur des réseaux wifi (802.11 and co), il faut le préciser…
C'est bien connu que TCP pose problème sur les réseaux sans-fil, c'est d'ailleurs pour cela qu'il y a dans 802.11 un mécanisme de retransmission au niveau LLC qu'il n'y a pas pour ethernet.
Le wifi c'est juste pourri, avec un peu de chance ça disparaîtra avec la 4G et la femto.
[^] # Re: En parlant de TCP...
Posté par slubman (site web personnel, Mastodon) . Évalué à 7.
Alors que je suis « chez moi », pourquoi je passerais par l’internet publique pour joindre des équipements chez moi, sachant que les accès 3G sont souvent NATtés ?
Alors que je suis « chez moi », pourquoi j’utiliserais un accès dont l’utilisation est limitée (3Go pour les plus gros forfaits, avant réduction du débit) ?
Le wifi est peut-être pourri, mais il n’est pas soumis à ces contraintes.
[^] # Re: En parlant de TCP...
Posté par ckyl . Évalué à 3.
Pour 20 euros t'as un câble Ethernet de 30m ;)
[^] # Re: En parlant de TCP...
Posté par SidStyler . Évalué à 4.
J'ai beau chercher, je trouve pas de prise Ethernet sur mon smartphone.
Ceci dit, tu n'as pas tort concernant le Femto, si ça peut permettre de rester sur son réseau local sans devoir passer par les relais de l'opérateur, je prend.
[^] # Re: En parlant de TCP...
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 29 octobre 2012 à 20:10.
Je ne vois pas le rapport : chez toi 30m c'est cool, mais moi avec mes aller-retour dans les pièces, ben ça s’emmêle (surtout qu'on a chacun notre PC portable dans la maison), et puis c'est loin d'être beau en plus d'être pas trop pratique.
Je ne sais pas ce que tu as contre le Wifi, mais il fait ce qu'on lui demande, pas "pur", mais bon, c'était aussi l'argument contre Ethernet qui était pas pur par rapport à ATM par exemple ou d'autres avant, tout comme IP et encore plus TCP (rigolo : toujours le plus "mal conçu" qui attire ;-) )
[^] # Re: En parlant de TCP...
Posté par BAud (site web personnel) . Évalué à 2.
euh, on ne va pas ressortir les arguments contre ATM (latence induite du découpage en paquets de 53 octets…), utilisation pour l'ADSL alors que c'était soi-disant pour de la vidéo ou de l'audio avec latence faible (QoS non tenue…). Bref, ATM c'est aussi beau que X25 àmha, sur le papier.
[^] # Re: En parlant de TCP...
Posté par Zenitram (site web personnel) . Évalué à 2.
Justement, c'est la où je voulais en venir ;-).
Le wifi ça pue beaucoup, mais ça pue moins que toutes les autres technologies proposées.
[^] # Re: En parlant de TCP...
Posté par BAud (site web personnel) . Évalué à 3.
bon, on peut citer ISDN alors :) (quelle arnaque… le truc qui devait apporter la domotique avec gestion du téléphone, de la zik dans toute la maison, de la vidéoconférence pour tous et partout, ce qui aurait pu sauver le minitel, mais faut croire que les expérimentations à Marseille n'ont pas suffit :/). Oui c'est très 90, toussa…
[^] # Re: En parlant de TCP...
Posté par Zenitram (site web personnel) . Évalué à 4.
Ah l'ISDN, si tu veux parler des vieilleries… Ben ça dépend les pays! les allemands n'avaient pas le minitel, mais avaient l'ISDN! Du coup, quand les français avait leur pauvre 56K qui n'allait pas si vite que ça et qui coupait souvent + 30 bonnes seconds pour se connecter, les allemands avaient l'ISDN avec un vrai 64K avec connexion en moins de 1 seconde + 2 ou 3 numéro de téléphone (très pratique pour les colocs) pour pas cher.
Pas une "arnaque", mais plutôt FT qui ne voulait pas vraiment tuer sa poules aux oeufs d'or ;-).
[^] # Re: En parlant de TCP...
Posté par oinkoink_daotter . Évalué à 2.
Parce que FT ne se sucrait pas joyeusement sur l'ISDN peut-être ?
[^] # Re: En parlant de TCP...
Posté par Zenitram (site web personnel) . Évalué à 2.
l'ISDN, c'est "Internet", tu payes la connexion un prix fixe par minute, le minitel c'était lent (ça dure plus longtemps donc paye plus) et bonus tu peux faire différents prix, dont des très très cher, par site avec facturation directe. Le Minitel, c'était du bonheur :).
[^] # Re: En parlant de TCP...
Posté par BAud (site web personnel) . Évalué à 3.
L'ISDN en France ça a donné Numeris (by FT, made in France toussa). Une ligne dédiée donnant du 64 kbits/s voire 128 kbits/s (entre le choix A ou B) et la possibilité de ne pas disposer de l'ADSL par la suite :) c'était géré par deux entités différente et l'adsl n'avait bien sûr pris en compte que pour le grand public (sans parler du SDSL avec une éligibilité aléatoire pour les professionnels et un coût d'entrée à +3k € limite prohibitif tout de même, sans garantie que cela fonctionne :/).
Ce que je pointais, c'est le S de ISDN, ce sur quoi tu n'as pas répondu (oui du réseau ça peut servir à tout, être utile ce serait déjà mieux).
[^] # Re: En parlant de TCP...
Posté par oinkoink_daotter . Évalué à 2.
Facturé au temps par canal pour l'accès à internet 128k = 2x facturation de 64k. Miam :-)
[^] # Re: En parlant de TCP...
Posté par oinkoink_daotter . Évalué à 2.
My bad, je me suis ptet mal exprimé. Par ISDN j'entendais bien numéris et donc sans accès à l'internet qu'il fallait prendre par ailleurs (et facturé par canal).
[^] # Re: En parlant de TCP...
Posté par MTux . Évalué à 8.
ipv4 c'est nul
le wifi c'est nul
TCP c'est nul
Ben didonc à ce train là on va tous revenir en 56k.
[^] # Re: En parlant de TCP...
Posté par Zenitram (site web personnel) . Évalué à 1.
Ah mais non, 56K c'était déjà pas pur, avec plein de hacks immondes, c'était du "mensonge" tout ça.
A la limite 33.6K…
[^] # Re: En parlant de TCP...
Posté par calandoa . Évalué à 7.
Euh, je veux croire que le Wi-Fi c'est pourri par rapport à Ethernet, mais si t'imagines avoir de meilleurs performances avec la 4G tu risques d'être déçu…
[^] # Re: En parlant de TCP...
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 2.
Coded TCP est une idée géniale : quand le lien est mauvais (perd des paquets), ajouter des données (ben oui, ya pas de miracles, les codes correcteurs d'erreurs fonctionnent en ajoutant de la redondance).
[^] # Re: En parlant de TCP...
Posté par SidStyler . Évalué à 0.
Il est vrai que le principe peut faire sourire, mais si l'efficacité est là, c'est tout ce qui compte non ?
[^] # Re: En parlant de TCP...
Posté par reno . Évalué à 2.
Donc Coded TCP fonctionne sur le principe des codes correcteurs d'erreurs, tu peux m'expliquer ce qu'il y a de génial la dedans?
[^] # Re: En parlant de TCP...
Posté par ziliss . Évalué à 1.
Je ne connais pas bien le sujet, mais j'imagine que si on a une bonne estimation du taux d'erreur, on peut directement envoyer suffisamment de données supplémentaires afin que les données perdues puissent être reconstituées sans avoir besoin de redemander les données. Cela évite donc de perdre du temps et des aller-retours.
Je pense que le plus important est de réussir à avoir une bonne estimation du taux d'erreur:
- estimation trop basse, et il faudra redemander de renvoyer les données.
- estimation trop élevée et il y aura de la perte de bande passante.
Il faudrait donc voir ce que cela donne dans la réalité, mais je crois qu'il y a un bon potentiel.
[^] # Re: En parlant de TCP...
Posté par Michaël (site web personnel) . Évalué à 1.
Dans la réalité cela multiplie par 10 le débit de certaines connnections… tu as lu le texte?
[^] # Re: En parlant de TCP...
Posté par Batchyx . Évalué à 3.
Ce que ça montre, c'est ce l'on savait depuis longtemps : TCP sur Wi-Fi ça pue. Je suis sur que tu peux faire du ×6 si tu jarte les mécanismes de congestion de TCP.
Là ou c'est potentiellement intéressant, c'est sur des liens de merde avec 10% de pertes ou plus. Sauf que généralement, des protos naifs comme DHCP commencent déjà à merder sur ces réseaux …
[^] # Re: En parlant de TCP...
Posté par ziliss . Évalué à 1.
Pas eu le temps, mais merci pour l'info.
[^] # Re: En parlant de TCP...
Posté par ahuillet (site web personnel) . Évalué à 0.
Est-ce que tu as une source qui explique en quoi c'est une bonne ou mauvaise idée ? Tout ce que j'ai lu c'est une partie du papier qui était bien plus long et compliqué que le temps que je souhaite passer sur cette question :)
Peut-être que tu prévois de vulgariser un peu le débat ?
[^] # Re: En parlant de TCP...
Posté par karteum59 . Évalué à 5.
En fait, les technologies radio font à peu près toutes déjà ça (elles adaptent leur modulation et taux de codage (donc le débit) en fonction de la qualité du lien radio : par exemple, en QPSK-1/2, le 1/2 signifie bien qu'on consomme la moitié du débit physique en redondance liée au codage canal), et HARQ sert aussi à fiabiliser autant que possible le lien L2 car malheureusement TCP n'aime pas du tout les pertes de paquets (qu'il interprête comme de la congestion).
[^] # Re: En parlant de TCP...
Posté par calandoa . Évalué à 2.
Effectivement, dans le Wi-Fi, il existe un encodeur convolutionnel basé sur l'algorithme de Viterbi qui va augmenter la taille des données pour améliorer la robustesse de la transmission. Par exemple, pour le a et g, chaque paire de rates 6 et 9, 12 et 18, 24 et 36, 48 et 54, utilisent la même modulation physique, mais avec un taux de codage plus ou moins redondant/robuste (1/2, 2/3 ou 3/4).
La différence, c'est que la redondance ne s'opère que sur quelques bits et en continue. Si la première moitié d'un paquet est parfaite et la seconde manquante, c'est mort. Alors que Coded TCP semble fonctionner en ajoutant des paquets entier, ce qui permet de récupérer après des interférences beaucoup plus importantes.
[^] # Re: En parlant de TCP...
Posté par karteum59 . Évalué à 2.
Non, le système adapte aussi la taille de la constellation QAM (QPSK, 16QAM ou 64QAM. Dans le cas du 802.11ac, cela va même jusqu'à la 256QAM). C'est la même chose en WiMAX et LTE.
Je ne connais pas le détail du codage canal employé en wi-fi, mais ce dernier s'arrange pour assurer une résilience au niveau trame (en plus du codage canal, il y a aussi un mécanisme de CRC et ARQ afin que les trames ne recevant pas de ACK soit retransmises par l'émetteur sans passer par TCP). C'est aussi la raison pour laquelle le multicast est assez pourri en wi-fi (tout le monde utilise la même modulation i.e. la plus basse, et il n'y a pas d'ARQ…)
[^] # Re: En parlant de TCP...
Posté par calandoa . Évalué à 3.
C'est ce que je disais, mais ça manquait peut être de clarté… plus précisément : BPSK : 6 et 9, QPSK : 12 et 18, 16-QAM : 24 et 36, 64-QAM : 48 et 54 ; la différence dans chacune des paires étant due au Viterbi.
Il y a effectivement un système de retransmission en Wi-Fi dans le cas normal, en plus de la redondance du Viterbi, mais je me demande si il n'est pas désactivé dans le cas du Coded TCP (cela peut se configurer avec certains AP qui font de la QoS). J'ai lu en diagonale les articles et papiers sur cette technologie, et je ne réussis pas à comprendre si la modification est seulement faite au niveau de la stack TCP ou aussi dans la configuration du Wi-Fi. Parce que les auteurs n'en parlent pas, j'aurais tendance à penser qu'il s'agit de Wi-Fi normal, mais quitte à vouloir booster les performances de TCP, autant supprimer le système d'ACK du Wi-Fi qui est redondant avec celui de TCP, et qui ajoute beaucoup de latence à cause du système anti-collision (le délai d'attente à chaque retransmission est en gros doublé tant que le paquet ne passe pas).
# MPTCP fera-t-il mieux que SCTP ?
Posté par porki . Évalué à 6.
Je fondais beaucoup d'espoirs dans SCTP. Cela devait être l'union de TCP et UDP, gardant les avantages de chacun sans les inconvénients, sans compter quelques nouveautés intéressantes (protections contre les SYN flooding, multi-homing, …). SCTP est supporté par de nombreux systèmes d'exploitation. L'utilisation des sockets SCTP est aussi simple que pour TCP ou UDP. Il avait tout pour mettre la patée à TCP et pourtant il n'est toujours pas très présent dans les nouveaux développements applicatifs. MPTCP sera encore mieux, mais est-ce pour autant qu'il ne connaîtra pas le même sort ? J'ai l'impression que TCP et UDP seront aussi tenances pour la couche 4 qu'IPv4 pour la couche 3 (voir plus !).
[^] # Re: MPTCP fera-t-il mieux que SCTP ?
Posté par Florent Fourcot . Évalué à 4.
L'énorme différence entre SCTP et MPTCP, c'est que MPTCP ne nécessite pas de mises à jour des applications, on a l'impression d'utiiser du TCP classique. Comme tout se passe au niveau du noyau et que l'API des sockets reste la même, il n'y a pas de raisons que ce ne soit pas déployé (une mise à jour du noyau et hop).
Pour SCTP, l'API pour ouvrir les sockets n'est pas la même (simple d'accord, mais différente). Que les systèmes d'exploitations fonctionnent avec ne suffit pas, car il y peu de chances que les développeurs d'applications se lancent massivement dans son utilisation (car ils ne connaissent pas/mal (les développeurs, c'est rarement des pros du réseau), car ils n'en voient pas l'intérêt, car c'est pas compatible avec tel soft, car il faut de toute façon qu'ils codent en TCP pour l'universalité et que ça donnerait deux fois plus de boulot…).
[^] # Re: MPTCP fera-t-il mieux que SCTP ?
Posté par galactikboulay . Évalué à 3.
Je ne suis pas spécialiste de SCTP, mais comme c'est "à part" de TCP et d'UDP (n° de protocole IP différent), je doute que ce soit très bien géré par tous les firewalls ou des routeurs faisant du NAPT.
[^] # Re: MPTCP fera-t-il mieux que SCTP ?
Posté par Florent Fourcot . Évalué à 3.
Là-dessus je ne suis pas certain qu'ils réagiront beaucoup mieux quand du MTCP passera sans prévenir, c'est pas non plus du TCP complètement standard pour la création du contexte.
[^] # Re: MPTCP fera-t-il mieux que SCTP ?
Posté par galactikboulay . Évalué à 3.
Normalement (bon je parierais pas ma vie non plus là dessus), ça devrait mieux fonctionner: les auteurs du draft ont pris en compte le NAT dès le départ, et les éléments spécifiques à MPTCP passent sous forme d'options TCP. Et a priori, si la connexion ne passe pas, il y a un fallback sur du TCP standard, ce qui a le mérite de ne pas tout casser.
[^] # Re: MPTCP fera-t-il mieux que SCTP ?
Posté par claudex . Évalué à 4.
Les serveurs et les clients étant tout à fait compatible avec les serveurs et clients n'utilisant que TCP, c'est beaucoup plus facile à déployer.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: MPTCP fera-t-il mieux que SCTP ?
Posté par claudex . Évalué à 7.
Une autre différence avec ce qui est cité plus haut est que j'ai entendu que des société comme Google sont intéressé pour l'implémenter dans leur datacenter (pour amélioré les performances) et des opérateurs GSM sont intéressés de l'implémenter dans les appareils qu'ils vendent pour décharger le réseau 3G avec un WiFi partagé par les box. Il y a donc déjà pas mal de promoteurs pour une spec pas encore finie.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: MPTCP fera-t-il mieux que SCTP ?
Posté par obo . Évalué à 3.
Il existe un port de Multipath TCP sur Android qui tourne sur Samsung Galaxy S2. Voir https://github.com/mptcp-galaxys2
# Implémentation sur FreeBSD
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 6.
Je ne sais pas pour les autres systèmes, mais il y a une implémentation en cours pour FreeBSD : http://caia.swin.edu.au/urp/newtcp/mptcp/ .
# Concrètement, on peut multiplexer deux connexions ADSL ?
Posté par theNouk . Évalué à 2.
question bête: avec une implémentation actuelle de MPTCP:
je me refait un petit kernel sur mon serveur dédié chez OVH qui me sert également de proxy
idem sur mon laptop à la maison
je prends une deuxième ligne téléphonique avec une deuxième connexion ADSL.
Et je n'ai plus qu'à profiter d'une connexion avec un débit double (au mieux), en down comme en up ?
[^] # Re: Concrètement, on peut multiplexer deux connexions ADSL ?
Posté par Kerro . Évalué à 0.
Si tu passes par une machine extérieure, tu auras plus d'intérêt à utiliser l'agrégation de liens qui existe depuis longtemps.
Recherche "linux channel bonding".
[^] # Re: Concrètement, on peut multiplexer deux connexions ADSL ?
Posté par DerekSagan . Évalué à 4.
Le bonding c'est au niveau 2 (ethernet), donc inadapté car les fournisseurs d'accès internet proposent une interface du niveau 3 (IP).
[^] # Re: Concrètement, on peut multiplexer deux connexions ADSL ?
Posté par claudex . Évalué à 4.
Il existe du bonding de ligne ADSL mais il faut que le fournisseur les propose, on ne peut pas se permette d’agréger bêtement deux lignes.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Concrètement, on peut multiplexer deux connexions ADSL ?
Posté par claudex . Évalué à 4.
Le débit doublé uniquement pour les connexions TCP.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Concrètement, on peut multiplexer deux connexions ADSL ?
Posté par Phil_S . Évalué à 4.
MLPPP me semble beaucoup plus adapté :
Ca se passe en dessous de la couche réseau, donc valable aussi pour UDP,ICMP (bon OSEF, OK) et permet l’agrégation de lignes (ADSL,T1,..).
Il faut juste un serveur de chaque côté des lignes (1 chez soi, 1 chez OVH,Free,..) qui fait le boulot.
Il existe une implémentation sous FreeBSD.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.