La Fibre
Fournisseurs d'accès à Internet mobile et 5G/4G fixe => 4G 5G Mobile => 
QoS mobile => Discussion démarrée par: kgersen le 08 mai 2022 à 22:29:19
-
Hors sujet extrait du sujet Nouveau serveur speedtest hébergé sur le réseau de MilkyWan (https://lafibre.info/milkywan/nouveau-serveur-speedtest-heberge-sur-le-reseau-de-milkywan/)
Vivement qu'ils déploient leur fameuse nouvelle implémentation de TCP RACK chez Microsoft, ou alors ils misent tout sur QUIC ? ::)
j'avoue qu'insister sur TCP ne semble pas être une solution d'avenir. Et quand on voit les débats (c Free vs ARCEP par exemple ;)) que ca engendre et la complexité/ancienneté de TCP on peut se poser des questions.
J'avoue que le dev de NSpeed a un peu pâti de ce constat : y'a t'il un intérêt a diagnostiqué plus et passé du temps sur TCP ou ne vaut t'il pas mieux tout miser sur QUIC...
En tout cas l’implémentation QUIC de Microsoft se fait en open source quasi total ce qui est a noté: https://github.com/microsoft/msquic
ils prétendent qu'elle est "Optimized for maximal throughput and minimal latency", j'ai hate de voir les futures benchs...
-
j'avoue qu'insister sur TCP ne semble pas être une solution d'avenir. Et quand on voit les débats (c Free vs ARCEP par exemple ;)) que ca engendre et la complexité/ancienneté de TCP on peut se poser des questions.
J'avoue que le dev de NSpeed a un peu pâti de ce constat : y'a t'il un intérêt a diagnostiqué plus et passé du temps sur TCP ou ne vaut t'il pas mieux tout miser sur QUIC...
Il y a deux types de tests : Des tests qui visent à mesurer la capacité du tuyau (cas de nPerf / NSpeed) et des tests visant à être le plus représentatif (cas des tests Arcep). C'est bien différent.
Dans le cas de capacité du tuyau, QUIC semble pertinent et pourrait éviter d'avoir à ouvrir 16 connexions TCP en //.
Dans le cas de tests représentatifs de l'Arcep, le tests seront en 2022 en mono-connexion et 75% avec Cubic et 25% avec BBR de façon à être représentatif de ce que l'on trouve sur internet. J'aurais aimé que les 25% BBR soient avec QUIC, mais aujourd'hui ce n'est pas supporté par les outils de mesure. J'ai réalisé quelques tests avec NGINX et QUIC+HTTP/3 et les performances HTTP/3 étaient catastrophique. J'utilisais pour mes tests Firefox, qui télécharge un fichier de 250 Mio et la première connexion se fait en HTTP/2 (les débits étaient bon) et les suivantes en HTTP/3 (débits catastrophiques).
-
(désolé pour le HS, je peux créer un autre sujet si besoin car on a pas mal dévié ?)
j'avoue qu'insister sur TCP ne semble pas être une solution d'avenir. Et quand on voit les débats (c Free vs ARCEP par exemple ;)) que ca engendre et la complexité/ancienneté de TCP on peut se poser des questions.
Je suis bien d'accord, mais pour moi un OS majeur ne devrait quand même pas se permettre de laisser son implémentation TCP à la traine comme ça par rapport aux autres. Certes on parle de QUIC depuis des années, certes QUIC est déjà utilisable en l'état, mais on est encore loin d'abandonner TCP pour autant... Et pourtant Microsoft laisse de gros défauts d'implémentations dans ses algos de congestion TCP (cf les analyses assez poussées de Gary Nebbett sur le sujet par exemple: Extreamly slow Upload speed in Windows (all other OS's on network are fine) (https://docs.microsoft.com/en-us/answers/questions/330172/extreamly-slow-upload-speed-in-windows-all-other-o.html), Slow performance of IKEv2 built-in client VPN under Windows (https://gary-nebbett.blogspot.com/2021/07/slow-performance-of-ikev2-built-in.html), Windows 11 TCP/IP Congestion Control Improvements (https://gary-nebbett.blogspot.com/2022/01/windows-11-tcpip-congestion-control.html)...).
En gros s'il y a du out-of-order sur la connexion avec une distance de plus de 3 segments (ce qui est assez courant finalement), Windows va interpréter cela comme de la perte et ne va pas réaugmenter la fenêtre de congestion au moment de la réception des D-SACK.
Du coup on se retrouve avec un débit en upload très dégradé, autour de 20-25% de ce que l'on peut avoir avec un Linux sur la même connexion en utilisant le même algo de congestion (je ne parle même pas de BBR).
Le pire c'est que ce problème est apparu progressivement fin 2020 (avec les MAJ non critiques mais quand même obligatoires de Windows 10, qui permettent à Microsoft d'avoir un immense panel de beta-testeurs...), mais il n'a jamais été corrigé depuis.
J'avoue que le dev de NSpeed a un peu pâti de ce constat : y'a t'il un intérêt a diagnostiqué plus et passé du temps sur TCP ou ne vaut t'il pas mieux tout miser sur QUIC...
C'est sûr que du point de vue développement de logiciels de test/diagnostic, ça donne plutôt envie d'embarquer dans l'aventure QUIC que de passer du temps sur des logiciels dédiés TCP.
-
C'est sûr que du point de vue développement de logiciels de test/diagnostic, ça donne plutôt envie d'embarquer dans l'aventure QUIC que de passer du temps sur des logiciels dédiés TCP.
On a tendance ici a ce focaliser sur les débits et performances max car c'est ce qu'on mesure mais pour beaucoup de personnes ,notamment pour les sites web, les devs de logiciels et OS, ce qui compte surtout c'est la latence et le nombre d'utilisateurs.
Tout les efforts et la R&D va la dedans d'ou l'apparition de QUIC/HTTP3. "TCP en l'état" suffit dans la plupart des cas simples et les "hyper scaleurs" comme Google, FB, Cloudflare, etc ne se focalisent pas sur le "debit max" d'un seul flux. Meme Netflix qui fait des optis extrêmes sur ses serveurs cherche a maximiser le débit max d'un serveur et pas le débat max d'un flux tcp (ce n'est pas la même problématique).
Dans le cas de tests représentatifs de l'Arcep, le tests seront en 2022 en mono-connexion et 75% avec Cubic et 25% avec BBR de façon à être représentatif de ce que l'on trouve sur internet. J'aurais aimé que les 25% BBR soient avec QUIC, mais aujourd'hui ce n'est pas supporté par les outils de mesure. J'ai réalisé quelques tests avec NGINX et QUIC+HTTP/3 et les performances HTTP/3 étaient catastrophique. J'utilisais pour mes tests Firefox, qui télécharge un fichier de 250 Mio et la première connexion se fait en HTTP/2 (les débits étaient bon) et les suivantes en HTTP/3 (débits catastrophiques).
75% cubic vs 25% BBR c'est représentatif de quoi ? ca sort d'ou ?
J'ai l'impression qu'il manque la donnée primordiale: qu'est-ce qui circule dans les tuyaux , le ratio UDP vs TCP et le ratio TCP/Cubic vs TCP/BBR et en volume et pas nombre de sites/services. Faires des comparaisons de débit sans connaitre la volumétrie réelle des choses me semble hasardeux.
Avant de faire un campagne de mesure des débits je cherchais plutôt a savoir ce qui passe dans les tuyaux. En collectant ses données chez des utilisateurs complices et en demandant des stats au FAI et au gros fournisseurs de contenus/hébergeurs.
-
75% cubic vs 25% BBR c'est représentatif de quoi ? ca sort d'ou ?
Cela sort de là : https://w3techs.com/technologies/details/ce-http3
Le très gros des sites qui supportent HTTP/3 sont en BBR et le très gros des sites qui ne supportent pas HTTP/3 sont en Cubic.
L'idée est d'être le plus représentatif possible. Si 1/4 de sites sont en BBR, alors la campagne de test doit mesurer 1/4 de serveurs BBR.
-
c''est le "historical trend in the percentage of websites" donc pas du tout le volume. C'est bien plus vu les sites en question (rien que Youtube par exemple fait plus de 10% du trafic mondial)
L'idée est d'être le plus représentatif possible. Si 1/4 de sites sont en BBR, alors la campagne de test doit mesurer 1/4 de serveurs BBR.
si 1/4 des voitures sont électriques mais représentent 80% des kilomètres parcourus ce n'est pas la même chose.
C'est plus le nombre de paquets TCP en BBR vs ceux en CUBIC qui comptent non?
Perso je ne ferais des mesures qu'en BBR. Car on cherche a mesurer le débit max pas le débit minimal ou la latence. Je ne vois pas l'interet d'aller faire 1/4 bbr, 3/4 cubic ca ne représente rien du tout du monde réel.
-
c''est le "historical trend in the percentage of websites" donc pas du tout le volume. C'est bien plus vu les sites en question (rien que Youtube par exemple fait plus de 10% du trafic mondial)
si 1/4 des voitures sont électriques mais représentent 80% des kilomètres parcourus ce n'est pas la même chose.
C'est plus le nombre de paquets TCP en BBR vs ceux en CUBIC qui comptent non?
Perso je ne ferais des mesures qu'en BBR. Car on cherche a mesurer le débit max pas le débit minimal ou la latence. Je ne vois pas l'interet d'aller faire 1/4 bbr, 3/4 cubic ca ne représente rien du tout du monde réel.
Personnellement, je vois même pas la finalité du truc.
Faire un énième outil de test de débit ? Occuper l' Arcep à des fins inutiles ? Remplir les tuyaux des FAI de débits encore plus inutiles pour se revendre du GB/s entre opérateur ?
Cela occupe en tous cas.
-
C'est la campagne annuelle de l'Arcep qui est reportée sur https://monreseaumobile.arcep.fr/
L'année dernière les tests étaient 100% Cubic :
L’Arcep publie les résultats de la 22ème édition de son enquête annuelle d’évaluation de la qualité de service des opérateurs mobiles métropolitains.
La qualité du service mobile mesurée en 2G, 3G, 4G et pour la première fois en 5G
Plus de 1 million de mesures en 2G, 3G, 4G, et pour la première fois, en 5G, ont été réalisées dans tous les départements, de mai à septembre 2021, sur les lieux de vie - à l'intérieur et à l'extérieur des bâtiments - et dans les transports. L’enquête a porté sur les services mobiles les plus répandus : navigation web, lecture de vidéo, transfert de données, SMS et appels vocaux. Les tests réalisés visent à évaluer la performance des réseaux des opérateurs, de manière strictement comparable, et dans des conditions d’usages diversifiées.
https://www.arcep.fr/actualites/les-communiques-de-presse/detail/n/qualite-des-services-mobiles-191121.html
(https://lafibre.info/images/barometre/202111_arcep_qos_mobile_4.webp)
-
C'est la campagne annuelle de l'Arcep qui est reportée sur https://monreseaumobile.arcep.fr/
L'année dernière les tests étaient 100% Cubic :
Ce qui fait que tu changes un paramètre d'étude et donc le périmètre d'étude, le comparatif entre N-1 et N, n' a plus de sens dans ce cas.
Si tu veux avoir la tendance d'évolution de chacun, il faut un périmètre d'étude constant, sinon tu pondères avec un coefficient variable, que tu fais varier, et ceux à qui cela ne plaira pas,parce que cela dessert, ne manqueront pas de te le faire remarquer.
-
J'ai l'impression qu'il manque la donnée primordiale: qu'est-ce qui circule dans les tuyaux , le ratio UDP vs TCP et le ratio TCP/Cubic vs TCP/BBR et en volume et pas nombre de sites/services. Faires des comparaisons de débit sans connaitre la volumétrie réelle des choses me semble hasardeux.
Se baser sur le volume échangé n'est pas forcément mieux que se baser sur le nombre de sites/services: dans les deux cas tu as de très forts biais.
Pour moi ce qui compte vraiment quand on veut évaluer une qualité de service ressentie côté utilisateur c'est d'avoir le ratio du temps passé par l'utilisateur, pas le ratio du volume.
En te basant sur le volume seulement tu vas considérer par exemple que le temps utilisateur d'une seule personne qui regarde sa série sur une plateforme en 8K multi-flux BBR va être plus important que le temps utilisateur de 100 personnes qui regardent des vidéos en SD en mono-flux CUBIC, pas très représentatif...
-
Ce qui fait que tu changes un paramètre d'étude et donc le périmètre d'étude, le comparatif entre N-1 et N, n' a plus de sens dans ce cas.
Si tu veux avoir la tendance d'évolution de chacun, il faut un périmètre d'étude constant, sinon tu pondères avec un coefficient variable, que tu fais varier, et ceux à qui cela ne plaira pas,parce que cela dessert, ne manqueront pas de te le faire remarquer.
Le protocole évolue lestement chaque année pour être le plus représentatif possible.
Par exemple le transfert se limite à une durée (qui est toujours 10 secondes) et une taille qui augmente régulièrement. J'ai souvenir il y a 10 ans d'un fichier de 5 Mio qui a été augmenté à 20 Mio, puis 50 Mio et depuis deux ans en métropole, c'est un fichier de 250 Mio. Cette année on devrait avoir un protocole identique entre DROM et métropole.
J'ai essayé de pousser de ne faire qu'une durée (taille infinie) en proposant un transfert de 8 secondes sans limite de taille afin de ne plus avoir à faire augmenter la taille du fichier, mais ce n'est pas passé.
-
En te basant sur le volume seulement tu vas considérer par exemple que le temps utilisateur d'une seule personne qui regarde sa série sur une plateforme en 8K multi-flux BBR va être plus important que le temps utilisateur de 100 personnes qui regardent des vidéos en SD en mono-flux CUBIC, pas très représentatif...
oui mais on parle de débit "max" dans ces mesures et pas des mesures de confort/latence.
Ce qui compte pour le mec qui regarde sa série en 8K avec un bitrate video de 100Mbps c'est qu'il y ai en moyenne 100Mbps pour pas vider son buffer et que les 100 personnes qui regardent en SD aient chacune en moyenne 1Mbps voir moins.
Si tu prend un ratio 100 cubic vs 1 bbr tu n'est pas représentatif du tout. c'est 1 Mbps x100 vs 100 Mbps x 1 ou sur 1 heure, 50% pour BBR et 50% pour cubic.
Donc oui prendre le volume c'est représentatif parce que le provider qui doit fournir du 100Mbps moyen a un client va forcement utiliser la tech la plus adaptée donc du BBR.
Si on cherche le "max" on mesure avec BBR (et rapidement qu'avec QUIC et plus tcp) et ca ne sert a rien de regarder autre chose. Ca complexifie l'étude et crée des polémiques inutiles de faire les cubic et bbr.
-
oui mais on parle de débit "max" dans ces mesures et pas des mesures de confort/latence.
Si j'ai bien tout suivi on compare les débits moyens sur la durée du test de téléchargement.
Si tu prend un ratio 100 cubic vs 1 bbr tu n'est pas représentatif du tout. c'est 1 Mbps x100 vs 100 Mbps x 1 ou sur 1 heure, 50% pour BBR et 50% pour cubic.
Je n'ai pas compris ce que tu voulais dire ici ? Pour moi l'important c'est le nombre d'utilisateurs concernés, pas le volume de données.
Donc oui prendre le volume c'est représentatif parce que le provider qui doit fournir du 100Mbps moyen a un client va forcement utiliser la tech la plus adaptée donc du BBR.
Si on cherche le "max" on mesure avec BBR (et rapidement qu'avec QUIC et plus tcp) et ca ne sert a rien de regarder autre chose. Ca complexifie l'étude et crée des polémiques inutiles de faire les cubic et bbr.
Je ne suis pas du tout ta logique...
edit: en fait si, je pense que j'ai compris, surtout depuis que les posts ont été déplacés dans la section QoS mobile et qu'un sujet a été ajouté posant le cadre du test de débit pour mobiles (personnellement je parlais plutôt des usages en ligne fixe...)
Tu pars du principe que cela ne sert à rien de s'encombrer de CUBIC dans les tests de débit, car de toutes façons le trafic en CUBIC n'est pas du trafic qui a besoin de vitesse élevée sinon l'administrateur du serveur aurait déjà migré en BBR.
Peut-être que c'est le cas pour tous les services typiques d'un usage mobile, je suis relativement mal placé pour en parler...
-
Le protocole évolue lestement chaque année pour être le plus représentatif possible.
Par exemple le transfert se limite à une durée (qui est toujours 10 secondes) et une taille qui augmente régulièrement. J'ai souvenir il y a 10 ans d'un fichier de 5 Mio qui a été augmenté à 20 Mio, puis 50 Mio et depuis deux ans en métropole, c'est un fichier de 250 Mio. Cette année on devrait avoir un protocole identique entre DROM et métropole.
J'ai essayé de pousser de ne faire qu'une durée (taille infinie) en proposant un transfert de 8 secondes sans limite de taille afin de ne plus avoir à faire augmenter la taille du fichier, mais ce n'est pas passé.
Quand tu prends des métriques différentes pour mesurer des facteurs différents dans une analyse multifactorielles ( Mesure d'audience, Mesure de volume échangé ou tout autre ) il te faut un facteur commun de métrique, pour tout ramener à la même unité de mesure, pour pouvoir pondérer les différents facteurs.
Là tu as pris un volume d'échange, pourquoi pas, cela aurait pu être le temps, le facteur commun des poids de pondération des différents facteurs.
Ce que tu ne peux pas faire, si tu veux pouvoir comparer ce qui est comparable dans le temps, c'est de dire, je vais comparer dans le temps N-1, N deux choses qui ont un facteur ayant été modifié, ce n'est pas consistant. Ou alors ce sont deux études décorrélées et incomparables.Et là tu t'exposes aux désaccords de méthodologie.
Si tu dis, on ne peux pas comparer les études de l'année dernière et de cette année, soit. Si tu dis on a changé la méthodologie de mesure pour l'améliorer, tu dois prévenir que on ne peux pas comparer les études précédentes avec celle-ci.
-
Les changements suivent Internet.
Pour donner un autre exemple pendant longtemps les tests étaient 100% en http. Il y a ensuite eu 50% http et 50 https. Depuis 2/3 ans, c'est 100% des tests en https.
Autre changement : l'arrivée de l'IPv6 l'année dernière avec 50% des tests réalisés vers un serveur IPv4+IPv6 et 50% vers un serveur IPv4 only.
Pour le surf, c'est un ensemble de 10 pages extrait du top30 Alexa des sites les plus consultés en France qui est testé. Là aussi les pages évoluent d'une année sur l'autre.
Bref internet évolue et la méthode de test doit donc évoluer.
-
Tu pars du principe que cela ne sert à rien de s'encombrer de CUBIC dans les tests de débit, car de toutes façons le trafic en CUBIC n'est pas du trafic qui a besoin de vitesse élevée sinon l'administrateur du serveur aurait déjà migré en BBR.
oui c'est exactement ca
-
Les changements suivent Internet.
Pour donner un autre exemple pendant longtemps les tests étaient 100% en http. Il y a ensuite eu 50% http et 50 https. Depuis 2/3 ans, c'est 100% des tests en https.
Autre changement : l'arrivée de l'IPv6 l'année dernière avec 50% des tests réalisés vers un serveur IPv4+IPv6 et 50% vers un serveur IPv4 only.
Pour le surf, c'est un ensemble de 10 pages extrait du top30 Alexa des sites les plus consultés en France qui est testé. Là aussi les pages évoluent d'une année sur l'autre.
Bref internet évolue et la méthode de test doit donc évoluer.
Pose la question à l'INSEE si la méthodologie est avalisée (enfin quand je dis toi, l'ARCEP).
Je n'y vois pas de problème intellectuel structurel sur la métrologie, mais évites toi des polémiques médiatiques inutiles ensuite.
Si la méthodologie de mesure est validée par l'INSEE cela rentre dans les outils de mesure de l'état, et les opérateurs n'ont plus à contester, ni la méthodologie,les métriques et outils.
-
L'opérateur qui a contesté au moment où il a eu accès aux résultats n'avait rien trouvé à redire au protocole avant que les tests soient lancés.
-
Oui, comme tu dis, les choses évoluent.
Il y a plusieurs façons de t'aider, ou te tirer d'un mauvais pas, ou t'éviter de le faire.
-
perso je pense qu'il faudrait:
- un test de débit max avec BBR et HTTP/2 taille illimitée max 8 secondes. (remplacé puis plus tard par un test en HTTP/3) (tester du HTTP/1.1 et/ou du non chiffré n'a pas d'intérêt de nos jours). en ipv4 et ipv6.
- un test de perte de paquets au heure de pointes (via des streams UDP a des débits représentatifs sans pousser au max) ... C'est qui fait que CUBIC pèche chez Free par exemple. En publiant ce genre de chose ca évite la polémique car ca met en évidence clairement les engorgements de collecte ou peerings/transits d'un FAI sans brouiller le message avec un débat sur les algos de congestion de TCP ou de mesures de débit ;)
-
Il y aura peut-être un test débit max (multi-connexion, 100% BBR) qui se rapprochera d'un nPerf, c'est en expérimental.
Le débit principal a lui toujours la volonté d'être le plus représentatif possible (dans la limite du raisonnable financièrement, on ne va pas mettre 5 serveurs).
Le problème d'un indicateur sur les pertes de paquets, c'est que c'est vraiment un indicateur technique, pas de qualité d'expérience.
-
Le problème d'un indicateur sur les pertes de paquets, c'est que c'est vraiment un indicateur technique, pas de qualité d'expérience.
L'idée était par exemple de balancer de l'UDP a 1 ou 2 Mbps aux heures de pointes. Avec des pertes de paquets ca va être difficile de faire de la visio de bonne qualité (Duo/Chat, Zoom, Facetime, Teams, etc)... c'est assez simple à faire comme test.
-
Le problème d'un indicateur sur les pertes de paquets, c'est que c'est vraiment un indicateur technique, pas de qualité d'expérience.
Ce n'est pas un problème à proprement parler, ce sont deux mesures différentes.
La Qualité d'expérience, repose sur un ressentis sensoriel, vue, ouïe etc. c'est un type d'analyse différent, des études plus souvent faites par les départements marketing Quali/Quanti.
Il y a une corrélation sous-jacente avec la qualité technique, mais elle est invisible pour le consommateur. Pour le consommateur, plus il y a de débit mieux c'est, c'est un raccourcit de relation causale faux.
Là on parle de ce qui est ton périmètre à toi et de tes campagnes de mesure, de tes choix de tests et présentations. Si un des opérateurs utilise ces indicateurs pour ses besoins marketing en les mettant en avant, d'autres y trouveront à redire, sur n'importe quel angle de mise en cause.
Pour ce qui te concerne, il faut juste que ce soit impartial.
La métrique de kgersen, en est une, elle repose sur une analyse temporelle, elle à l'avantage de se décorréler de la technologie sous-jacence.
Tu récupères un volume en temps donné, et ce qui est derrière est du ressort de l'opérateur. Si tu entres dans les détails du bit 8 de l'octet 4 du protocole 1.2, tu vas avoir du mal à synthétiser.
-
Ne pas oublier que 3 opérateurs mobile sur 4 ont une plateforme d'optimisation (on en parle dans le sujet IPv6 fallback to IPv4 (https://lafibre.info/ipv6/ipv6-fallback-to-ipv4/msg944760/#msg944760)) qui concerne tous les flux TCP port 80 et TCP port 443).
Il faut faire attention à la représentativité quand on lance un test qui ne passe pas par cette plateforme (et c'est aussi pour cela que faire une partie des tests en HTTP/3, quand il sera plus mur, est intéressante : HTTP/3 ne peut pas être accéléré par la plateforme d'optimisation).
Le protocole 2022 est figé et les tests préliminaires à la campagne lancés, mais je pourrais essayer de vous inviter pour discuter lors de la co-construction du protocole 2023, des idées sont probablement bonnes à prendre.
-
La campagne va se dérouler sur quelle période ?
L'année dernière, n'était-ce pas beaucoup plus tôt dans l'année ?
-
Il me semble que l'Arcep ne rend pas public le planning de mesure de la QoS mobile, mais c'est toujours un peu la même chose :
Un appel d'offre est lancé fin d'année (ou début d'année suivante) pour déterminer le prestataire (et les outils) qui vont réaliser les mesures.
Il y a ensuite la finalisation du protocole, le choix des terminaux, la mise en place des serveurs, la configuration des outils de mesure et la validation des chaines de mesure.
Les mesures qui seront publiées sont réalisées à la fin du printemps et au début de l'été.
Le rapport final arrive à l'automne, cf les date des sujets sur le forum :
- novembre 2021 : https://lafibre.info/qos-mobile/rapport-arcep-qos-mobile-2021/
- décembre 2020 : https://lafibre.info/qos-mobile/rapport-arcep-qos-mobile-2019-1er-2eme-3eme-4eme/ (décalage lié au covid)
- octobre 2019 : https://lafibre.info/qos-mobile/rapport-arcep-qos-mobile-2019-orange-1er-bytel-2eme-sfr-3eme-free-4eme/
- octobre 2018 : https://lafibre.info/qos-mobile/rapport-arcep-2018/
Il faut attendre le rapport pour octobre pour la métropole, si tout se passe bien. Dans les DROM, c'est décalé de quelques mois.