Auteur Sujet: Protocole Arcep pour la mesure du débit mobile (Lu 2242 fois)

kgersen · « **le:** 08 mai 2022 à 22:29:19 »

Hors sujet extrait du sujet Nouveau serveur speedtest hébergé sur le réseau de MilkyWan

Citation de: ouno le 03 mai 2022 à 22:54:29

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

vivien · « **Réponse #1 le:** 09 mai 2022 à 07:08:08 »

Citation de: kgersen le 08 mai 2022 à 22:29:19

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

ouno · « **Réponse #2 le:** 15 mai 2022 à 13:57:21 »

(désolé pour le HS, je peux créer un autre sujet si besoin car on a pas mal dévié ?)

Citation de: kgersen le 08 mai 2022 à 22:29:19

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), Slow performance of IKEv2 built-in client VPN under Windows, Windows 11 TCP/IP Congestion Control Improvements...).

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.

Citation de: kgersen le 08 mai 2022 à 22:29:19

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.

kgersen · « **Réponse #3 le:** 15 mai 2022 à 20:49:10 »

Citation de: ouno le 15 mai 2022 à 13:57:21

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

Citation de: vivien le 09 mai 2022 à 07:08:08

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.

vivien · « **Réponse #4 le:** 17 mai 2022 à 08:43:00 »

Citation de: kgersen le 15 mai 2022 à 20:49:10

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.

kgersen · « **Réponse #5 le:** 17 mai 2022 à 10:26:00 »

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)

Citation de: vivien le 17 mai 2022 à 08:43:00

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.

Anonyme · « **Réponse #6 le:** 17 mai 2022 à 10:44:46 »

Citation de: kgersen le 17 mai 2022 à 10:26:00

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.

vivien · « **Réponse #7 le:** 17 mai 2022 à 10:52:33 »

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 :

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

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

Anonyme · « **Réponse #8 le:** 17 mai 2022 à 11:36:46 »

Citation de: vivien le 17 mai 2022 à 10:52:33

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.

ouno · « **Réponse #9 le:** 17 mai 2022 à 12:46:15 »

Citation de: kgersen le 15 mai 2022 à 20:49:10

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

vivien · « **Réponse #10 le:** 17 mai 2022 à 12:56:00 »

Citation de: Anonyme le 17 mai 2022 à 11:36:46

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

kgersen · « **Réponse #11 le:** 17 mai 2022 à 12:59:09 »

Citation de: ouno le 17 mai 2022 à 12:46:15

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.