La Fibre
Fournisseurs d'accès à Internet mobile et 5G/4G fixe => 4G 5G Mobile => 
QoS mobile => Discussion démarrée par: vivien le 30 juin 2022 à 08:45:46
-
L'Arcep dévoile le protocole des campagnes de mesure de la QoS mobile 2022
A la suite de polémique lancée par Free en novembre 2021 sur le protocole des campagnes de mesure de la QoS mobile (voir ci-dessous), l'Arcep publie aujourd'hui le protocole de mesure de la QoS mobile 2022.
(cliquez sur la miniature ci-dessous - le document est au format PDF)
(https://lafibre.info/images/doc/202206_arcep_rapport_etat_internet_2022.webp) (https://lafibre.info/images/doc/202206_arcep_rapport_etat_internet_2022.pdf)
Le protocole de l’enquête annuelle d’évaluation de la qualité de service (QoS) des opérateurs mobiles vise à mesurer une qualité de service mobile représentative de l’expérience utilisateur. Les débits mesurés par l’Arcep peuvent être éloignés de ceux obtenus avec certains outils de mesure de débit grand public, qui relèvent la capacité du lien (le débit du tuyau qui relie le terminal à internet), alors que l’Arcep cherche à avoir un débit représentatif d’une utilisation d’internet. Les principales différences entre certains tests de débit grand public et le protocole Arcep sont détaillées ci-dessous :
Mono-connexion vs multi-connexions
Mono-connexion : un test de débit mono-connexion (monothread) mesure le débit via une seule connexion, ce qui permet de remonter un débit représentatif d’une utilisation d’internet. En effet, la grande majorité des usages sur internet utilisent, à un instant donné, une seule connexion avec un débit important. Pour beaucoup de services sur internet, plusieurs connexions sont ouvertes, mais dans la grande majorité des cas, à un instant donné, une seule connexion à la fois est utilisée pour transférer la plupart des données. Par exemple le transfert va commencer par la connexion « A », avant de basculer sur la connexion « B » puis à la « C » et enfin revenir à la connexion « A ». Il peut y voir des petits éléments qui sont transférés en parallèle, toutefois cela reste minoritaire et globalement, la plupart des usages sur internet sont proches du comportement d’une mesure de débit mono-connexion.
Multi-connexions : un test de débit multi-connexions (multithread) mesure le débit en cumulant les débits de multiples connexions simultanées. On constate par exemple que de nombreux outils de mesure du débit effectuent un transfert sur 16 connexions simultanées. Ces multiples connexions permettent d’estimer le débit maximum du lien, mais ne sont pas à même de déceler certaines limitations de débit sur les connexions TCP. Ces limitations, qui impactent fortement une seule connexion TCP mais marginalement les connexions multiples en parallèle, peuvent être des pertes de paquets ou/et des saturations ou/et une latence trop importante.
Le choix de l’Arcep : le protocole de l’Arcep est mono-connexion afin d’être le plus représentatif des usages de la majorité des clients. Toutefois en 2022, un test expérimental (limité à 50 lieux de mesure) sera réalisé en multi-connexions, afin d’avoir une information supplémentaire sur la capacité des liens considérés.
Cubic vs BBR
Les résultats des mesures de la QoS dépendent aussi des caractéristiques techniques des serveurs de test (mire de test), et notamment de leurs algorithmes d’évitement de congestion. Ces algorithmes sont utilisés côté émetteur de données pour décider de la vitesse d’envoi des paquets. Il existe de nombreux algorithmes d’évitement de congestion et ces algorithmes évoluent.
Cubic : aujourd’hui, la majorité des services sur internet utilisent Cubic. Créé en 2006, il s’appuie sur la perte de paquets comme signal pour réduire le débit. Cubic est l’algorithme d’évitement de congestion utilisé par défaut sous Linux (qui équipe la majorité des serveurs sur internet), mais aussi Android et macOS.
BBR : Google a développé en 2016 BBR (Bottleneck Bandwidth and Round-trip propagation time), qui utilise un modèle différent, se basant sur la bande passante maximale et le temps d’aller-retour. Cette approche permet à BBR, quand une connexion perd des paquets, de proposer un débit nettement plus élevé que ceux offerts par les algorithmes s’appuyant sur la perte de paquets, comme Cubic. Aujourd’hui, certains grands acteurs d’internet commencent à déployer BBR sur leurs serveurs. Cependant, BBR n’est pas encore généralisé sur internet notamment en raison de problématiques d’équité des flux. En effet, sur un même lien où le débit est partagé entre utilisateurs (exemple : les fréquences du réseau mobile ou un lien fibre), les connexions BBR vont « prendre la place » des connexions Cubic. Une version « BBR v2 » est en développement pour améliorer la version actuelle et permettre une meilleure cohabitation avec Cubic. Quel sont les algorithmes d’évitement de congestion utilisés dans les applications de test de débit ? Ces applications peuvent utiliser Cubic, BBR, mais également d’autres algorithmes d’évitement de congestion, qui peuvent avoir la particularité d’être « agressifs », permettant potentiellement d’obtenir de très bons débits, mais qui ne sont pas représentatifs d’usages quotidiens. L’Arcep cherche à promouvoir plus de transparence en incitant les outils de mesure à indiquer le protocole d’évitement de congestion. Si le réglage réalisé sur certains serveurs de test de débit permet d’afficher des records de débit, cela n’influe pas nécessairement sur le débit qui sera obtenu pour un usage quotidien d’un utilisateur final.
Le choix de l’Arcep : le protocole de l’Arcep souhaite refléter l’usage des utilisateurs et en 2022, 75 % des tests seront réalisés avec Cubic et 25 % avec BBR. Le test expérimental (limité à 50 localisations) en multi-connexions sera lui réalisé 100 % en BBR, afin d’avoir un échantillon similaire à certains résultats d’outils de mesure de débit grand public.
HTTP vs HTTPS
Internet a évolué et est passé en quelques années d’un protocole HTTP (en clair et sur le port 80) au protocole HTTPS (en chiffré sur le port 443). Les tests dans les applications mobiles de test de débit sont encore majoritairement réalisés en HTTP. Le port utilisé n’est, pour certaines applications, ni le port 80, ni le port 443, ce qui pose le problème de la représentativité. L’Arcep pousse pour plus de transparence en demandant aux outils de mesure conformes au Code de conduite 2021 d’indiquer le port utilisé et le chiffrement ou non des flux de test de débit.
Le choix de l’Arcep : en 2022, tous les tests du protocole de l’Arcep sont réalisés avec le protocole HTTPS sur le port 443.
IPv4 vs IPv6
La transition d’internet vers IPv6 est en cours et d’après le baromètre IPv6 Arcep 2021, 62 % des pages web les plus visitées (données sur le top 730 d’Alexa en France) sont accessibles en IPv6. Certains outils de mesure de débit ont choisi de ne proposer par défaut que des tests en IPv4, tandis que d’autres utilisent IPv6 dès que le serveur et le client ont une connectivité IPv6. L’Arcep incite à plus de transparence en demandant aux outils de mesure conformes au Code de conduite 2021 d’indiquer si les serveurs supportent le protocole IPv6.
Le choix de l’Arcep : le protocole de l’Arcep prévoit 50 % des tests réalisés en IPv4 et 50 % des tests réalisés en double pile (dual stack) IPv4/IPv6.
Débit moyen vs débit maximum
Le débit affiché par les outils de mesure de débit varie selon les outils :
- débit maximum, atteint sur une courte durée pendant le test ;
- débit en régime établi (le débit à la fin du test) ;
- débit moyen après avoir exclu la montée en débit (les premières secondes du test) ;
- débit moyen entre la demande d’un fichier et la réception du dernier paquet.
Afin d’accroitre la transparence sur cet aspect, l’Arcep demande aux outils de mesure qui se sont déclarés conformes au Code de conduite 2020 d’indiquer les indicateurs affichés à l’issue du test. Les outils de mesure doivent également indiquer la durée du test, lorsque le volume maximum n’est pas atteint, ou le volume maximum de données échangés (taille du fichier téléchargé).
Le choix de l’Arcep : le débit est calculé en intégrant l’ensemble des étapes, à savoir la résolution DNS, la connexion TCP, la mise en place d’une couche de chiffrement TLS et le transfert d’un fichier de 250 Mio. Le transfert s’arrête dès que le fichier est entièrement téléchargé ou après expiration d’un délai de 10 secondes. En cas de difficulté sur les étapes de requêtes DNS ou connexion au serveur, le test ne sera pas interrompu avant les 10 secondes.
Configuration des serveurs utilisés
Dans un souci de transparence, l’Arcep publie un document récapitulant les paramètres des serveurs utilisés :
configuration des serveurs pour l’enquête QoS mobile Arcep 2022 (cliquez sur la miniature ci-dessous - le document est au format PDF)
(https://lafibre.info/images/barometre/202203_arcep_configuration_enquete_qos_mobile_2022.webp) (https://lafibre.info/images/barometre/202203_arcep_configuration_enquete_qos_mobile_2022.pdf)
-
Petit retour sur la polémique de la fin d'année 2021...
Le 19 novembre 2021, l'Arcep publie le rapport QoS mobile 2021, où Free apparaît en retrait, surtout quand on mesure avec une SIM 5G :
Débit descendant moyen avec une offre 5G :
- Free : seulement 32 Mb/s
- Orange : 227 Mb/s
- SFR : 145 Mb/s
- Bouygues Telecom : 130 Mb/s
C'est une mauvaise nouvelle pour Free qui axe sa communication sur "le plus grand réseau 5G de France".
Rapport Arcep QOS Mobile 2021 : Orange 1er, Bytel 2ème, SFR 3ème Free 4ème
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://lafibre.info/images/barometre/202111_arcep_qos_mobile_4.webp)
Source : Arcep (https://www.arcep.fr/actualites/les-communiques-de-presse/detail/n/qualite-des-services-mobiles-191121.html)
-
Suite à cette publication, Free a écrit une série de tweets accusant le protocole Arcep de ne pas refléter les usages réels des abonnés mobiles et les débits des abonnés Free Mobile.
C'est une communication très technique : Les termes BBR et Cubic qui ne sont pas utilisés par la presse même spécialisée apparaissent chacun deux fois. Le mot TCP apparait 9 fois, UDP deux fois, QUIC deux fois.
C’est comme tous les ans l’école des fans : ils ont l’impression tous d’avoir gagné
Il y en a un qui semble avoir moins gagné que les autres :
(https://lafibre.info/images/free_debit/202111_free_1337_tweet_campagne_arcep.png)
-
Dans son rapport sur l'état de l'internet 2022 publié le 30 juin 2022, l'Arcep laisse en premier de la place aux opérateurs pour s'exprimer.
Free, via Maxime Lombardini s'est exprimé de façon moins technique que dans la série de tweets :
(https://lafibre.info/images/barometre/202206_arcep_qos_mobile_free.webp)
SFR lance aussi une petite pique à Free, rappelant que "le débit 5G pouvant être inférieur au débit 4G chez certains opérateurs. Cette information gagnerait à être complétée pour démontrer au consommateur l'apport de la 5G en bande 3,5 GHz par opposition aux autres fréquences.".
(https://lafibre.info/images/barometre/202206_arcep_qos_mobile_sfr.webp)
Sollicité par l’Arcep, Orange n’a pas souhaité s’exprimer dans cette rubrique. L'exercice est en effet plus compliqué quand on est N°1.
-
Bouygues Telecom lance une petite pique à Free, rappelant qu'il a lancé la VoLTE en 2015.
(https://lafibre.info/images/barometre/202206_arcep_qos_mobile_bouygues.webp)
On note dans la contribution de Bouygues Telecom l'idée plusieurs évoqués aussi par d'autres acteurs de sortir de la communication sur le débit moyen. Le débit moyen poussant les opérateurs à proposer des débits toujours plus élevés (> 1 Gb/s) sans que cela ait un impact évident sur la QoS de l'utilisateur (au-delà de quelques dizaines de Mb/s, les gains pour l'utilisateur sont très faibles), alors que cette course aux débits à un cout financier et énergétique.
Une communication accès par tranche de débit comme dans cette communication de QoSi me plait bien. Pour un usage surf, il faut prendre l'opérateur qui le pourcentage le plus faible sur la ligne 0-5 Mb/s :
(https://lafibre.info/images/4g/202205_qosi_by_mozark_barometre_metro_mai_2022_5.webp)
-
L'Arcep détaille sur plusieurs pages les paramètres techniques influençant le débit :
Les paramètres techniques influençant le débit
Sur internet, un serveur émetteur de données n’a pas de connaissance du débit disponible de bout en bout. Il est pourtant primordial d’émettre la bonne quantité de données : en envoyer à un débit trop élevé, c’est prendre le risque de saturer une connexion bas débit. En envoyer trop peu ne permet pas d’exploiter efficacement la bande passante des connexions fibre. C’est un algorithme d’évitement de la congestion qui va estimer la capacité du lien entre le serveur et le client, en se basant sur la latence et la perte de paquets. L’algorithme, la latence et la perte de paquets sont 3 facteurs cruciaux pour permettre la disponibilité d’un bon débit.
1. La latence
La latence est le délai de transmission aller-retour d’une information sur le réseau. La latence est liée à 3 facteurs :
- La latence liée à la distance de fibre optique. La vitesse de la lumière dans un cœur de silice est de 200 000 000 m/s, soit 5 μs/km de fibre optique. Il faut multiplier ce chiffre par 2 pour avoir l’aller-retour. Il faut ajouter :
- 5 % pour les longueurs de love (surplus de câble rangé à l’aide de boucles) dans les différentes chambres télécom ;
- 1/7e de latence supplémentaire si la fibre est équipée de bobines de compensation de la dispersion chromatique.
Ce qui donne exactement 1,2 ms de latence aller-retour pour 100 kilomètres de fibre optique. Attention, la fibre optique empruntée n’utilise généralement pas un chemin en ligne droite, comme le fait un faisceau hertzien.
- La latence liée à la technologie d’accès à internet. Voici la latence typique rajoutée par technologie :- La fibre FttH (technologies Gpon, XGS-Pon ou 10G-Epon) : < 1 milliseconde ;
- Le réseau câble (Docsis 3.0) : entre 6 et 7 millisecondes ;
- Le réseau mobile 4G : entre 15 et 30 millisecondes ;
- Le réseau mobile 3G : entre 25 et 50 millisecondes ;
- Le réseau cuivre (technologies xDSL) : entre 5 et 45 millisecondes en fonction du paramétrage de « l’interleave* » pour protéger de la perte de paquets. Supprimer l’interleave permet une faible latence, mais la ligne n’est plus protégée et de nombreuses pertes de paquets (des « erreurs CRC ») vont dégrader la connexion. Un interleave de 16 millisecondes va protéger la ligne contre les bruits impulsionnels, mais va engendrer une latence supplémentaire de 32 millisecondes (16 ms aller + 16 ms retour). Les lignes bruitées ont besoin de plus de protection. Certains opérateurs permettent au client final de choisir le niveau de protection.
* Interleave L’interleave est une méthode qui consiste à découper des paquets de données en bits plus petits, puis à les réorganiser de manière à ce que des données autrefois contiguës soient désormais plus espacées pour former un flux non continu. Dans ce mode, lorsqu’une perturbation se produit, elle affecte en général un seul bit par octet, même si cela se produit dans un grand nombre d’octets.
- La latence liée aux mémoires-tampons (buffers), notamment en cas de congestion. Quand un lien reçoit plus de données qu’il ne peut en écouler, les paquets supplémentaires sont mis en attente dans une mémoire-tampon. Quand le buffer est plein, les paquets entrants supplémentaires sont supprimés.
Le paramétrage de la taille des buffers dans les équipements télécoms est une opération complexe :- Si le buffer est trop petit, les paquets sont rapidement supprimés, sans que l’algorithme d’évitement de congestion arrive à déterminer la capacité disponible sur le lien. Les débits seront alors anormalement faibles.
- Si le buffer est trop grand, l’algorithme d’évitement de la congestion peut ignorer que la liaison est encombrée. Il ne commencera alors à prendre des mesures correctives (diminuer le débit envoyé) qu’une fois que la mémoire-tampon déborde et que des paquets sont supprimés. Si on prend un exemple d’un buffer d’une seconde, toutes les connexions devront patienter une seconde pour passer le lien congestionné (les buffers utilisent la méthode First In First Out (FIFO) : le premier paquet entré est le premier paquet sorti). Les transferts de grande taille et le streaming vidéo seront peu affectés par cette latence importante, alors que les usages interactifs (chargement de pages web, jeux en réseau, contrôle à distance d’un équipement, etc.) seront fortement ralentis, voir inutilisables.
Cette latence anormalement élevée à cause du remplissage de buffers trop grand est appelée « bufferbloat ».
La bonne taille du buffer est ainsi la plus petite taille qui permet à l’algorithme d’évitement de congestion de comprendre où est la limite du débit du lien. Pour un lien de grande capacité agrégant les connexions de milliers d’utilisateurs, un buffer ne doit contenir que le strict minimum de données pour pouvoir remplir le lien pendant une saturation. Si le nombre d’octets du tampon ne descend jamais sous une certaine limite, alors cela veut dire qu’il est possible de diminuer le tampon d’autant. Ainsi, on conserve les performances, tout en réduisant au maximum les latences de type « bufferbloat ».
2. La perte de paquets
La perte de paquets se produit quand des paquets n’arrivent pas à destination. La perte est exprimée en pourcentage de paquets perdus par rapport aux paquets envoyés. Les deux causes de la
perte de paquets sont :
- Un réseau peu fiable qui peut entraîner des pertes de paquets.
C’est notamment le cas des réseaux sans fil (Wi-Fi, 4G, 5G, etc.), qui sont sensibles aux interférences radio. Une interférence ou un signal trop affaibli peut entraîner la corruption ou la perte des paquets en transit. La perte de paquets est mesurée par le BER (Bit Error Rate). Il est normal qu’un réseau Wi-Fi perde des paquets, 0,1% de paquets perdus est typiquement acceptable.
Une connexion ADSL peut également perdre des paquets si la ligne est bruitée et que l’interleave est réduit. Le manque de fiabilité du réseau peut également être dû à un matériel endommagé, à un bogue logiciel ou à un câble de mauvaise qualité.
- Une congestion réseau qui peut entraîner des pertes de paquets. Une fois la mémoire-tampon (buffer) remplie, les paquets entrants supplémentaires sont supprimés. C’est un mécanisme sain en cas de congestion, conserver trop de paquets dans le buffer entraînant du « bufferbloat ».
3. Les algorithmes d’évitement de la congestion
Cubic et BBR sont les algorithmes d’évitement de congestion les plus utilisés côté serveur.
- Cubic : aujourd’hui, Cubic est majoritairement utilisé sur internet. Créé en 2006, il s’appuie sur la perte de paquets comme signal pour réduire le débit. Cubic est l’algorithme d’évitement de congestion utilisé par défaut sous Linux (qui équipe la majorité des serveurs sur internet), mais aussi Android et macOS.
- BBR : Google a développé en 2016 BBR (Bottleneck Bandwidth and Round-trip propagation time), qui utilise un modèle différent, se basant sur la bande passante maximale et le temps d’aller-retour.
Cette approche permet à BBR, quand une connexion perd des paquets, de proposer un débit nettement plus élevé que ceux offerts par les algorithmes s’appuyant sur la perte de paquets, comme Cubic. Aujourd’hui, certains grands acteurs d’internet commencent à déployer BBR sur leurs serveurs. Cependant, BBR n’est pas encore généralisé sur internet notamment en raison d’une problématique d’équité des flux. En effet, sur un même lien où le débit est partagé entre utilisateurs (exemple : les fréquences du réseau mobile ou un lien fibre), les connexions BBR vont « prendre la place » des connexions Cubic. Une version « BBR v2 » est en développement pour améliorer la version actuelle et permettre une meilleure cohabitation avec Cubic.
-
Impact de la latence, de la perte de paquets et du protocole de congestion sur le débit
L'Arcep publie de nombreux tests, qui montrent que si un opérateur voit son débit chuter fortement avec le protocole de congestion Cubic, alors que le débit reste bon en BBR, c'est qu'il y a des pertes de paquets...
Le protocole de test
Les tests présentés ont été réalisés en laboratoire. Un serveur mis en place pour l’occasion est dédié aux tests et relié directement au client par un câble Ethernet à 1 Gbit/s de 2 mètres. La latence et la perte de paquets sont rajoutées avec le logiciel NetEm, intégré au noyau Linux. Le protocole suivi est celui des campagnes de mesure de la QoS mobile de l’Arcep : un fichier de 250 Mio1 est téléchargé en HTTPS. Le test est arrêté une fois les 250 Mio1 atteints, ou après expiration du délai de 10 secondes. Le serveur est configuré selon le document configuration des serveurs pour l’enquête QoS mobile Arcep 2022 (https://lafibre.info/images/barometre/202203_arcep_configuration_enquete_qos_mobile_2022.pdf)2. Afin de fiabiliser les résultats, chaque test a été refait plusieurs centaines de fois. Au total, plus de 58 000 tests3 ont été réalisés.
1 Mio, symbole d’unité du mébioctet valant 1024 Kio (Kibioctet) = 1024 x 1024 octets soit 1 048 576 octets. Un Mo (mégaoctet) vaut 1000 Ko soit 1 000 000 octets.
2 Une exception : la version d’Ubuntu utilisée est Ubuntu server 22.04 LTS.
3 Détails des tests réalisés (https://lafibre.info/testdebit/ubuntu/202205_debit_fichier_250mio_10sec.ods) (fichier au format OpenDocument, lisible dans un tableur).
Débit en fonction de la perte de paquets pour une latence aller-retour de 1 milliseconde
Cette latence extrêmement faible se rencontre principalement en entreprise, quand clients et serveurs sont sur le même site.
On note que le débit avec l’algorithme d’évitement de congestion Cubic baisse significativement par rapport à BBR à partir de 0,2 % de perte de paquets.
(https://lafibre.info/testdebit/ubuntu/202206_arcep_debit_fonction_latence_perte_protocole_congestion_1ms.webp)
Débit en fonction de la perte de paquets pour une latence aller-retour de 4 millisecondes
Débit en fonction de la perte de paquets pour une latence aller-retour de 4 millisecondes
Cette latence se rencontre principalement sur les réseaux FttH, quand le client et le serveur sont dans la même région et que le client est sur le même réseau que le serveur (ou que l’interconnexion entre les deux réseaux se fait également dans la région. Cela concerne principalement les parisiens qui utilisent un serveur Parisien, via une interconnexion située en région parisienne).
On note que le débit avec l’algorithme d’évitement de congestion Cubic baisse significativement par rapport à BBR à partir de 0,05 % de perte de paquets et passe sous les 100 Mbit/s quand on dépasse 1 % de paquets perdus.
(https://lafibre.info/testdebit/ubuntu/202206_arcep_debit_fonction_latence_perte_protocole_congestion_4ms.webp)
-
Débit en fonction de la perte de paquets pour une latence aller-retour de 16 millisecondes
Cette latence se rencontre principalement sur les réseaux FttH, quand le client et le serveur traversent plusieurs régions. Par exemple, la latence peut être de 16 millisecondes pour un client situé en région Auvergne-Rhône-Alpes qui utilise un serveur situé à proximité de son domicile, si le réseau du serveur est interconnecté avec celui du client à Paris. Le trajet réalisé peut être « client » => « Lyon (réseau du client) » => « Paris (réseau du client) » => « point de peering » => « Paris (réseau du serveur) » => « Lyon (réseau du serveur) » => « Serveur ».
On note que le débit avec l’algorithme d’évitement de congestion Cubic baisse significativement par rapport à BBR à partir de 0,05 % de perte de paquets. Le débit avec 0,5 % de perte de paquets est limité à 55 Mbit/s avec Cubic, contre 840 Mbit/s avec BBR.
(https://lafibre.info/testdebit/ubuntu/202206_arcep_debit_fonction_latence_perte_protocole_congestion_16ms.webp)
Débit en fonction de la perte de paquets pour une latence aller-retour de 32 millisecondes
Cette latence se rencontre principalement sur les réseaux 4G avec un serveur proche, ou sur le FttH, quand le serveur est situé hors de France (mais en Europe).
Le débit avec 0,5 % de perte de paquets est limité à 44 Mbit/s avec Cubic, contre 759 Mbit/s avec BBR.
(https://lafibre.info/testdebit/ubuntu/202206_arcep_debit_fonction_latence_perte_protocole_congestion_32ms.webp)
-
Débit en fonction de la perte de paquets pour une latence aller-retour de 64 millisecondes
Cette latence se rencontre principalement sur les réseaux 4G, quand le serveur est situé hors de France (mais en Europe).
On note que le débit avec l’algorithme d’évitement de congestion Cubic baisse significativement par rapport à BBR à partir de 0,02 % de perte de paquets et passe sous les 100 Mbit/s quand on dépasse 0,3 % de perte de paquets.
(https://lafibre.info/testdebit/ubuntu/202206_arcep_debit_fonction_latence_perte_protocole_congestion_64ms.webp)
Débit en fonction de la perte de paquets pour une latence aller-retour de 128 millisecondes
Cette latence se rencontre principalement sur les réseaux 4G, quand le serveur est situé outre-Atlantique.
Le débit n’est plus que de 9 Mbit/s s’il y a 0,5 % de perte de paquets avec Cubic.
(https://lafibre.info/testdebit/ubuntu/202206_arcep_debit_fonction_latence_perte_protocole_congestion_128ms.webp)
-
Débit en fonction de la latence pour une perte de paquets de 0,1 % et 1 %
Une perte de paquets de 0,1 % peut facilement se rencontrer sur un réseau Wi-Fi et une perte de 1 % sur un réseau qui subit une congestion.
On voit que l’impact sur le débit dépend fortement de la latence et de l’algorithme d’évitement de congestion.
(https://lafibre.info/testdebit/ubuntu/202206_arcep_debit_fonction_latence_perte_protocole_congestion_perte.webp)
Tester par vous-même Cubic vs BBR ?
Vous pouvez donc faire des tests mono-connexion Cubic vs BBR.
Tutoriel pour tester son débit et comprendre les limitations
(cliquez sur la miniature ci-dessous - le document est au format PDF)
(https://lafibre.info/testdebit/linux/tuto_test_debit.webp) (https://lafibre.info/testdebit/linux/tuto_test_debit.pdf)
-
Partie "mesure de la qualité d'internet" lors de la présentation du rapport sur l'état de l'internet :
https://lafibre.info/videos/arcep/202206_arcep_rapport_etat_internet_2_qos.mp4
L'Arcep interview quatre autres régulateurs sur le sujet de la mesure de débit
RTR, l'Autorité autrichienne de régulation de la radiodiffusion et des télécommunications qui édite l'outil open source https://www.netztest.at/en/
(https://lafibre.info/images/barometre/202206_arcep_qos_mobile_rtr.webp)
Nkom, l’Autorité norvégienne des communications :
(https://lafibre.info/images/barometre/202206_arcep_qos_mobile_nkom.webp)
-
La Bundesnetzagentur, l’Agence fédérale des réseaux en Allemagne :
(https://lafibre.info/images/barometre/202206_arcep_qos_mobile_bundesnetzagentur.webp)
Traficom : Agence finlandaise des transports et des communications :
(https://lafibre.info/images/barometre/202206_arcep_qos_mobile_traficom.webp)
-
Le choix de l’Arcep : le protocole de l’Arcep prévoit 50 % des tests réalisés en IPv4 et 50 % des tests réalisés en double pile (dual stack) IPv4/IPv6.
Là il est question du serveur, mais il faudrait préciser celle du téléphone.
Les réglages par défaut des APN dépendent du modèle, et peuvent changer lors des mises à jour.
-
C'est un peu tôt je pense pour donner exactement le modèle et la version du téléphone. Habituellement il me semble que c'est un Samsung et un iPhone récent. Il faudrait retrouver ceux de cette année et l'an dernier.
-
Le choix de l’Arcep : le protocole de l’Arcep prévoit 50 % des tests réalisés en IPv4 et 50 % des tests réalisés en double pile (dual stack) IPv4/IPv6.
Là il est question du serveur, mais il faudrait préciser celle du téléphone.
Les réglages par défaut des APN dépendent du modèle, et peuvent changer lors des mises à jour.
C'est un flou volontaire qui masque une différence entre métropole et Drom :
- En métropole, l'IPv6 est activé sur tous les téléphones (c'est déjà le cas par défaut chez Bouygues, Orange et SFR, c'est par contre une activation manuelle chez Free). On aura donc 100% des tests réalisés avec APN IPv6.
- Dans les Drom, il me semble qu'il n'y a plus d'opérateur proposant IPv6. Le seul opérateur qui proposait de l'IPv6, Zeop qui a arrêté de faire de l'IPv6 quelques mois sur le fixe comme sur le mobile. Je dis temporairement, car l'obligation d'IPv6 ready sur les mobiles arrive d'ici à la fin de l'année 2022 à la Réunion où est présent Zeop.
-
Je ne comprends pas très bien l'intérêt d'expliquer tous les tenants et aboutissants des protocoles de tests au préalable à la campagne de test.
C'est un peu comme si tu disais : Concours d'entrée aux ENS/Polytechnique, Questions du concours de cette année.
Globalement, les concours d'entrée ont une base commune connue de tous, et elle diffère peu d'année en année.
Les résultats et classements sont donnés à postériori.
La l'ARCEP dit, voila le protocole de test de cette année, voila ce que l'on va tester, et comment, il manquerait plus que dire quand !
Vous voulez pas poser la question aux opérateurs sur quoi ils voudraient être testés non plus ?
Alors cela plait pas à un opérateur, il dit publiquement, votre test ne nous classe pas bien, il est pourri.
C'est comme dire, je n'ai pas été admis aux ENS/Polytechnique, j'ai eu que Centrale, il est pourri le concours des ENS.
Evidemment que les opérateurs si ils sont pas classés premiers, ils vont y trouver à redire.
Et que dit Free au juste ? Polémique publique l'année dernière, elle va être reconduite cette année. Bien, on le sait dont acte.
Tempête dans un verre d'eau pour bientôt.
Le champ de polémique sera de nouveau médiatique, pas technique, sur des critères tellement techniques, que seule les barbus seraient en mesure de différentier. Même chez les informaticiens, va leur dire que l'ARCEP a fait un test sur un serveur en protocole de congestion BBR ou Cubic, ou l'un à la place de l'autre. La bonne blague. La majorité va regarder l'ARCEP en pensant, ils sont tombés sur la tête, tout le monde s'en fout du protocole de congestion, cela ne parle à personne. Ce qui nous parle à nous c'est notre perception de l'utilisation, même si elle est fausse, c'est ce que l'on perçoit qui va faire que l'on va préférer un opérateur à un autre, par le protocole de congestion des serveurs de l'opérateur.
Si l'ARCEP ne lie pas les protocoles de test d'une manière technique avec un organisme de marketing de perception du consommateur de l'utilisation de la téléphonie mobile, l'ARCEP va ouvrir le flanc à toutes les récriminations techniques des opérateurs.
C'est pas le rôle de l'ARCEP de faire jouer la concurrence sur les services techniques apportés par les opérateurs, l'ARCEP c'est un gendarme et un juge de paix, c'est pas un "market maker".
-
La l'ARCEP dit, voila le protocole de test de cette année, voila ce que l'on va tester, et comment, il manquerait plus que dire quand !
Tu peux dire à Free quand tu vas les tester c'est pas pour autant que le Cubic ou le mono connexion marchera mieux vu que c'est à priori plutôt expliqué par des congestions/perte de paquets. Tant que tu leur donnes pas les URL à prioriser ^^
Je pense au contraire qu'être transparent sur ce qu'on mesure est une bonne chose puisque cela permet à qui le veut de répliquer le protocole de test (approche classique dans le monde des sciences)
-
Ce qui change cette année, c'est que le protocole est dévoilé au grand public.
Depuis toujours, les opérateurs ont en avance de phase le protocole exact, les mobiles utilisés et le calendrier macro. Ce protocole est réalisé en prenant l'avis des opérateurs (cela ne veut pas dire que l'Arcep va suivre aveuglément l'avis des opérateurs, mais analyser chaque demande, pour souvent garder ce qui est le plus représentatif) - et au passage l'année dernière Free n'avait rien dit quand l'Arcep a proposé de faire les tests en mono-connexion Cubic. Ils ont été défavorables au protocole qu'une fois les tests réalisés.
Oui, les opérateurs optimisent leur réseau en partie en utilisant le protocole Arcep. C'est pour cette raison qu'il doit être le plus représentatif possible de manière a ce que les optimisations profitent pleinement aux vrais clients. Plus les années passent et plus on utilise les paramètres par défaut. Les traces de chaque mesure sont données aux opérateurs qui peuvent analyser chaque contre-performance et comprendre d'où elle venait.
Un exemple de demande de modification du protocole : Le TCP Offload Engine (TOE) que le protocole demande de laisser à sa valeur par défaut (cela n'a pas toujours été le cas dans le passé) : Un opérateur a demandé que l'on force son activation, un autre opérateur a demandé qu'on force sa désactivation. L'Arcep a gardé sa proposition initiale de le garder à sa valeur par défaut (donc probablement activé) qui est probablement le cas sur la grande majorité des serveurs.
Les opérateurs ne savent par où l'Arcep réalise les tests en avance. Certains opérateurs déploiement des méthodes ingénieuses pour tenter de trouver la zone des tests, mais l'Arcep fait attention. C'est terminé l'époque (il y a 10 ans) où les opérateurs choisissaient les forfaits de la campagne, avec un petit malin qui avait créé un forfait spécial Arcep (caché, pas intéressant, avec nécessité de se déplacer en boutique et de demander le forfait spécial). Maintenant c'est un mélange aléatoire de tout ce qui est proposé (avec / sans engagement) et les forfait ne sont pas souscrits au nom de l'Arcep.
-
Et que dit Free au juste ? Polémique publique l'année dernière, elle va être reconduite cette année. Bien, on le sait dont acte.
Tempête dans un verre d'eau pour bientôt.Ce qui change cette année, c'est que le protocole est dévoilé au grand public.
Gageons que cela va couper court a toute velléité de polémique, quel que soit l'opérateur.
-
Peu probable, le protocole retenu n'est pas celui qui donne de bonnes perf à FM.
(j'énonce juste un fait, il n'est pas nécessaire de refaire une n-ième fois le débat associé)
-
Partie "mesure de la qualité d'internet" lors de la présentation du rapport sur l'état de l'internet :
https://lafibre.info/videos/arcep/202206_arcep_rapport_etat_internet_2_qos.mp4
-
Gageons que cela va couper court a toute velléité de polémique, quel que soit l'opérateur.
En fait, les opérateurs sont au courant des conditions de test, depuis ... pffff (toujours ? ).
C’est ce qui est magique dans ces polémiques à la con. :)
-
Il y a des évolutions chaque année, mais pas de révolution, cela se fait toujours relativement progressivement
Ex: 100% http puis 50% http 50% https puis 100% https
-
Voici comment sont testés les réseaux de Bouygues Telecom, Free Mobile, Orange et SFR
https://lafibre.info/videos/arcep/202207_01net_comment_arcep_mesure_la_qualite_de_service_mobile.mp4
https://www.01net.com/actualites/voici-comment-sont-testes-les-reseaux-de-bouygues-telecom-free-mobile-orange-et-sfr.html
-
Superbe reportage d'Amélie Charnay
Photo de la campagne de mesure Arcep : (source: 01net (https://www.01net.com/actualites/voici-comment-sont-testes-les-reseaux-de-bouygues-telecom-free-mobile-orange-et-sfr.html))
(https://lafibre.info/images/5g/202207_01net_comment_arcep_mesure_la_qualite_de_service_mobile.jpg)
(https://lafibre.info/images/5g/202207_01net_comment_arcep_mesure_la_qualite_de_service_mobile_1.webp)
-
D'autres photos de la valide :
(https://lafibre.info/images/5g/202207_01net_comment_arcep_mesure_la_qualite_de_service_mobile_2.webp)
(https://lafibre.info/images/5g/202207_01net_comment_arcep_mesure_la_qualite_de_service_mobile_3.webp)
-
Les 6 ventillateurs :
(https://lafibre.info/images/5g/202207_01net_comment_arcep_mesure_la_qualite_de_service_mobile_4.webp)
(https://lafibre.info/images/5g/202207_01net_comment_arcep_mesure_la_qualite_de_service_mobile_5.webp)
-
Les 9 mobiles de la valide :
(https://lafibre.info/images/5g/202207_01net_comment_arcep_mesure_la_qualite_de_service_mobile_6.webp)
(https://lafibre.info/images/5g/202207_01net_comment_arcep_mesure_la_qualite_de_service_mobile_7.webp)
-
Les tests :
(https://lafibre.info/images/5g/202207_01net_comment_arcep_mesure_la_qualite_de_service_mobile_8.webp)
-
L'ARCEP est malhonnête avec son histoire de grand public vs pros. Déjà c'est nPerf qui est visé sans être nommé. Ensuite nPerf aussi fait des campagnes de tests pros. Enfin l'ARCEP fait ses tests avec 5G Mark, qui existe en version grand public et dont elle reprend également des données issues de tests grand public.
-
Non les tests ne sont pas réalisé avec 5G Mark Pro.
C'est AFD.TECH qui fait les tests en métropole et ce n'est pas 5G Mark Pro qui est utilisé.
5G Mark (et plus généralement les outils développé par QoSi) sont des outils proche du protocole Arcep (c'est le positionnement de QoSi : suivre les protocoles Arcep), mais dans la catégorie des tests multi-connexions, il n'y a pas que nPerf. Il y a de nombreux outils disponibles en multi-connexion au-delà des nPerf ou SpeedTest d'Ookla.
nPerf propose dans sa version payante des tests mono-connexion. SpeedTest d'Ookla propose aussi des tests mono-connexion (gratuitement).
La problématique remontée dans le rapport sur l'état de l'internet 2022 de l'Arcep, c'est que BBR vs Cubic a un impact important et que peu d'outils indiquent si on est sur un serveur BBR, Cubic ou autre.
-
Pas plus que Free qui connaît le protocole à l’avance et qui le critique ensuite en inventant des histoires de réseau optimisé pour des protocoles soi disant ultra moderne pour une meilleure expérience utilisateur alors que c’est juste un réseau non neutre et construit à l’économie.
-
Réseau non neutre, c'est quand même assez fort comme terme.
Pour moi Free est neutre, mais il perd potentiellement des paquets :
Débit en fonction de la perte de paquets pour une latence aller-retour de 16 millisecondes
On note que le débit avec l’algorithme d’évitement de congestion Cubic baisse significativement par rapport à BBR à partir de 0,05 % de perte de paquets. Le débit avec 0,5 % de perte de paquets est limité à 55 Mbit/s avec Cubic, contre 840 Mbit/s avec BBR.
(https://lafibre.info/testdebit/ubuntu/202206_arcep_debit_fonction_latence_perte_protocole_congestion_16ms.webp)
-
Réseau non neutre, c'est quand même assez fort comme terme.
Dans la mesure où il faut utiliser un protocole de congestion et pas un autre pour avoir des performances optimales et faire du multi thread car en mono c’est pas du tout optimal, et qu’en plus c’est revendiqué et assumé, il y a clairement une différence de traitement selon les serveurs et les trajets, c’est bien la définition de la non neutralité. Le distingo ne se fait pas sur des destinations précises mais sur des configurations techniques précises.
-
Pas plus que Free qui connaît le protocole à l’avance et qui le critique ensuite en inventant des histoires de réseau optimisé pour des protocoles soi disant ultra moderne pour une meilleure expérience utilisateur alors que c’est juste un réseau non neutre et construit à l’économie.
Google et tous leurs services fonctionnent sous bbr (bon, après c'est eux qui le développent), faut en déduire que c'est à l'économie aussi ?
-
Dans la mesure où il faut utiliser un protocole de congestion et pas un autre pour avoir des performances optimales et faire du multi thread car en mono c’est pas du tout optimal, et qu’en plus c’est revendiqué et assumé, il y a clairement une différence de traitement selon les serveurs et les trajets, c’est bien la définition de la non neutralité. Le distingo ne se fait pas sur des destinations précises mais sur des configurations techniques précises.
C'est juste que le mode de test cache plus ou moins les saturations et autres problèmes. Je ne pense pas qu'il faille y voir plus.
-
Pas plus que Free qui connaît le protocole à l’avance et qui le critique ensuite en inventant des histoires de réseau optimisé pour des protocoles soi disant ultra moderne pour une meilleure expérience utilisateur alors que c’est juste un réseau non neutre et construit à l’économie.
+1
-
il y a clairement une différence de traitement selon les serveurs et les trajets, c’est bien la définition de la non neutralité. Le distingo ne se fait pas sur des destinations précises mais sur des configurations techniques précises.
Non, car Free ne fait pas de différence de traitement entre les serveurs et les trajets, c'est simplement que son réseau est assez limité en monothread, et que cela se voit moins en multhread.
La non neutralité du net, c'est quand tu privilégies un type de flux par rapport à d'autres. Par exemple, en 2013/2014, Free mobile bridait les flux en streaming, gros consommateurs de données, et les flux en https, car il ne pouvait pas savoir si c'était du streaming qui passait dedans. Là, il y avait clairement violation de la neutralité du Net. Ce n'est plus le cas maintenant, et l'ARCEP a des protocoles de test pour savoir si la neutralité est violée ou pas.
-
Les flux BBR ne sont pas traités de la même manière que les flux sur serveurs Cubic. C’est donc une différence de traitement. Mais bon, on connait la complaisance à l’égard de Free de certains…
La preuve c’est que les 3 autres, BBR/Cubic ou mono/multi ça ne change pas les résultats. Et ça, à mon avis, ça a son importance.
-
Google et tous leurs services fonctionnent sous bbr (bon, après c'est eux qui le développent), faut en déduire que c'est à l'économie aussi ?
LOL 😂 quel rapport? Parce que Free pensait qu’en favorisant BBR, ils allaient avoir un réseau du niveau de celui de Google parce que Google l’utilise?! Free fait le choix de BBR pas pour ses performances mais parce qu’il permet de masquer certains insuffisances de son réseau. Point. Un réseau neutre et efficace fonctionne pareil avec et sans BBR. Que Google ou autre s’en sert ou pas n’a rien à voir avec Free ou son réseau.
-
On a parlé de Google, car c'est l'un des principaux acteurs à avoir massivement déployé BBR.
Pour la neutralité, si (c'est une hypothèse) le réseau perd des paquets, il est normal d'avoir de bien meilleurs débits en BBR, algorithme qui se débrouille bien mieux dans ce cas.
Le fait d'avoir un réseau qui à 0,2% de perte de paquets n'est pas une infraction à la neutralité du net.
Enfin la question pourrait être pourquoi les distributions Linux, Apple ou même Google pour Android ne remplacent pas Cubic par BBR, la réponse est là :
Cependant, BBR n’est pas encore généralisé sur internet notamment en raison de problématiques d’équité des flux. En effet, sur un même lien où le débit est partagé entre utilisateurs (exemple : les fréquences du réseau mobile ou un lien fibre), les connexions BBR vont « prendre la place » des connexions Cubic. Une version « BBR v2 » est en développement pour améliorer la version actuelle et permettre une meilleure cohabitation avec Cubic.
-
LOL 😂 quel rapport? Parce que Free pensait qu’en favorisant BBR, ils allaient avoir un réseau du niveau de celui de Google parce que Google l’utilise?! Free fait le choix de BBR pas pour ses performances mais parce qu’il permet de masquer certains insuffisances de son réseau. Point. Un réseau neutre et efficace fonctionne pareil avec et sans BBR. Que Google ou autre s’en sert ou pas n’a rien à voir avec Free ou son réseau.
Mais il est neutre le réseau Free ! Non ?
Enfin quant on regarde les usages normaux, hors speedtest, c'est au même niveau que les opérateurs en Cubic par exemple.
-
On a parlé de Google, car c'est l'un des principaux acteurs à avoir massivement déployé BBR.
Pour la neutralité, si (c'est une hypothèse) le réseau perd des paquets, il est normal d'avoir de bien meilleurs débits en BBR, algorithme qui se débrouille bien mieux dans ce cas.
Le fait d'avoir un réseau qui à 0,2% de perte de paquets n'est pas une infraction à la neutralité du net.
Enfin la question pourrait être pourquoi les distributions Linux, Apple ou même Google pour Android ne remplacent pas Cubic par BBR, la réponse est là :
Semblerait que Netflix aussi soit en bbr.
-
Mais il est neutre le réseau Free ! Non ?
C'est surtout le fait que Free connaissait à l'avance le protocole utiliser lors des tests et ont chouiner sur Twitter après alors qu'ils n'ont pas bouger le p'tit doigt pour régler la chose et pour moi c'est totalement volontaire car ça pouvais servir d'excuse en cas de mauvais résultats
-
Cette histoire de Cubic vs BBR ça s'applique qu'au mobile ou aussi au fixe ?
Je ne constate pas de différence au niveau mobile ou même fixe sur un speedtest. C'est localisé à certains endroits ce problème ou bien c'est national ?
-
Je ne comprends pas très bien l'intérêt d'expliquer tous les tenants et aboutissants des protocoles de tests au préalable à la campagne de test.
C'est un peu comme si tu disais : Concours d'entrée aux ENS/Polytechnique, Questions du concours de cette année.
Globalement, les concours d'entrée ont une base commune connue de tous, et elle diffère peu d'année en année.
Les résultats et classements sont donnés à postériori.
La l'ARCEP dit, voila le protocole de test de cette année, voila ce que l'on va tester, et comment, il manquerait plus que dire quand !
Vous voulez pas poser la question aux opérateurs sur quoi ils voudraient être testés non plus ?
Alors cela plait pas à un opérateur, il dit publiquement, votre test ne nous classe pas bien, il est pourri.
C'est comme dire, je n'ai pas été admis aux ENS/Polytechnique, j'ai eu que Centrale, il est pourri le concours des ENS.
Evidemment que les opérateurs si ils sont pas classés premiers, ils vont y trouver à redire.
Et que dit Free au juste ? Polémique publique l'année dernière, elle va être reconduite cette année. Bien, on le sait dont acte.
Tempête dans un verre d'eau pour bientôt.
Le champ de polémique sera de nouveau médiatique, pas technique, sur des critères tellement techniques, que seule les barbus seraient en mesure de différentier. Même chez les informaticiens, va leur dire que l'ARCEP a fait un test sur un serveur en protocole de congestion BBR ou Cubic, ou l'un à la place de l'autre. La bonne blague. La majorité va regarder l'ARCEP en pensant, ils sont tombés sur la tête, tout le monde s'en fout du protocole de congestion, cela ne parle à personne. Ce qui nous parle à nous c'est notre perception de l'utilisation, même si elle est fausse, c'est ce que l'on perçoit qui va faire que l'on va préférer un opérateur à un autre, par le protocole de congestion des serveurs de l'opérateur.
Si l'ARCEP ne lie pas les protocoles de test d'une manière technique avec un organisme de marketing de perception du consommateur de l'utilisation de la téléphonie mobile, l'ARCEP va ouvrir le flanc à toutes les récriminations techniques des opérateurs.
C'est pas le rôle de l'ARCEP de faire jouer la concurrence sur les services techniques apportés par les opérateurs, l'ARCEP c'est un gendarme et un juge de paix, c'est pas un "market maker".
J'avais pas encore vu ce post, je suis d'accord avec la dernière partie. Faut final, le client s'en fout royalement des baromètres ARCEP, déjà si ils en entendent parler, c'est déjà pas mal. Leurs choix va plus se porter sur le prix (surtout avec jumelage d'une offre fixe) ou l'expérience perso en fonction de leurs localisations (le sans engagement et la facilité de changer d'opérateur aidant fortement aux choix).
-
Cette histoire de Cubic vs BBR ça s'applique qu'au mobile ou aussi au fixe ?
Je ne constate pas de différence au niveau mobile ou même fixe sur un speedtest. C'est localisé à certains endroits ce problème ou bien c'est national ?
Tutoriel pour tester son débit et comprendre les limitations
(cliquez sur la miniature ci-dessous - le document est au format PDF)
(https://lafibre.info/testdebit/linux/tuto_test_debit.webp) (https://lafibre.info/testdebit/linux/tuto_test_debit.pdf)
-
En wifi, ça compte ?
-
Et via le pc en filaire et navigateur (pas trouvé le choix mono/multi dans la version appli)
Pour le coup, meilleur résultat (en UP) en Cubic ;D
-
Trés bon tests Myck205. C'est l'exemple parfait de ce qui est attendu par une ligne 1 Gb/s sans défaut.
C'est normal pour une ligne parfaitement propre, Cubic est un tout petit peu devant BBR en descendant. Pour l'upload, je constate la même chose, je ne sais pas l'expliquer.
Bref, ligne fixe qui est parfaite.
Cela serait bien d'avoir les mêmes résultats sur le mobile.
-
Trés bon tests Myck205. C'est l'exemple parfait de ce qui est attendu par une ligne 1 Gb/s sans défaut.
C'est normal pour une ligne parfaitement propre, Cubic est un tout petit peu devant BBR.
Bref, ligne fixe qui est parfaite.
Cela serait bien d'avoir les mêmes résultats sur le mobile.
Sur le mobile, j'ai les mêmes résultats. Peut-être un ensemble d'antennes parfaites.
Bref, du coup, sur le fixe, on peut en déduire que c'est pas national.
-
On a parlé de Google, car c'est l'un des principaux acteurs à avoir massivement déployé BBR.
...
Enfin la question pourrait être pourquoi les distributions Linux, Apple ou même Google pour Android ne remplacent pas Cubic par BBR, la réponse est là :
...
Il n'y a pas que BBR vs Cubic/Lereste comme problème. BBR se phagocite lui-même suivant les conditions de bande passante et privilégie les flux à plus longue latence.
-
Non les tests ne sont pas réalisé avec 5G Mark Pro.
C'est AFD.TECH qui fait les tests en métropole et ce n'est pas 5G Mark Pro qui est utilisé.
5G Mark (et plus généralement les outils développé par QoSi) sont des outils proche du protocole Arcep (c'est le positionnement de QoSi : suivre les protocoles Arcep), mais dans la catégorie des tests multi-connexions, il n'y a pas que nPerf. Il y a de nombreux outils disponibles en multi-connexion au-delà des nPerf ou SpeedTest d'Ookla.
nPerf propose dans sa version payante des tests mono-connexion. SpeedTest d'Ookla propose aussi des tests mono-connexion (gratuitement).
La problématique remontée dans le rapport sur l'état de l'internet 2022 de l'Arcep, c'est que BBR vs Cubic a un impact important et que peu d'outils indiquent si on est sur un serveur BBR, Cubic ou autre.
Ah ça nest plus QoSi, c'est quoi alors?
De toutes manières ça ne change rien au fait que le discours de l'ARCEP est fallacieux sur ce point.
-
Il y a des appels d'offre chaque année et pour la métropole, cette année, pour les tests data, c'est AFD.TECH.
Je ne suis pas sûr que ce soit le même prestataire pour les tests voix / sms.
C'est quoi le point problématique des tests ?
-
Le problème ? Tant que Free ne sera pas numéro 1, freedor râlera.
-
Comme je l’ai déjà dit, le seul moyen pour calmer Free et ses fanboys c’est que Free transmette directement les chiffres qu’ils voudraient voir dans les résultats. Sinon c’est « fallacieux ».
-
Il y a des appels d'offre chaque année et pour la métropole, cette année, pour les tests data, c'est AFD.TECH.
Je ne suis pas sûr que ce soit le même prestataire pour les tests voix / sms.
C'est quoi le point problématique des tests ?
Je ne parlais pas des tests mais du discours lunaire de l'ARCEP sur les outils de tests grand public.
-
Si l'ARCEP n'explique pas ça ne va pas.
Si l'ARCEP détaille son protocole c'est lunaire.
-
Je ne parlais pas des tests mais du discours lunaire de l'ARCEP sur les outils de tests grand public.
Je ne vois pas le problème, ils expliquent juste pourquoi la stratégie n'est pas la même et n'arrivera pas forcément aux mêmes résultats. C'est quoi le problème ?
-
De mon côté chez Free Mobile, entre Cubic et BBR c'est pas la même mayonnaise... Je vous laisse juge !
On notera tout de même l'uload, une constante très frustrante du réseau mobile, toujours très faible (et encore, c'est plus souvent vers les 1 Mbps...)
-
Je ne vois pas le problème, ils expliquent juste pourquoi la stratégie n'est pas la même et n'arrivera pas forcément aux mêmes résultats. C'est quoi le problème ?
Le résultat.
-
guiest63 il pourrait être intéressant de tester en 4G également.
Moi c'est ce qui m'a étonné en réalisant des tests avec Free mobile sur des sites 5G 700 Mhz : on a un meilleur débit en 4G.
3 Mb/s en débit montant, cela semble anormalement faible.
-
Les résultats 4G ne sont en tout cas pas ici meilleurs qu'en 5G
Oui l'upload est très faible, toujours constaté chez Free sous Android (11, OnePlus Nord 5G) et depuis que j'ai changé pour Apple.
Là, le classement Cubic et BBR semble inversé, mais le résultat est pas bon de toute manière.
Peu-être le réseau Free Mobile à Clermont n'est pas hyper développé (ceci dit je n'ai pas l’impression que le nombre d'antenne soit très faible par rapport aux autres opérateurs)
-
5G BBR vs Cubic, effectivement il y a de la perte, seulement 450mega, misérable :(
-
5G BBR vs Cubic, effectivement il y a de la perte, seulement 450mega, misérable :(
Le fait qu'il y ait une différence indique déjà une saturation. Je dis pas que c'est forcément gravissime mais toujours est-il que c'est le cas.
-
Le fait qu'il y ait une différence indique déjà une saturation. Je dis pas que c'est forcément gravissime mais toujours est-il que c'est le cas.
ça non plus c'est pas nouveau, évidemment que c'est impossible d'avoir un bon réseau backhaul avec les prix pratiquer ça se serait sinon...
-
Le fait qu'il y ait une différence indique déjà une saturation. Je dis pas que c'est forcément gravissime mais toujours est-il que c'est le cas.
Saturation à quel niveau ? Juste l'antenne ?
Parce que niveau collecte, c'est la même que le fixe et pas de saturation sur le fixe.
-
ça non plus c'est pas nouveau, évidemment que c'est impossible d'avoir un bon réseau backhaul avec les prix pratiquer ça se serait sinon...
Dit il en étant chez RED ;D
-
Saturation à quel niveau ? Juste l'antenne ?
Parce que niveau collecte, c'est la même que le fixe et pas de saturation sur le fixe.
Aucune idée, mais ça ne serait pas une surprise que ça sature au niveau radio oui.
-
Dit il en étant chez RED ;D
Je suis chez Orange demain, pour te faire plaisir je peux changer tout de suite le FAI sur mon profile si tu veux :)
-
Aucune idée, mais ça ne serait pas une surprise que ça sature au niveau radio oui.
vivien n'a pas plutôt laissé entendre que la différence de débit serait plutôt liée à des pertes de paquets ?
-
vivien n'a pas plutôt laissé entendre que la différence de débit serait plutôt liée à des pertes de paquets ?
Speedtest indique 0%. Info non viable ?
-
Pas nécessairement, le débit réduit peut permettre de rester à 0 via des retransmissions par exemple. Enfin je laisse vivien préciser :).
-
vivien n'a pas plutôt laissé entendre que la différence de débit serait plutôt liée à des pertes de paquets ?
J'avais supposé que c'était lié à une saturation mais j'en sais rien en vrai...
-
Une saturation se produit principalement le soir. Il y a d'autres causes de pertes de paquets comme évoqué :
2. La perte de paquets
La perte de paquets se produit quand des paquets n’arrivent pas à destination. La perte est exprimée en pourcentage de paquets perdus par rapport aux paquets envoyés. Les deux causes de la
perte de paquets sont :
- Un réseau peu fiable qui peut entraîner des pertes de paquets.
C’est notamment le cas des réseaux sans fil (Wi-Fi, 4G, 5G, etc.), qui sont sensibles aux interférences radio. Une interférence ou un signal trop affaibli peut entraîner la corruption ou la perte des paquets en transit. La perte de paquets est mesurée par le BER (Bit Error Rate). Il est normal qu’un réseau Wi-Fi perde des paquets, 0,1% de paquets perdus est typiquement acceptable.
Une connexion ADSL peut également perdre des paquets si la ligne est bruitée et que l’interleave est réduit. Le manque de fiabilité du réseau peut également être dû à un matériel endommagé, à un bogue logiciel ou à un câble de mauvaise qualité.
- Une congestion réseau qui peut entraîner des pertes de paquets. Une fois la mémoire-tampon (buffer) remplie, les paquets entrants supplémentaires sont supprimés. C’est un mécanisme sain en cas de congestion, conserver trop de paquets dans le buffer entraînant du « bufferbloat ».
Comme il n'y a pas une seule méthodologie pour tester de débit, il y a plusieurs méthodes pour mesurer la perte de paquet. Les outils SpeeTest sont plus des outils permettant d'avoir une information fiable sur le débit du lien, plutôt que ses pertes de paquets.
Une autre explication possible, c'est que les paquets dont TCP va demander la retransmission ne sont pas forcements perdus dans le sens où ils n'arrivent jamais. Ils peuvent arriver dé séquencé (après le paquet suivant). L'impact sur le débit est identique à une perte, même si le paquet n'est pas à proprement parlé perdu. Il est important pour TCP que les paquets d'une même connexion arrivent tous dans l'ordre. C'est pour cela que dans des lag n x 10 Gb/s ou n x 100 Gb/s, il y a un algorithme qui permet de garantir que tous les paquets d'une même connexion passeront par le même lien.
Le fait de perdre du débit en 5G, vs 4G only m'a fait me demander si les paquets 5G n'arrivent pas avant (ou après) le paquet 4G qui est juste derrière quand on est à haut débit. Il faudrait des captures coté mobile pour permettre de diagnostiquer ce qui ne va pas.
-
Ah oui j'avais oublié le cas où la qualité de la liaison radio est dégradée parce que tu es tout simplement en limite de couverture (ce qui est plus susceptible d'arriver chez Free puisqu'il y a moins d'antennes).
-
Pour compléter et finir, la situation sur freebox pop
Dans un premier temps, en Wifi (je sais…) sur iPhone 12 Pro, mais résultats identiques sur iPad
On notera la limite à 200 Mbps en up !
-
Et voici en Ethernet (mon CPU sature lors du test Download en BBR)
-
Sur les lignes fixes ça dépend beaucoup de l'endroit donc c'est compatible avec des saturations locales.
PS : L'upload est bizarrement bas.
-
Passer de 800mbps bbr à 100mbps cubic ? C'est chaud
-
Passer de 800mbps bbr à 100mbps cubic ? C'est chaud
« Chaud » n’est pas le qualificatif que j’utiliserais ;D
Sur les lignes fixes ça dépend beaucoup de l'endroit donc c'est compatible avec des saturations locales.
PS : L'upload est bizarrement bas.
Peut-être, je testerai à d’autres heures… Et je suis d’accord pour l’upload, sachant qu’en multi je monte bien à 700 Mbps. Par ailleurs j’ai un meilleur résultat sur l’iPad/iPhone en Wifi que sur le PC W11, je me pose des questions de limites lié au hardware ?
-
« Chaud » n’est pas le qualificatif que j’utiliserais ;D
Peut-être, je testerai à d’autres heures… Et je suis d’accord pour l’upload, sachant qu’en multi je monte bien à 700 Mbps. Par ailleurs j’ai un meilleur résultat sur l’iPad/iPhone en Wifi que sur le PC W11, je me pose des questions de limites lié au hardware ?
A l'usage, streaming, download classique, web, jeux, etc ça se ressent ?
-
En vrai pas vraiment (et c’est bien pour ça que je fais pas un scandale ^^)
J’habite seul en appartement, donc pas de consommation très intensive (pas de JV par exemple), et quelques téléchargements de temps en temps
Pas de ralentissement sur le streaming constate en tout cas (Netflix, YouTube et consort)
Toujours est-il que cela ne me semble pas bien normal non plus
-
Et voici en Ethernet (mon CPU sature lors du test Download en BBR)
Un réseau qui n'a pas de problème ne doit pas montrer une différence entre CUBIC et BBR. J'ai l'impression que l'on tourne en rond sur ces dernières pages ^^
-
Aller pour vous détendre, un article d'Univers Freebox (avec ses commentaires croustillants) : https://www.universfreebox.com/article/529260/qualite-de-service-mobile-free-juge-le-protocole-de-mesure-de-larcep-trop-complexe-et-prone-un-debat
Il reprend la contribution de Maxime Lombardini, publiée dans le rapport de l'Arcep sur l'état de l'internet (l'article ne le dit pas, mais on retrouve les mêmes phrases) mais par contre, il omet les deux pages de réponse réalisée par l'Arcep pour se justifier sur le protocole. C'est pourtant juste après la contribution de Free, page 29 (https://lafibre.info/images/doc/202206_arcep_rapport_etat_internet_2022.pdf#page=29). Ils ont oublié de tourner la page ?
Tout l'article est basé sur cette contribution extérieure : (contribution qui ne date pas du 1er juillet comme indiqué dans l'article, mais de nombreux mois avant, car le document est maquetté)
Dans son rapport sur l'état de l'internet 2022 publié le 30 juin 2022, l'Arcep laisse en premier de la place aux opérateurs pour s'exprimer.
Free, via Maxime Lombardini s'est exprimé de façon moins technique que dans la série de tweets :
(https://lafibre.info/images/barometre/202206_arcep_qos_mobile_free.webp)
-
Free a dévoilé aujourd'hui comment il réalise ses drives test.
Là où certains opérateurs externalisent ces tests (il y a plusieurs sociétés spécialisées dans les driver test), Free le fait en interne.
https://lafibre.info/videos/free/202209_free_mobile_drive_test.webm
une vidéo postée sur un nouveau compte Youtube (Free 1337 (https://www.youtube.com/channel/UCAyrJdGH-NPNxwkk2WKIpOw) qui se rajoute à la chaine Youtube Free (https://www.youtube.com/channel/UCzoLVwQrGOBlfzrma3FiJbg) et à la chaine Iliad (https://www.youtube.com/channel/UCIPsMRZ9208ceXgsCJovFDA), ce qui me semble beaucoup pour les activités d'Iliad en France d'avoir 3 chaines Youtube)
Il me semble avoir déjà vu le sac à dos ailleurs...
https://lafibre.info/videos/arcep/202207_01net_comment_arcep_mesure_la_qualite_de_service_mobile.mp4