Auteur Sujet: L'Arcep dévoile le protocole des campagnes de mesure de la QoS mobile 2022 (Lu 21751 fois)

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)

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)

vivien · « **Réponse #1 le:** 30 juin 2022 à 08:46:15 »

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".

Citation de: Nico le 19 novembre 2021 à 09:24:31

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.

Source : Arcep

vivien · « **Réponse #2 le:** 30 juin 2022 à 08:46:29 »

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.

Citation de: vivien le 22 novembre 2021 à 15:51:29

Citation de: Nikos le 19 novembre 2021 à 10:39:05
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 :

vivien · « **Réponse #3 le:** 30 juin 2022 à 08:46:43 »

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 :

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.".

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.

vivien · « **Réponse #4 le:** 30 juin 2022 à 08:46:56 »

Bouygues Telecom lance une petite pique à Free, rappelant qu'il a lancé la VoLTE en 2015.

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 :

Citation de: vivien le 20 juin 2022 à 14:07:52

vivien · « **Réponse #5 le:** 30 juin 2022 à 08:47:12 »

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.

vivien · « **Réponse #6 le:** 30 juin 2022 à 08:47:28 »

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 Mio¹ est téléchargé en HTTPS. Le test est arrêté une fois les 250 Mio¹ 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². Afin de fiabiliser les résultats, chaque test a été refait plusieurs centaines de fois. Au total, plus de 58 000 tests³ ont été réalisés.

¹ 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.
² Une exception : la version d’Ubuntu utilisée est Ubuntu server 22.04 LTS.
³ Détails des tests réalisés (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.

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.

vivien · « **Réponse #7 le:** 30 juin 2022 à 08:48:16 »

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.

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.

vivien · « **Réponse #8 le:** 30 juin 2022 à 08:48:31 »

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.

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.

vivien · « **Réponse #9 le:** 30 juin 2022 à 08:48:44 »

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.

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)

vivien · « **Réponse #10 le:** 30 juin 2022 à 08:49:03 »

Partie "mesure de la qualité d'internet" lors de la présentation du rapport sur l'état de l'internet :

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/

Nkom, l’Autorité norvégienne des communications :

vivien · « **Réponse #11 le:** 30 juin 2022 à 08:49:17 »

La Bundesnetzagentur, l’Agence fédérale des réseaux en Allemagne :

Traficom : Agence finlandaise des transports et des communications :