Dommage, tu sais s'ils seront remplacés ? C'était bien pratique d'avoir des serveurs fiables bien interconnectés partout et avec des configurations différentes.

Peut-être qu'Appliwave accepterait d'avoir un serveur en cubic.

Aujourd'hui c'est moi qui gère les serveurs de test de débit de Bouygues Telecom, mais Bouygues Telecom va reprendre la main.

Une nouvelle infrastructure a été mise en place remplacera l'actuelle. Le système exploitation seront les mêmes (Ubuntu 20.04 LTS et configuration détaillée sur https://lafibre.info/ubuntu/ )

- SpeedTest : De nouveaux serveurs sont déclarés par Bouygues Telecom. Un premier serveur est disponible : Meudon, serveur BBR IPv4 only. Vu le nom de domaine, il s'agit pas des serveurs de prod (bien que disponible sur internet) : https://maquette.ookla.bytel.fr:8080/ (176.173.241.37). Les serveurs de prod seront disponibles en IPv6. Les serveurs actuels seront abandonnés à terme.

- nPerf : Les nouveaux serveurs (BBR) seront déclarés (pour remplacer par exemple le serveur de paris https://fr-bouygues-paris-01-10g.nperf.net/ qui pointe aujourd'hui sur les serveurs que je gère). Il est possible que le serveur nPerf Cubic soit abandonné à terme.

- Fichiers sur un serveur TestDebit.info : Les nouveaux serveurs (avec de nouvelles URL) seront disponibles en Cubic et en BBR. A terme les URL actuelles seront redirigés vers les nouveaux serveurs, afin que les script qui utilisent ces serveurs continuent de fonctionner avec les URL https://bouygues.testdebit.info/ (Cubic) et https://paris.testdebit.info/ (BBR)

- iPerf3 : Les nouveaux serveurs (avec de nouvelles URL) seront disponibles (on choisi le protocole de congestion avec iPerf3). A terme le nom de domaine actuelle (bouygues.iperf.fr) seront redirigés vers les nouveaux serveurs, afin que les script qui utilisent ces serveurs continuent de fonctionner. Attention, si aujourd'hui tout est mutualisé sur un même serveur (SpeedTest, nPerf, 5GMark, TestDebit, iPerf) ce ne sera plus le cas à l'avenir : iPerf3 et les fichiers TestDebit.info seront sur des serveurs distincts.

- 5GMark : Les nouveaux serveurs (avec de nouvelles URL) seront disponibles en Cubic et en BBR pour remplacer "Bougues Telecom BBR" et "Bouygues Telecom Cubic".

Franchement faut abandonner cubic. Le gros de ce qui passe dans les tuyaux est bbr maintenant sauf peut-être ce qui sort d'OVH mais ce qui sort d'OVH n'est pas représentatif du trafic d'Internet d'aujourd'hui.
On ne va pas juger les 4 opérateurs mobiles la dessus c'est ridicule. OVH c'est quasi que des pages web (site e-commerce, site corpo, etc). De plus en plus de sites chez OVH sont même accédès que par Cloudflare (=20% des sites web au monde) ou autres gros CDN en frontal.

C'est sur Google, Netflix, Facebook,  les gros cloud publics (GCP, Azure, AWS) , les gros CDN (Cloudflare , Akamai) etc qu'il faut juger les opérateurs. Sur le gros des usages et d'où vient le trafic généré. Ce n'est pas parce qu'on opérateur est 1er depuis OVH qu'il le sera depuis Netflix ou Youtube par exemple.

Pour le coup il y a déjà eu ce débat dans les 20 pages précédentes, ça serait bête de le refaire encore une fois...

La conclusion c'est qu'en pratique BBR est encore loin d'être majoritaire, qu'il n'est pas "juste" par rapport à cubic (il va écraser les autres flux et prendre la place en cas de saturation) et que sur un réseau en "bonne santé", cubic vs BBR et mono-connexion vs multi-connexions ne devrait pas faire de différence donc autant utiliser ce qui met en lumière les problèmes.

oui désolé j'ai pas lu les 20 pages...

> BBR est encore loin d'être majoritaire
C'est basé sur quoi cette affirmation ? On parle de volumétrie (nombre de paquets ou octets) ou du nombre de sources (sites web ou services web). Ce qui compte c'est le volume et le gros c'est BBR a cause de Netflix, Google (surtout Youtube) et Cloudflare notamment. Il suffit d'un lien de collecte saturé par du Youtube ou Netflix et tout ce qui n'est pas BBR va souffrir.

> BBR est encore loin d'être majoritaire
C'est basé sur quoi cette affirmation ? On parle de volumétrie (nombre de paquets ou octets) ou du nombre de sources (sites web ou services web). Ce qui compte c'est le volume et le gros c'est BBR a cause de Netflix, Google (surtout Youtube) et Cloudflare notamment. Il suffit d'un lien de collecte saturé par du Youtube ou Netflix et tout ce qui n'est pas BBR va souffrir.

Vivien le dit et le répète ici et ailleurs depuis des mois sur tout les topics où c'est nécessaire :

C'est Cubic qui est majoritairement utilisé.

Non, car 5G mark a des serveurs Cubic, mais aussi des serveurs BBR (ex: le serveur 40 Gb/s Appliwave que je gère).

Voici la médiane de 4 tests que j'ai réalisé à proximité immédiate d'un site Free mobile, avec APN IPv6 : (je mets les résultats 4G car ils sont systématiquement meilleurs que les résultats 5G)

- Cubic mono-connexion : 23 Mb/s (les tests Arcep sont en mono-connexion Cubic)
- Cubic multi-connexion : 113 Mb/s
- BBR mono-connexion : 152 Mb/s
- BBR multi-connexion : 155 Mb/s
(pour réaliser ce tests, j'ai mis en ligne des serveurs identiques à part BBR / Cubic, les deux serveurs sont dans la même baie)

Dans mon cas un test sur un serveur BBR mono-connexion permet d'avoir un meilleur débit que sur un serveur Cbic multi-connexion.

A noter que les ratios changent selon la charge des sites.
Plus un site est chargé, plus le débit Cubic va s'effondrer avec que le débit BBR va diminuer plus doucement.

La raison c'est que BBR permet de prendre du débit sur les autres utilisateurs qui sont en Cubic et donc qu'on est un peu comme si on est tout seul sur la cellule (j’exagère volontairement pour que vous compreniez mon propos, le débit BBR n'est pas miraculeux, il se fait au détriment des utilisateurs en Cubic, de nombreuses études le démontrent). La grande majorité du trafic est en Cubic, donc BBR a de la facilité pour récupérer du trafic.

Je déjà expliqué pourquoi de nombreux acteurs n'utilisent pas BBR (version 1) par défaut : 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.

Quand il y a une saturation sur un lien, BBR est excellent, grâce a la capacité qu’il va 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/#msg898513
Le 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).

Si BBR est généralisé, il ne sera plus possible de récupérer du trafic sur les connexions Cubic, donc il n'y aura plus cet effet impressionnant que l'on voit aujourd’hui quand BBR prend le débit des connexions Cubic de la même antenne / même lien.

Maintenant peut-être que BBRv2 va remplacer Cubic, on verra quand BBRv2 sera finalisé.

C'est nécessaire, mais ce n'est pas suffisant. Il faut qu'il soit représentatif d'un usage réel.

Ceux qui demandent que tous les tests de l'Arcep soient réalisés avec le protocole de congestion BBR, car les débit de Free sont multiplié par 10 quand on prend BBR se trompent : Sur internet c'est Cubic qui est majoritaire.

Un bon réseau a un débit proche 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 on 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 va 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/#msg898513
Le 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.

Ça semble sacrément has been le cubic apparemment. Du coup , Free en avance sur son temps pour suivre les grosses plateformes ?

A un moment il faut ouvrir les yeux hein... BBR ne marche pas moins bien chez les autres opérateurs, c'est juste cubic qui marche mal chez Free ce qui est symptomatique d'un problème, pas d'une avance.

Franchement arriver à ce niveau de déni, c'est vraiment grave !