Un bon réseau a un débit indique en Cubic / BBR et mono / multi-thread.
La réciproque, c'est que pour résumer, une différence importante entre débit Cubic / BBR et mono / multi-thread est synonyme de réseau en mauvaise santé (perte de paquets et/ou saturations). Ces soucis sur les réseaux ne sont pas que sur une feuille de papier : ils impactent les utilisateurs, car la grande majorité des usages sont en mono-thread Cubic.
Même si BBR n’est pas très représentatif sur internet, avoir la différence de débit entre Cubic et BBR permet de tirer des conclusions sur la santé d’un réseau au-delà du débit offert. C’est aussi un moyen de donner des pistes pour comprendre les mauvais débit et inciter les opérateurs à faire le nécessaire, car oui, en traquant les pertes de paquets ont peut chercher à les éliminer (et donc à avoir un débit proche entre Cubic et BBR).
Cubic est de loin le protocole de congestion TCP le plus représentatif, c’est celui utilisé par défaut sur le serveurs depuis de nombreuses années.
BBR est un nouveau protocole de congestion TCP qui doit encore évoluer. Une version BBRv2 est en préparation. Plusieurs travaux montrent que le BBR actuel n'est pas fair : Si on met des flux BBR et Cubic sur le même tuyau, BBR va prendre la bande passante des flux Cubic. BBR fait également exploser le taux de retransmissions, ce qui en cas de saturation va diminuer le débit réel utilisable vis à vis de Cubic (car BBR ne va pas faire grossir la taille du lien saturé). BBR a tendance à faire diminuer un peu le trafic réel utilisable sur un lien, à cause des retransmissions importantes.
Cubic n’est pas exempt de défauts. Si une perte de paquet arrive pendant la phase de montée en débit, on sort de la croissance exponentielle pour rentrer en contrôle de congestion et le débit va peu monter. La perte de paquets en début de connexion TCP peut être catastrophique pour le débit en Cubic (pas avec BBR).
Quand il y a une saturation sur un lien, BBR est excellent, grâce a la capacité qu’il vé récupérer sur les connexions Cubic de ce même lien (BBR dégrade les connexions Cubic du même lien). Un exemple réel sur une saturation du lien Cogent => Orange :
https://lafibre.info/peering/saturation-cogent-gt-orange/msg898513/#msg898513Le débit est de 719 Mb/s avec BBR et 10 Mb/s avec Cubic (sur le même serveur, car iPerf3 permet de changer de protocole de congestion TCP à la volée).
Outre le protocole de congestion, un autre choix important est mono/multi-thread. Normalement sur un réseau sain (sans perte de paquet, sans congestion) la différence entre les deux est faible. Le multi-connexion permet une montée plus rapide en débit, mais il permet aussi de masquer des problèmes de perte de paquets / saturations. Si une connexion Cubic a une perte au démarrage, son débit sera mauvais. Ce n’est pas problématique en multi-thread : une autre connexion va utiliser le débit non consommé par cette connexion bridée par la perte de paquet.
Bref vous l'avez compris, j'aimerais bien avoir un outil de test de débit plus complet que ce qui est proposé aujourd'hui et qui indique un pourcentage de débit en mono-thread vs multi-thread et un % de débit Cubic vs BBR. Cela permet de commencer à comprendre pourquoi on a un mauvais débit.
Si vous êtes déjà au débit maximum permis par la radio, votre accès ou votre CPU, changer de protocole de congestion ne va pas augmenter le débit.