Critiqué pour ses résultats en baisse par rapport à la 4G et à ses concurrents, l'opérateur a livré sa vision des choses via son compte Twitter « Free 1337 ».
Ce dernier répondait hier que « ces disparités résultent du protocole de mesure [qui] utilise une seule connexion (monothread) TCP Cubic ». Il mesure donc « le temps de download d’un fichier et en déduit le débit [et] le débit auquel l'algorithme de contrôle de congestion Cubic autorégule sa vitesse sur une seule connexion ».
Pour Free Mobile, ce n'est pas le meilleur choix, ce protocole datant de 2008. Il « est fondé sur les pertes de paquets mais peut ajouter des délais et dégrader les performances. Le TCP BBR, de 2016, qui devient majoritaire, utilise des estimations de bande passante et de temps d'aller-retour (RTT) et s’approche de l'optimum théorique » vante l'opérateur.
Il ajoute que son réseau « a été optimisé pour un usage à plusieurs connexions (multithread), cas d’usage des abonnés mobiles » et cite « les services comme Wetransfer, iCloud, Netflix ou Youtube et quasiment tous les sites web dont celui de http://arcep.fr utilisent entre 2 et 200 connexions TCP associées à 1 à 10 connexions UDP QUIC pour le contenu vidéo ».
Il met en avant ses propres mesures, effectuées par un prestataire de l'Arcep sur 50 points à Paris qui montreraient des débits améliorés en 5G, sans préciser si cela se fait sur des antennes à 700 MHz ou 3 500 MHz. Un point d'importance, puisque contrairement à ses concurrents, le 700 MHz est la bande principale de son déploiement 5G et l'une des raisons de ses débits faibles.
L'opérateur termine en indiquant que « le protocole de mesure de l'ARCEP ne reflète pas les usages réels des abonnés mobile et les débits des abonnés Free Mobile. Les prochaines campagnes de test devront évoluer pour être plus proches des réalités terrain ». Espérons également que l'entreprise prendra le temps d'indiquer sur ses cartes de couverture quels sont les débits auxquels ses clients peuvent prétendre, zone par zone.
Pour Vivien, administrateur du forum LaFibre.info travaillant à l'Arcep, « Ceux qui demandent que tous les tests de l'Arcep soient réalisés avec le protocole de congestion BBR, car les débits 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 ».
Pour l'expert, « 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ébits 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) ».
Interrogée pour un commentaire officiel, l'Arcep ne nous avait pas encore répondu ce matin.
Commentaires (43)
#1
ça me fait penser aux tests anti-pollutions automobiles (diesel-gate).
Même si la comparaison est foireuse…
Mais finalement lorsqu’on utilisent des tests en usage réel, ça révèle les supercheries.
#2
Quels guignolos… Sur un réseau relativement stable, TCP depuis sa création n’a jamais eu de problème à saturer les liens. Les évolutions et multi-thread servent à améliorer les débits sur les réseaux justement non stables (et aussi à prendre le pas sur les utilisateurs mono-thread à leurs dépens quand le réseau sature), mais faut pas croire que ça les multiplie non plus, à moins d’avoir un réseau vraiment très pourri.
La prochaine fois ils diront qu’il fallait activer tel bit de tel en-tête pare que sinon la mesure est mauvaise.
#3
TCP est fondé sur l’hypothèse qu’une perte de paquet vient forcément de la congestion, donc qu’il faut ralentir si ça se produit. Cette hypothèse n’est plus vraie dès que tu as une liaison radio. Cubic est l’algo idéal sur une liaison fibre, pas du tout sur de la 5G.
#4
Je suis parfaitement d’accord avec l’aspect technique de gestion de la congestion et l’utilisation de BBR, par ailleurs sur mes routeurs 4G (j’en ai une dizaine), avec une puce FREE, c’est cette congestion BBR que j’utilise depuis 3ans, et j’ai très hâte que BBRv2 puisse être finalisé, car les débits et la gigue du ping n’ont absolument rien à voir par rapport à Cubic, fortement déconseillé pour n’importe quelle liaison sans fil dont les pertes sont plus conséquentes que du filaire. BBRv2 va encore réduire fortement les retransmissions TCP, donc augmenter le débit…
Les box que j’utilise sont un peu partout en France et sur des distances allant de 1Km à 18Km, je tape en moyenne pour chaque BOX du 100Mbps(DL)/30Mbps(UP) à tout heure de la journée et de la nuit, sur certaines antennes ou le 2CA/3CA est possible, je tape du 260Mbps(DL)/40Mbps(UP).
J’ai même un client très éloigné, dont les antennes émettrices ce situe derrière une centrale nucléaire, qui a 2 x BOX 4G avec un OpenMPTCProuter pour cumuler les débits : ~160Mbps(DL)/20Mbps(UP)
Quand à la 5G, les derniers tests de débit montre qu’avec un signal pas terrible sur mon smartphone (2 barres sur 4), modifié pour préférer BBR à Cubic, j’ai maximum 400Mbps(DL)/50Mbps(UP) et une gigue de ~2ms … ! et en moyenne je suis tout le temps dans les 200Mbps(DL)
Merci, de rien.
#4.1
Meeci pour la précision, mais ça montre quand-même que le réseau de Free semble perdre plus de paquets que celui des autres. La question du pourquoi reste donc ouverte.
Merci pour ces détails. Comment faire pour pousser l’utilisation de BBR à l’échelle d’un réseau local ? J’ai un cas d’utilisation assez loin de l’antenne qui pourrait bien bénéficier de cette amélioration (un petit réseau chez un particulier, rien de professionnel).
#4.2
1-Ce sont des modifications que tu as faites et qui ne représentent pas la grande majorité des usages
2- Les conditions de tests sont les mêmes pour tout le monde.
#5
Pour ceux pour qui il manque une étape dans la description du raisonnement de Vivien :
Cubic et BBR sont des algorithmes de gestion de congestions. Si les débits sont différents suivant les algorithmes utilisés, c’est qu’il y a congestion sur le réseau, et que donc, ce réseau n’est pas sain.
C’est ce qui semble être le cas du réseau de Free actuellement.
#5.1
Sauf que ce qui est détecté comme congestion peut être une pure perte de paquet entre le téléphone et l’antenne, sans rapport avec le réseau physique en aval.
Après, comme pointé plus haut, si les résultats diffèrent des concurrents selon le protocole de congestion utilisé, ça veut aussi dire que le taux de perte de paquet avant même l’antenne est plus important ce qui soulève d’autres questions (hardware de l’antenne, fréquences utilisées, installation ?)
#6
Non. S’il y a une différence, c’est qu’il y a des pertes de paquets, et Cubic croit que c’est à cause de la congestion, alors que non, les pertes sont dues à la radio.
Un meilleur débit au prix d’un peu plus de pertes de paquets, ça rappelle la stratégie agressive de synchronisation ADSL de Free. Ils font sans doute un truc équivalent en 5G.
#7
Bande Free 700 : l’ohms ne suffit pas.
Bientôt sur les écrans des autres !
#8
Je ne suis pas l’arcep mais quand je fais des tests débit 4G et 5G sur mon forfait Free mobile je vois bien que c’est juste une qualité de réseau mobile à la hauteur du prix mensuel de l’abonnement…
C’est juste du bon sens et de la logique pas la peine que Free s’enfonce dans des explications douteuses.
En outre sur la fibre ils sont parfaits
#8.1
Le low-cost des télécoms, quoi.
Oh wait, ça va pas faire plaisir à Xavier ton commentaire.
(Et s’ils étaient parfaits sur la fibre, ça se saurait…)
Congestion réseau ou perte radio, la conséquence pour l’utilisateur est la même: ça marche moins bien.
#8.2
oui et non
pour le ressenti utilisateur, si, comme free et des commentaires l’indiquent, c’est bbr qui est utilisé dans les appli “courantes”, l’utilisateur n’aura pas de souci à l’usage
par contre, si, effectivement, le souci est du a des pertes de paquet plus prononcées chez free que chez les autres (avec une compensation prise en compte par bbr et pas par cubic) ça reste un témoin qu’il y a qqch de différent sur le réseau, MAIS est-ce vraiment un défaut réel de la structure du réseau ? ou bien est-ce que les autres ont mis en place des systèmes pour compenser les pertes différents et qui sont pris en compte par cubic ? ça j’en sais rien
pure hypothèse de ma part, j’y connais rien en protocole radio (ni réseau à proprement parler) et encore moins en équipement télécom, mais j’imaginerai sans souci un système de cache au niveau de l’antenne, que les opérateurs ont configurés différents, du genre chez orange une trame est gardée en cache pour un canal jusqu’a émission complète avec succès, quand chez free la trame est découpée pour des envois sur plusieurs canaux en même temps, mais si un paquet est perdu, c’est pas le même canal qui ré-émettra le paquet -> pas vu par cubic
je serai pas étonné qu’un truc dans le genre puisse être la source des différences détectées.
forcément en disant ça ça fait “fanboy free”
une autre hypothèse serait que le lien coeur de réseau <-> antenne est moins fiable chez free que chez les autres et qu’il y a plus de pertes, (mais je vois pas trop comment bbr serait moins impacté par ça que cubic cela dit)
même si je ne comprendrai pas tout, j’aimerai bien avoir l’explication détaillée des causes de la différence (mais ça, j’imagine que free donnera jamais l’info :( )
#9
Meilleur commentaire de la discussion: clair, net, précis et exact.
Si on pouvait voter les commentaires, je mettrais +10.
#10
Bien sûr… et d’ailleurs, avant d’avoir des réseaux filaires switchés ayant résolu le pb des collision, TCP ne fonctionnait pas?!! Pourtant, dans les 2 cas on est sur un média ou tout le monde peut se retrouver à causer ensemble. Sauf qu’en filaire, c’était retransmission (CSMA/CD) tandis qu’en radio, justement, c’est le mode de fonctionnement normal depuis l’avènement de l’UMTS que tout le monde puise causer en même temps (contrairement au GSM, ou les utilisateurs étaient séparés physiquement en temps/fréquence).
Free, comme toi, a vraiment tout faux. A ce tarif, faut retourner aux origines du minitel rose de la boite.
#11
A commencer par l’installation bâclée: Là ou les autres font du FTTH, Free dans mon quartier étant cablé depuis sa construction n’a pas poussé la fibre au delà du point de connection sous la chaussée devant les maisons: Ils ont laissé la terminaison câblée!!!
=> Plusieurs voisins chez Free ont changé d’opérateur (Orange ou Sosh si pas besoin de + de 300MB symétriques) afin d’avoir une installation fibre réalisée correctement… Les suivants, prévenus, ont changé d’opérateur avant de demander leur raccordement, histoire de gagner du temps.
#12
Bon, je suis d’accord pour dire qu’en BBR ce sera probablement plus rapide.
D’ailleurs j’utilise BBR sur une connexion fibre Free depuis des années et ça marche bien mieux ainsi vs cubic (genre au début je passais de 200Mbps à 890Mbps).
Seul problème, je fais comment pour configurer mon smartphone en BBR hein ? Et windows chez moi sur la fibre ?
Heureusement les PC windows étaient limités par le wifi, mais aujourd’hui mon wifi atteins le giga. Il se trouve par chance que ma connexion supporte désormais le Gbps en cubic, mais ce n’est que récent. Je doute que les smartphones passent un jour au BBR. Bref, au moins chez Orange en cubic ou BBR j’étais toujours au max, et windows pouvait “s’exprimer”.
Et là pour le réseau 5G c’est vraiment de la mauvaise foi. Il existe des moyens pour le passage de plusieurs Gbps à des connexions à perte (8G->1G, ou RF à plusieurs Gbps). Faut juste bien savoir configurer son équipement.
#13
Merci pour cette contribution bienveillante et toute en finesse.
Reprenons : la base du contrôle de congestion dans TCP, c’est que quand les switchs ou routeurs débordent, il jettent des paquets. Donc si on constate des pertes de paquets, c’est qu’il y a congestion, donc il faut ralentir. Dès l’origine (Tahoe puis Reno), ça marchait comme ça. La contention pour l’accès au medium physique (en 10base2 par exemple), c’est autre chose, et normalement géré par la couche physique, pas par TCP. Les autres causes de pertes de paquets, en filaire, sont rares. Il suffit d’avoir déjà fait de l’UDP pour s’en rendre compte : en LAN, on ne perd rien.
En radio en revanche, la perte de paquet n’est pas automatiquement le signe de congestion. Ça peut être causé par de la congestion quand même, certes, mais il y a d’autres causes possibles, ce qui induit les protocoles de congestion de TCP en erreur.
Après, pour être exact, j’ai bien compris que tu n’étais pas d’accord, mais je ne vois pas en quoi ce que tu racontes apporte une quelconque explication.
#14
Comme dit plus haut, dans les 2 cas il y a perte de paquets. Mais la conséquence pour l’utilisateur n’est pas la même si on choisit un algo adapté à “la cause la plus probable” d’une perte de paquet dans une transmission par onde radio.
#14.1
Transmis à Mme Michu qui a cru au marketing de Xavier: change de protocole chérie, t’es chez Free et pour des raisons mystiques il y a des pertes radio plus importantes chez eux que chez les autres mais c’est vraiment pas leur faute.
#15
Il gère l’orthographe le Vivien
#16
Tout ce qui est dit c’est qu’on devrait arrêter d’utiliser un protocole inadapté aux ondes radio pour évaluer la qualité d’un réseau par onde radio.
C’est comme évaluer la qualité d’un réseau routier avec un protocole prévu pour le transfert de wagons de marchandise.
#17
J’ai bien compris que c’est l’argument de Free. Je ne sais pas ce qu’il vaut dans la vraie vie. Quels sont les protocoles utilisés par les terminaux/OS/applis, comment se passe éventuellement le switch d’un protocole à l’autre…
J’ai peut-être un a priori négatif mais ce ne serait pas la première fois que Free tord un peu le cou à des protocoles pour “faire marcher malgré tout”. Je ne demande qu’à être convaincu du contraire, avec de vrais arguments techniques. Là, du peu que j’ai lu jusqu’à présent, c’est l’écart de mesures entre les utilisations des 2 protocoles qui serait réellement problématique.
#18
Normalement: Cad que c’était toujours le cas pour celui qui commençait à transmettre dont le transceiver, niveau couche physique, s’apercevait immédiatement du problème… mais de l’autre côté, pour celui qui l’avait devancé d’un poil de cul (pour avoir baisé le sense initial du précédent), c’était des erreurs/retransmissions gérées au dessus.
Mon propos c’était que depuis l’UMTS et l’OVSF (codes orthogonaux assurant la séparation des utilisateurs + gestion débit combiné à celle de la puissance), en radio tout le monde cause en même temps et qu’on peut se marcher dessus, c’est conçu pour et dès la couche physique rendant la comparaison filaire/radio peu pertinente sauf à considérer un passé GSM (et systèmes antérieurs, restés au “passez moi le 22 à Asnières” avec un canal de communication bien balisé attribué a l’utilisateur et lui seul, l’utilisateur ayant son time-slot dans des burst de 577µs sur une fréquence parmi les autres dans la bande allouée à l’équipement).
#19
Il y a l’intérêt évident pour Free de présenter des bons chiffres face à la concurrence. Je dirais que ça c’est l’argument marketing… et je m’en moque (d’autant + que je suis chez Orange :)
Mais il y a aussi l’argument technique: faut faire un bench qui soit adapté à la technologie utilisée et son usage réel. Je suppose que tout le monde gueulerait si on comparait la puissance des cartes graphiques avec un bench qui fait du throttling à 30fps. :/
#20
[HS]
Finalement, est-ce que le diesel-gate avait une base légale ?
Si ce qui était demandé c’était d’obtenir un score X à un test normalisé, est-ce que ce n’est pas ce que sont parvenus à faire les constructeurs ?
Parce qu’il y a plein de dispositifs qui sont contournés par les multinationales. A partir de quand de l’optimisation fiscale devient de l’évasion ?
#21
grammaire
#21.1
Non, orthographe. C’est le pronom “on” qui est mal orthographié et ce n’est pas un problème de conjugaison.
#21.2
Je n’ai pas dit qu’il avait fait une faute de conjugaison, mais une faute de grammaire, qui signifie un problème au niveau de la construction de la phrase. Techniquement, mettre “ont” au lieu de “on” peut aussi être un problème d’orthographe si on ne sait pas écrire le mot “on”. Mais c’est peu probable, nous avons donc affaire ici à
un serial killerune faute de grammaire. Ou tout simplement une faute de mémoire musculaire qui a ajouté un “t” par habitude.J’allait chez sa tante. => conjugaison
J’allais chez sa tente => orthographe
J’allais chez ça tante => grammaire
#22
A tous ceux qui disent configurer leur PC ou smartphone en BBR : le seul protocole de congestion qu’on choisit, c’est celui qui est utilité pour l’envoi (upload). En réception, on est tributaire du protocole de congestion choisi par le serveur.
A part avec iperf (qui est un test, pas une application pratique), et le cas de quelqu’un qui écrirait une application et aurait le choix du protocole (HTTP/1.1 et HTTP/2 utilisent TCP, HTTP/3 est en UDP et peut donc avoir une gestion de la congestion différente), le choix côté client est donc limité.
Donc à moins que le réseau Free entraîne des pertes de paquets surtout en upload, on ne peut rien faire : si le serveur en face utilise BBR tant mieux, s’il utilise cubic…
#23
I hear “Cheh” in my oreillette de Vivien.
#24
Ca ne nous dit toujours pas pourquoi Free aurait plus de pertes de paquets que les autres. Perdre des paquets n’est jamais bon dans un réseau, quel que soit le protocole, et doit être minimisé.
Pour reprendre l’exemple que tu donnes, je me poserais des questions si je voyais tous les participants à 30 FPS sauf un à 25, et je douterais fortement que faire un test non limité en FPS change la donne, même si ce serait effectivement mieux de le faire non limité.
#25
Ce n’est jamais bon de perdre des paquets à cause d’une congestion (=saturation).
Par contre perdre des paquets à cause d’une perturbation (=corruption), c’est presque normal sur un réseau radio. Il suffit de réémettre les paquets… à la même vitesse !
Et le problème c’est que l’algo utilisé part du principe que la cause c’est forcément la congestion et qu’il faut donc réémettre les paquets en diminuant la vitesse !
Si, comme l’affirme le presta de Free, les perfs sont aussi bonnes que celle des concurrents lorsqu’on change le protocole c’est que le problème c’est pas la congestion mais la perturbation.
Donc le réseau n’est pas de moins bonne qualité (technique) mais plus sensible aux perturbations (environnement).
#MyGuess
#25.1
Mon hypthèse à 2 balles: Free a probablement désactivé ou diminué la correction d’erreur au niveau transport radio et laisse les couches du dessus (OSI) se démerder.
Le gros avantage avec cette technique est que dans le cas optimal, ca diminue la latence et augmente le débit. Exactement de la même façon qu’en ADSL avec leur “mode patate”.
Mais quand le réseau n’est pas optimal, ca force les applicatifs a traiter ces pertes de paquets et tous les protocoles ne s’en sortent pas de la même façon.
Par exemple, je bosse souvent en 4G sur Orange et il m’est déjà arrivé de voir des ping (qui ne traitent pas les erreurs, ca passe ou ca passe pas) à 10s ou 15s. Tout simplement du fait que la liaison radio est en galère mais s’efforce de fournir un service de qualité au niveau IP, donc bufferise et retransmet.
Je pense que chez Free, j’aurai eu des paquets perdu.
Alors est-ce que c’est grave ou pas? Je pense que oui. Beaucoup de flux passent avec du tcp basique. Le jour ou tout sera en quic et traité au niveau logiciel, pourquoi pas. Mais c’est beaucoup trop tot. Et clairement, peu importe d’avoir 500Mb/s sous l’antenne, si c’est pour avoir une connexion de merde partout ailleurs.
#26
Perdre des paquets quelle qu’en soit la raison n’est jamais bon, il faut toujours le minimiser, quel que soit le lien. Évidemment, en radio on sera sur un ordre de grandeur tout autre que sur un réseau filaire, mais il n’empêche qu’il faut chercher à le minimiser, c’est du temps et de l’énergie perdue.
Et si TCP s’en sort bien, tout protocole sans retransmission en souffre (jeux en ligne, streaming audio et vidéo temps réel).
J’ai bien compris ce problème et en quoi changer l’algorithme peut apporter au TCP sur liaison radio. Par contre je m’attends plutôt à ce que ça augmente le débit pour tous les opérateurs, pas que ca permette juste à Free de remonter au niveau des autres, dire ça c’est être très optimiste.
Ce qui déjà reste à prouver, le test n’ayant pas été fait, mais j’émets quelques doutes, cf ma réponse au-dessus avec les FPS.
Pour quelle raison ? Si un réseau est plus sensible aux perturbations de l’environnement au même endroit que d’autres, c’est qu’il est bien de moins bonne qualité technique. En plus, si ça se trouve, ce n’est pas sur la partie radio que se fait toute la perte, on ne sait pas.
#27
Surement un truc du genre, en effet.
Cubic et BBR sont des algos de controle de congestion pour TCP .
#28
Je suis assez d’accord avec l’idée,
si le découpage des paquets est optimisé pour un fonctionnement particulier (ici répartis sur “plusieurs connexions”), et qu’on en utilise un autre pour les tests, les résultats seront pas des meilleurs.
Je me rappelle d’un anecdote sur 4D (https://fr.wikipedia.org/wiki/4e_Dimension_(langage) ) que m’ont racontée d’anciens de leurs développeurs, ils étaient les plus rapides en synchro à l’époque du RTC (ligne téléphonique), car avaient développé une couche TCP adaptée à leurs propre besoins, mais au passage à l’ADSL qui redécoupait une deuxième fois leurs paquets ça a été une catastrophe, qu’ils ont mis longtemps à relever.