Débits 5G : face aux attaques de Free Mobile, l’Arcep défend son protocole, persiste et signe

Prochain round en 2022

Débits 5G : face aux attaques de Free Mobile, l’Arcep défend son protocole, persiste et signe

Le 26 novembre 2021 à 07h20

Commentaires (17)

votre avatar

Free, l’éternel sale gosse qui voudrait changer les règles du jeu une fois les notes distribuées…

votre avatar

C’est assez étrange, ce même Vivien sur le site de lafibre.info, et, sur le sujet de BBRv2, affiche un jolie graph de comparaison du débit (sur plusieurs jours) mono-multi connexions avec CUBIC et avec BBR et je trouve que les graphs parlent d’elles même et est en contradiction avec la phrase « un bon réseau a un débit proche en Cubic / BBR et mono / multi-thread ».



Malgré le vilain défaut de l’équité de BBR, il surpasse de loin Cubic à un point ou, je cite : “certains grands acteurs de l’internet commencent à déployer BBR sur leurs serveurs”.



Les vilains défaut seront corrigés dans BBRv2 qui est actuellement en Alpha et dont j’ai déjà pu tester sur des routeurs OpenWRT : réduction de 50% des paquets perdu/retransmis, avec une augmentation de 30% du débit.



Mes propres tests sur Cubic m’ont fait comprendre, quand il s’agit d’une connexion purement radio : on l’oublie tout de suite ! (que le réseau du fournisseur soit bien ou pourri)

votre avatar

Merci pour avoir retransmis fidèlement mes propos.



Pour la phrase « Depuis l’année dernière on est 50 % de serveurs IPv4/IPv6 et 50 % IPv4 “only” pour être représentatif parce qu’aujourd’hui ont voit qu’à peu près 50 % des pages consultées sont en IPv6 » j’ai fait une petite erreur : 50% des pages consultées sont sur des serveurs qui proposent de l’IPv6.



Selon le “Baromètre annuel de la transition vers IPv6 en France 2020” : “61% des pages web les plus visitées en France sont accessibles en IPv6” (source).



A noter que l’Arcep va publier Lundi soir la version 2021 du Baromètre annuel de la transition vers IPv6 en France. Ceux qui le souhaitent peuvent assister à une réunion en visio-conférence de présentation le lundi 29 novembre 2021 à 16h30 à l’occasion de la publication de l’édition 2021 du baromètre de la transition vers IPv6.



À cette occasion, sera également publié le guide « Entreprises : Comment déployer IPv6 ? », second livrable de la task-force IPv6 co-pilotée par l’Arcep et Internet Society France et ouverte à l’ensemble de l’écosystème. Ce guide méthodologique sera destiné aux entreprises et visera à expliquer comment effectuer la transition vers IPv6.



Déroulé de l’événement (sous réserve de modifications) :
• 16h30 : Ouverture de l’événement par Serge Abiteboul, membre du Collège de l’Arcep

• 16h40 : Présentation de la nouvelle édition du baromètre de la transition vers IPv6 en France par les équipes de l’Arcep, suivie d’une session de questions / réponses
• 17h10 : Présentation du guide de la task-force IPv6 « Entreprises : Comment déployer IPv6 ? » par Jean-Charles Bisecco, suivie d’une session de questions / réponses
• 17h40 : Échanges sur les futurs travaux de la task-force IPv6
• 17h50 : Conclusion par Nicolas Chagny, président d’Internet Society France



Nous vous remercions de confirmer votre présence en remplissant le formulaire via ce lien. Un email vous sera envoyé ultérieurement pour confirmer votre inscription et vous indiquer le lien pour rejoindre l’événement (merci de vérifier vos spams). Le lien étant personnalisé, veillez à le conserver pour le jour même.

votre avatar

Mais du coup, la différence CUBIC, BBR, ça se configure de façon logicielle?
Je ne comprends pas pourquoi Free Mobile ne le fait pas.



Ça se configure comment sur OpenWRT?

votre avatar

Ça se déploie coté émetteur au niveau de la couche TCP. Donc coté réseau mobile puisque la majorité du débit est dans ce sens. Cubic n’a pas été pensé pour la radio et son taux de perte important mais plus pour des liaisons filaires ou la perte de paquets est du a de la congestion.

votre avatar

D’accord, mais du coup ça ne semble pas cohérent avec la réalité du terrain ce que tu dis, les 3 autres opérateurs utilisent Cubic, ils obtiennent des débits meilleurs que Free.



Bizarre.

votre avatar

Non, au contraire, ils ont des débits meilleurs uniquement parce que c’est testé exclusivement en Cubic. Si c’était testé en BBR, les conclusions seraient probablement différentes, peut-être même inversées. Mais ça, on ne peut pas en juger, puisque les tests sont partiels et ignorent la moitié de la réalité du terrain (multithread, BBR).



De toute façon, le seul test qui vaille, c’est le test pratique fait au même moment sur des services bien réels et représentatifs, avec un panel de matériel grand public lui aussi représentatif.



Sur des tests pratiques, Free n’est pas du tout à la traine. Ça met en question la crédibilité du protocole borgne retenu par l’ARCEP.

votre avatar

Une recherche te permet de trouver l’information en quelques secondes : “linux how use bbr”



1°) avoir un noyau linux supérieur à ou égale à 4.9 (donc ça fait un moment que BBR est pris en charge, dans les ~2016)



2°) modifie le fichier /etc/sysctl.conf et ajoute :



net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr



3°) reboot + vérification via “lsmod | grep bbr” que le module tcp_bbr est bien chargé.






Il n’y a que Microsoft qui ne sait pas implémenter BBR dans Windows convenablement, et on s’en fou, car l’IP public de ton accès internet n’est pas sur ton PC mais sur ton Routeur, qui lui fonctionne avec un noyau Linux dans +90% des cas.

votre avatar

D’accord, donc ce n’est pas implémenter dans l’interface OpenWRT.
Dommage, mais merci.

votre avatar

Bien des routeurs et firewalls utilisent un noyau *BSD et pas Linux.

votre avatar

Ces commandes sont valables pour la machine qui envoie les paquets.
Donc l’utilisateur d’un Linux peut effectivement utiliser BBR pour l’upload.
Mais pour le download, c’est le serveur qui applique son protocole de congestion TCP, le client ou l’opérateur n’y peuvent rien.



Donc c’est en pratique l’administrateur du serveur, qui peut être le fournisseur si c’est un hébergement mutualisé (ou tout service qui ne donne pas un accès assez bas niveau), qui peut choisir un protocole de congestion. Même si les applications peuvent choisir le protocole pour chaque connexion (par exemple iperf), ce n’est pas le cas courant.

votre avatar

Mearwen a dit:


Ça se déploie coté émetteur au niveau de la couche TCP. Donc coté réseau mobile puisque la majorité du débit est dans ce sens.


Euh, l’émetteur c’est le serveur de départ, la couche TCP c’est la couche 4, le réseau mobile c’est au plus haut de la couche 3 (niveau IP), je vois pas comment le réseau mobile peut choisir d’utiliser Cubic ou BBR, il ne sait même pas ce que c’est.




Kalimeiro a dit:


Il n’y a que Microsoft qui ne sait pas implémenter BBR dans Windows convenablement, et on s’en fou, car l’IP public de ton accès internet n’est pas sur ton PC mais sur ton Routeur, qui lui fonctionne avec un noyau Linux dans +90% des cas.


Même remarque qu’au-dessus, un routeur avec NAT c’est de la couche 3, avec pour certains quelques incursions dans les couches supérieures mais habituellement seulement en lecture pour maintenir des tables, comment peut-il “convertir” le Cubic du PC Windows et BBR ? Vous utilisez un module Linux de routage spécifique (comme il en existe par exemple pour le FTP qui modifie les paquets à la volée), ou un proxy transparent ?

votre avatar

Kalimeiro a dit:


Une recherche te permet de trouver l’information en quelques secondes : “linux how use bbr”



1°) avoir un noyau linux supérieur à ou égale à 4.9 (donc ça fait un moment que BBR est pris en charge, dans les ~2016)



2°) modifie le fichier /etc/sysctl.conf et ajoute :



net.core.default_qdisc=fq net.ipv4.tcp_congestion_control=bbr



3°) reboot + vérification via “lsmod | grep bbr” que le module tcp_bbr est bien chargé.






Il n’y a que Microsoft qui ne sait pas implémenter BBR dans Windows convenablement, et on s’en fou, car l’IP public de ton accès internet n’est pas sur ton PC mais sur ton Routeur, qui lui fonctionne avec un noyau Linux dans +90% des cas.


Donc ce n’est pas utilisable par le grand public, donc les argument de l’ARCEP sont cohérents.



On se fout de savoir qui va le plus vite dans des conditions optimum: on veut savoir qui est le meilleur dans des conditions réelles d’utilisation.



Soit Free modifie ses protocoles, soit il indique clairement à tous ses clients les modifications à faire pour profiter pleinement de son réseau.

votre avatar

stratic a dit:


De toute façon, le seul test qui vaille, c’est le test pratique fait au même moment sur des services bien réels et représentatifs, avec un panel de matériel grand public lui aussi représentatif.


Clair que Free est bien connu pour n’avoir aucun problème de débits en réseau urbain dense.

votre avatar

cubic ou bbr n’agissent qu’en cas de saturation. Ce sont des techniques de gestion de la congestion.
Si un opérateur a des moyennes différentes entre les deux techniques c’est que son réseau est souvent saturé… y’a pas besoin d’autre argument…



C’est bien connu que la collecte et le backbone de Free sont sous-dimensionnés et saturés par rapport a ce qu’il y a aux extrémités. Les peerings aussi.



Fournir une bonne connexion au réseau Free (5g en mobile, 8G en fibre, etc) mais en amont ne pas faire correctement le job (collecte, transit, peering) c’est ne faire que la moitié du job. Et sur ce genre de tests ca se voit assez bien.

votre avatar

kgersen a dit:


cubic ou bbr n’agissent qu’en cas de saturation. Ce sont des techniques de gestion de la congestion.


L’hypothèse émise ici et avancée par Free est que des pertes normales se produisent sur la liaison radio entre l’utilisateur et le réseau, à cause de perturbations radio passagères, et dans ce cas, Cubic interprèterait ces pertes de paquets comme de la congestion, ce qui effectivement n’est pas correct. BBR ne ferait pas cette confusion et des gens ici ont constaté des améliorations en utilisant BBR sur ce type de connexion.



Mais je rejoins quand-même ton avis, déjà parce qu’ils ne sont pas censés être plus perturbés que les autres réseaux à un endroit donné, et ensuite parce que c’est une hypothèse, par définition possiblement fausse et peut-être que la perte de paquets ne se situe pas que là mais aussi dans le réseau, comme tu l’avances. On n’a que les dires de Free pour le savoir, ce qui est un peu léger.

votre avatar

Si l’Autorité publie les résultats des mesures, « c’est free qui peut expliquer pourquoi et comment » son réseau obtient de mauvais résultats. « L’enquête c’est une image à un instant », explique le service presse.


C’est insultant pour tous les opérateurs et pour le citoyen : lorsqu’on dit qu’on mesure on mesure, on ne fait pas mumuse avec un logiciel dont la physique échappe au contexte.



Ce qui s’affirme sans preuves se réfute sans preuve. Merci à l’Arcep et Free de confirmer mon opinion qu’on paye pour du travail bâclé. :roll:

Débits 5G : face aux attaques de Free Mobile, l’Arcep défend son protocole, persiste et signe

  • Cubic vs BBR : une guerre inutile ?

  • … un réseau doit gérer correctement les deux

  • Mono/multiconnexion : ce que Free Mobile « oublie de dire »

  • « On ne cache pas le protocole aux opérateurs »

Fermer