Bonjour à toi, puisses tu être fidèle lecteur ou pas.
Un petit post pour partager quelques expérimentations faites à la va-vite quand à l’optimisation des paramètres MultiPath TCP (via l’interface proposée par OpenWRT/OpenMPTCPRouter).
Voici sans tataouiner, comme diraient nos amis québécois, les résultats:
Alors énorme warning, le protocole ne rend en rien honneur à la rigueur forgée par plusieurs siècles de sciences statistiques (pas de calcul de variance par dimension, pas d’estimation d’incertitude).
Ceci dit, on pourra noter qu’en général un seul paramètre est modifié à la fois, avec 3 tests consécutifs par test. Sauf exception, auquel cas on se retrouve dans une configuration déjà testée (ou.. presque).
Les tests ont été fait de façon groupée, avec des conditions météos similaires (important, car nous parlons d’interfaces 4G).
On force pour tous les runs le serveur speedtest auquel une CLI se connecte pour mesure.
Si l’on souhaite creuser la signification de quelques paramètres MPTCP, il y a la Source (http://multipath-tcp.org/, par les auteurs contribuant dans le noyau Linux, malheureusement pas tout à fait à jour), ainsi que de nombreux blogs/publications que l’on peut dénicher sur le net (http://staff.ustc.edu.cn/~kpxue/paper/Sigcomm2019-p75-Han.pdf, https://www.gitmemory.com/marcschaller, https://hal.sorbonne-universite.fr/hal-01382907v2/document), dont les résultats ont parfois permis de limiter le champs d’exploration pour nos petites expériences (notamment pour la combinatoire des “congestion protocol”, avec certains comme balia, olia ou encore wvegas clairement en retrait dans le cadre de ma double connexion 4g).
Un point intéressant, on pourrait très clairement envisager l’utilisation pertinente (pour une fois 😉 ) d’apprentissage supervisé (reinforcement learning par exemple) pour parcourir de manière non exhaustive la combinatoire, et de converger vers un objectif à définir.
Mais oui, quel est l’objectif?
Dans mon cas (multiplexage de connexions internet 4g pour télétravailler, essentiellement), l’objectif est de minimiser la gigue (aka jitter en anglais) et le ping, pour rendre le plus agréable possible les appels audio et vidéoconférences.
Ensuite, il s’agit de minimiser les pertes de paquets pour éviter de subites pertes de connections SSH ou VPN, par exemple.
Enfin, avec une moindre priorité, de maximer la bande passante en téléchargement (download et upload).
Succinte analyse
Le scheduler “redundant” est à éviter, il provoque un débit quasiment deux fois moindre que ses meilleurs comparses.
Même sentence pour le pathmanager “binder”, il est le seul à être accompagné de systématiques pertes de paquets.
Il serait intéressant de creuser l’impact du nombre de “subflows” par couple d’ip source/destination, même si l’asymptote semble vite atteinte.
Et le gagnant..
était le combo:
path manager: fullmesh
scheduler: ECF (a priori meilleur pour les liens « aériens » comme la 4G)
congestion control: mtcpdesync
avec 2 subflow par pair d’IPs.
Les défauts étant resp. fullmesh/BLEST/cubic.
Mais
Depuis l’écriture originelle de cet article et l’incendie d’OVH qui a obligé une réécriture (rapide, il faut dire) des derniers articles de ce blog, j’ai découvert qu’après quelques heures, cette configuration mettait le VPS à genoux.
Après quelques itérations, en remettant la valeur par défaut au paramètre “fullmesh subflows for each pair of IP addresses”, soit 1, le retour à la stabilité était atteint.
D’autres itérations restaient toutefois nécessaires. En particulier, comprendre d’ou venait l’effondrement en performance (empreinte cpu/mémoire lié aux subflows, effet collatéral lié à du swap (si starvation mémoire..)..?).
« Conclusion »
Les derniers essais fait sur un autre fournisseur VPS, avec 2 Go de RAM (plutot qu’un seul), ainsi que l’arrivée d’un nouvel algorithme de contrôle de congestion (bbr2 en beta), indique désormais le combo ECF/bbr2 en combo gagnant.
Avec les paramètres par défaut:
Voici les résultats:
Et avec le combo ECF/bbr2:
Des résultats excellents!
Note, le passage a 2 fullmesh subflows par paire d’IPs ne semble avoir aucun impact avec le nouveau VPS (2 vCores Intel Xeon E5-2690v3 + 2Go ram), alors au vu de l’impact sur le VPS précédent, j’ai décidé d’en rester à la valeur par défaut.
Note 2, les IPs des VPS OVH étant blacklistés par de nombreux sites/services (blink d’Amazon par exemple), le passage au nouveau VPS (pulseheberg) évite le paramétrage omr-bypass, qui permet de garder l’intérêt de la solution en toutes circonstances.