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

0 Membres et 1 Invité sur ce sujet

ouno

  • Abonné Orange Fibre
  • *
  • Messages: 144
  • Rennes (35)
Protocole Arcep pour la mesure du débit mobile
« Réponse #12 le: 17 mai 2022 à 13:29:57 »
oui mais on parle de débit "max" dans ces mesures et pas des mesures de confort/latence.
Si j'ai bien tout suivi on compare les débits moyens sur la durée du test de téléchargement.

Si tu prend un ratio 100 cubic vs 1 bbr tu n'est pas représentatif du tout. c'est 1 Mbps x100 vs 100 Mbps x 1 ou sur 1 heure, 50% pour BBR  et 50% pour cubic.
Je n'ai pas compris ce que tu voulais dire ici ? Pour moi l'important c'est le nombre d'utilisateurs concernés, pas le volume de données.

Donc oui prendre le volume c'est représentatif parce que le provider qui doit fournir du 100Mbps moyen a un client va forcement utiliser la tech la plus adaptée donc du BBR.
Si on cherche le "max" on mesure avec BBR (et rapidement qu'avec QUIC et plus tcp) et ca ne sert a rien de regarder autre chose. Ca complexifie l'étude et crée des polémiques inutiles de faire les cubic et bbr.
Je ne suis pas du tout ta logique...

edit: en fait si, je pense que j'ai compris, surtout depuis que les posts ont été déplacés dans la section QoS mobile et qu'un sujet a été ajouté posant le cadre du test de débit pour mobiles (personnellement je parlais plutôt des usages en ligne fixe...)
Tu pars du principe que cela ne sert à rien de s'encombrer de CUBIC dans les tests de débit, car de toutes façons le trafic en CUBIC n'est pas du trafic qui a besoin de vitesse élevée sinon l'administrateur du serveur aurait déjà migré en BBR.
Peut-être que c'est le cas pour tous les services typiques d'un usage mobile, je suis relativement mal placé pour en parler...
« Modifié: 17 mai 2022 à 15:27:11 par ouno »

  • Invité
Protocole Arcep pour la mesure du débit mobile
« Réponse #13 le: 17 mai 2022 à 13:41:04 »
Le protocole évolue lestement chaque année pour être le plus représentatif possible.

Par exemple le transfert se limite à une durée (qui est toujours 10 secondes) et une taille qui augmente régulièrement. J'ai souvenir il y a 10 ans d'un fichier de 5 Mio qui a été augmenté à 20 Mio, puis 50 Mio et depuis deux ans en métropole, c'est un fichier de 250 Mio. Cette année on devrait avoir un protocole identique entre DROM et métropole.

J'ai essayé de pousser de ne faire qu'une durée (taille infinie) en proposant un transfert de 8 secondes sans limite de taille afin de ne plus avoir à faire augmenter la taille du fichier, mais ce n'est pas passé.
Quand tu prends des métriques différentes pour mesurer des facteurs différents dans une analyse multifactorielles ( Mesure d'audience, Mesure de volume échangé ou tout autre ) il te faut un facteur commun de métrique, pour tout ramener à la même unité de mesure, pour pouvoir pondérer les différents facteurs.
Là tu as pris un volume d'échange, pourquoi pas, cela aurait pu être le temps, le facteur commun des poids de pondération des différents facteurs.
Ce que tu ne peux pas faire, si tu veux pouvoir comparer ce qui est comparable dans le temps, c'est de dire, je vais comparer dans le temps N-1, N deux choses qui ont un facteur ayant été modifié, ce n'est pas consistant. Ou alors ce sont deux études décorrélées et incomparables.Et là tu t'exposes aux désaccords de méthodologie.
Si tu dis, on ne peux pas comparer les études de l'année dernière et de cette année, soit. Si tu dis on a changé la méthodologie de mesure pour l'améliorer, tu dois prévenir que on ne peux pas comparer les études précédentes avec celle-ci.

vivien

  • Administrateur
  • *
  • Messages: 48 042
    • Twitter LaFibre.info
Protocole Arcep pour la mesure du débit mobile
« Réponse #14 le: 17 mai 2022 à 14:19:46 »
Les changements suivent Internet.

Pour donner un autre exemple pendant longtemps les tests étaient 100% en http. Il y a ensuite eu 50% http et 50 https. Depuis 2/3 ans, c'est 100% des tests en https.

Autre changement : l'arrivée de l'IPv6 l'année dernière avec 50% des tests réalisés vers un serveur IPv4+IPv6 et 50% vers un serveur IPv4 only.

Pour le surf, c'est un ensemble de 10 pages extrait du top30 Alexa des sites les plus consultés en France qui est testé. Là aussi les pages évoluent d'une année sur l'autre.

Bref internet évolue et la méthode de test doit donc évoluer.

kgersen

  • Modérateur
  • Abonné Orange Fibre
  • *
  • Messages: 9 230
  • Paris (75)
Protocole Arcep pour la mesure du débit mobile
« Réponse #15 le: 17 mai 2022 à 16:43:37 »
Tu pars du principe que cela ne sert à rien de s'encombrer de CUBIC dans les tests de débit, car de toutes façons le trafic en CUBIC n'est pas du trafic qui a besoin de vitesse élevée sinon l'administrateur du serveur aurait déjà migré en BBR.

oui c'est exactement ca


  • Invité
Protocole Arcep pour la mesure du débit mobile
« Réponse #16 le: 17 mai 2022 à 18:14:35 »
Les changements suivent Internet.

Pour donner un autre exemple pendant longtemps les tests étaient 100% en http. Il y a ensuite eu 50% http et 50 https. Depuis 2/3 ans, c'est 100% des tests en https.

Autre changement : l'arrivée de l'IPv6 l'année dernière avec 50% des tests réalisés vers un serveur IPv4+IPv6 et 50% vers un serveur IPv4 only.

Pour le surf, c'est un ensemble de 10 pages extrait du top30 Alexa des sites les plus consultés en France qui est testé. Là aussi les pages évoluent d'une année sur l'autre.

Bref internet évolue et la méthode de test doit donc évoluer.
Pose la question à l'INSEE si la méthodologie est avalisée (enfin quand je dis toi, l'ARCEP).
Je n'y vois pas de problème intellectuel structurel sur la métrologie, mais évites toi des polémiques médiatiques inutiles ensuite.
Si la méthodologie de mesure est validée par l'INSEE cela rentre dans les outils de mesure de l'état, et les opérateurs n'ont plus à contester, ni la méthodologie,les métriques et outils.

vivien

  • Administrateur
  • *
  • Messages: 48 042
    • Twitter LaFibre.info
Protocole Arcep pour la mesure du débit mobile
« Réponse #17 le: 17 mai 2022 à 19:42:57 »
L'opérateur qui a contesté au moment où il a eu accès aux résultats n'avait rien trouvé à redire au protocole avant que les tests soient lancés.

  • Invité
Protocole Arcep pour la mesure du débit mobile
« Réponse #18 le: 17 mai 2022 à 20:50:34 »
Oui, comme tu dis, les choses évoluent.
Il y a plusieurs façons de t'aider, ou te tirer d'un mauvais pas, ou t'éviter de le faire.

kgersen

  • Modérateur
  • Abonné Orange Fibre
  • *
  • Messages: 9 230
  • Paris (75)
Protocole Arcep pour la mesure du débit mobile
« Réponse #19 le: 17 mai 2022 à 22:41:11 »
perso je pense qu'il faudrait:

- un test de débit max avec BBR et HTTP/2 taille illimitée max 8 secondes. (remplacé puis plus tard par un test en HTTP/3) (tester du HTTP/1.1 et/ou du non chiffré n'a pas d'intérêt de nos jours). en ipv4 et ipv6.
- un test de perte de paquets au heure de pointes (via des streams UDP a des débits représentatifs sans pousser au max) ... C'est qui fait que CUBIC pèche chez Free par exemple. En publiant ce genre de chose ca évite la polémique car ca met en évidence clairement les engorgements de collecte ou peerings/transits d'un FAI sans brouiller le message avec un débat sur les algos de congestion de TCP ou de mesures de débit ;)

vivien

  • Administrateur
  • *
  • Messages: 48 042
    • Twitter LaFibre.info
Protocole Arcep pour la mesure du débit mobile
« Réponse #20 le: 17 mai 2022 à 22:50:28 »
Il y aura peut-être un test débit max (multi-connexion, 100% BBR) qui se rapprochera d'un nPerf, c'est en expérimental.

Le débit principal a lui toujours la volonté d'être le plus représentatif possible (dans la limite du raisonnable financièrement, on ne va pas mettre 5 serveurs).

Le problème d'un indicateur sur les pertes de paquets, c'est que c'est vraiment un indicateur technique, pas de qualité d'expérience.

kgersen

  • Modérateur
  • Abonné Orange Fibre
  • *
  • Messages: 9 230
  • Paris (75)
Protocole Arcep pour la mesure du débit mobile
« Réponse #21 le: 17 mai 2022 à 23:03:25 »
Le problème d'un indicateur sur les pertes de paquets, c'est que c'est vraiment un indicateur technique, pas de qualité d'expérience.

L'idée était par exemple de balancer de l'UDP  a 1 ou 2 Mbps aux heures de pointes. Avec des pertes de paquets ca va être difficile de faire de la visio de bonne qualité (Duo/Chat, Zoom, Facetime, Teams, etc)... c'est assez simple à faire comme test.


  • Invité
Protocole Arcep pour la mesure du débit mobile
« Réponse #22 le: 18 mai 2022 à 00:32:02 »
Le problème d'un indicateur sur les pertes de paquets, c'est que c'est vraiment un indicateur technique, pas de qualité d'expérience.
Ce n'est pas un problème à proprement parler, ce sont deux mesures différentes.
La Qualité d'expérience, repose sur un ressentis sensoriel, vue, ouïe etc. c'est un type d'analyse différent, des études plus souvent faites par les départements marketing Quali/Quanti.
Il y a une corrélation sous-jacente avec la qualité technique, mais elle est invisible pour le consommateur. Pour le consommateur, plus il y a de débit mieux c'est, c'est un raccourcit de relation causale faux.
Là on parle de ce qui est ton périmètre à toi et de tes campagnes de mesure, de tes choix de tests et présentations. Si un des opérateurs utilise ces indicateurs pour ses besoins marketing en les mettant en avant, d'autres y trouveront à redire, sur n'importe quel angle de mise en cause.
Pour ce qui te concerne, il faut juste que ce soit impartial.

La métrique de kgersen, en est une, elle repose sur une analyse temporelle, elle à l'avantage de se décorréler de la technologie sous-jacence.
Tu récupères un volume en temps donné, et ce qui est derrière est du ressort de l'opérateur. Si tu entres dans les détails du bit 8 de l'octet 4 du protocole 1.2, tu vas avoir du mal à synthétiser.

vivien

  • Administrateur
  • *
  • Messages: 48 042
    • Twitter LaFibre.info
Protocole Arcep pour la mesure du débit mobile
« Réponse #23 le: 18 mai 2022 à 08:23:21 »
Ne pas oublier que 3 opérateurs mobile sur 4 ont une plateforme d'optimisation (on en parle dans le sujet IPv6 fallback to IPv4) qui concerne tous les flux TCP port 80 et TCP port 443).

Il faut faire attention à la représentativité quand on lance un test qui ne passe pas par cette plateforme (et c'est aussi pour cela que faire une partie des tests en HTTP/3, quand il sera plus mur, est intéressante : HTTP/3 ne peut pas être accéléré par la plateforme d'optimisation).

Le protocole 2022 est figé et les tests préliminaires à la campagne lancés, mais je pourrais essayer de vous inviter pour discuter lors de la co-construction du protocole 2023, des idées sont probablement bonnes à prendre.