Mesures d’activité de l’Internet de ses performances pendant le #confinement : ▻https://labs.ripe.net/Members/becha/internet-measurements-in-the-time-of-corona
Mesures d’activité de l’Internet de ses performances pendant le #confinement : ▻https://labs.ripe.net/Members/becha/internet-measurements-in-the-time-of-corona
pour une explication complète voir ce billet de @stephane ►https://framablog.org/2020/03/21/linternet-pendant-le-confinement
Avec la multiplication des collectifs de capteurs, qui surgissent à propos de la radioactivité, de la pollution atmosphérique, de la pollution de l’eau, de la biodiversité et des pesticides ou encore des ondes électromagnétiques, on voit se former une autre branche des « sciences participatives ». La promotion de « sciences participatives » qui vont au-delà de l’organisation de bénévoles ou d’amateurs comme auxiliaires de recherche constitue un véritable casus belli pour les rationalistes indignés (…)
L’enjeu des métrologies alternatives est de faire voler en éclat la frontière du visible – ou du tangible – qui contraint les acteurs à des formes de délégation reposant elles-mêmes sur une économie de la confiance. Rendre visible une pollution invisible est un des problèmes les plus canoniques de la santé environnementale
#métrologie_participative #capteurs #science #pollution
De la métrologie en démocratie. La nouvelle vague des capteurs citoyens | Socio-informatique et argumentation
►http://socioargu.hypotheses.org/4505
(2013)
Les successeurs des RFC 2679 (délai d’acheminement en aller simple) et 2680 (taux de pertes en aller simple) sont sortis et ils sont désormais norme complète et plus seulement proposition de norme.
RFC 7679 : A One-Way Delay Metric for IPPM
▻http://www.bortzmeyer.org/7679.html
RFC 7680 : A One-Way Loss Metric for IPPM
▻http://www.bortzmeyer.org/7680.html
#RFC #métrologie #IPPM #ping #Internet
This probe is not on 24/7 as they shut down tv during the night.
Mon grand-père continue à faire de même, en France... un appareil électrique ne doit pas rester branché si on ne l’utilise pas que diable ! ! ! :-D
Avec, dans les liens, un map-a-thon pour la cartographie OpenStreetMap d’Oulan-Bator…▻http://seenthis.net/messages/401788
RFC 7536 : Large-Scale Broadband Measurement Use Cases
Mesurer les performances d’un réseau, c’est crucial. Cela permet de savoir si le réseau a bien les caractéristiques promises et cela permet de comparer les réseaux entre eux. D’où l’existence du groupe de travail #LMAP de l’IETF, dont voici le premier #RFC. Il décrit deux études de cas où la mesure est nécessaire : un opérateur qui veut s’assurer de la qualité du service qu’il fournit, et un régulateur des télécommunications qui veut vérifier que les opérateurs livrent bien ce qu’ils promettent, et ne discriminent pas certaines utilisations. Il y a bien sûr d’autres cas possibles (l’utilisateur final qui veut mesurer les performances de sa connexion...)
Excellent article technique sur comment les sondes #RIPE_Atlas se tiennent à l’heure (ne sautez pas en disant « il suffit d’utiliser #NTP », c’est plus compliqué que cela) et comment on peut désormais les utiliser pour mesurer les serveurs NTP (je crains qu’on ne découvre désormais des horreurs).
▻https://labs.ripe.net/Members/philip_homburg/ntp-measurements-with-ripe-atlas
RFC 7398 : A Reference Path and Measurement Points for Large-Scale Measurement of Broadband Performance
Ce nouveau #RFC est situé à l’intersection du groupe de travail IETF ippm et du plus récent groupe lmap. Ce dernier travaille pour les Large-Scale Measurements of Broadband Performance, c’est-à-dire pour les mesures objectives des performances des différents FAI, telles qu’elles sont menées par des associations de consommateur, ou l’État, ou un régulateur (comme ce que fait l’#ARCEP avec son Observatoire sur la qualité du service fixe d’accès à l’Internet). Ces mesures peuvent être faites à des fins de comparaison, mais aussi de diagnostic. La référence normalisée en matière de métrologie est évidemment composée des RFC du groupe ippm. Ces RFC définissent les métriques essentielles comme le temps d’acheminement d’un paquet (RFC 2679) ou comme la capacité (RFC 5136). Comme la valeur de ces métriques dépend du point où se fait la mesure, il fallait pouvoir exprimer cette information. C’est le but de ce RFC, exprimer rigoureusement où la mesure a été faite.
L’#ARCEP a publié aujourd’hui la première édition de « Qualité du service fixe d’accès à l’Internet - Mesures de la qualité du service fixe d’accès à l’Internet » Il s’agit de l’aboutissement d’un projet commencé il y a plusieurs années, visant (entre autres) à déterminer la qualité de l’accès à l’Internet selon le FAI. La méthodologie choisie consiste en des mesures actives effectuées depuis huit points de mesure dotés d’un matériel spécialisé.
▻http://www.arcep.fr/uploads/tx_gspublication/rapport-QoS-internet-nov2014.pdf
Voir aussi la critique par Korben...
▻http://korben.info/ivre-larcep-tente-de-mesurer-la-qualite-de-service-de-votre-internet.html
@severo Critique qui se plante dès le début en décrétant que des sondes installées on ne sait pas trop (derrière le Wifi ?) où chez des particuliers volontaires seraient plus représentatives...
« Le RIPE, organisme en charge de la gestion des adresses IP, pour l’Europe, distribue gratuitement des sondes [les RIPE Atlas] qui permettent de mesurer finement la qualité de service d’Internet. Avec de vrais bonus pour vous si vous avez une de ces sondes. »
▻http://www.zdnet.fr/actualites/et-si-vous-installiez-une-sonde-ripe-atlas-pour-contribuer-a-mesurer-la-qualit
#qos
Troisième bonus, plus hypothétique : certains esprits malintentionnés m’ont laissé entendre que les #FAI, qui ont la possibilité de détecter la présence d’une sonde Atlas chez un de leurs clients, mettent alors en œuvre une procédure permettant d’apporter à ce client une bande passante maximale avec la meilleur stabilité de
connexion possible. D’aucuns auraient mesuré un accroissement de 20 voire 30% de leur débit descendant ! Je suis un peu sceptique [...]
Quelques changements dans le protocole/format #IPFIX, qui permet à un équipement de réseau, genre un #routeur, de transmettre des statistiques agrégées à son maître. Les nouveaux RFC :
RFC 7011 sur le protocole ▻http://www.bortzmeyer.org/7011.html
RFC 7012 sur le modèle de données ▻http://www.bortzmeyer.org/7012.html C’est celui qui a le plus changé, le modèle n’est plus dans le RFC mais dans un registre IANA ▻http://www.iana.org/assignments/ipfix/ipfix.xml#ipfix-information-elements
RFC 7013 sur l’enregistrement de nouveaux types dans le modèle
RFC 7014 sur les techniques de sélection d’un flot (utile pour la
NSA ?)
RFC 7015 sur l’agrégation de flots
« Where in the Internet is congestion ? », se demandent Daniel Genin et Jolene Splett, les auteurs de cette étude. Tout le monde s’est dit au moins une fois « ça rame » mais n’a pas pu répondre à la question « ça rame où ? Dans mon accès Internet ? Chez mon FAI ? Plus loin ? » Pour répondre, les auteurs ont utilisé les données récoltées par les sondes #SamKnows placées par la #FCC dans des milliers de foyers états-uniens. Ces sondes passent leur temps à télécharger de gros fichiers et à regarder combien de temps ça prend. L’idée de base des auteurs est de regarder les corrélations entre les épisodes de ralentissement : si tout le monde dans le Missouri rame en même temps, c’est probablement un problème dans le réseau de l’État, et pas chez M. Smith.
Parmi les conclusions, le fait que la congestion apparait aussi bien au bord qu’au cœur de l’Internet.
(Les deux tableaux les plus importants de l’article sont les tableaux I et II mais ils ne sont pas faciles à lire à cause d’une légende erronnée. Je pense qu’il faut lire RC au lieu de FC et TIS au lieu de PTIS.)
RFC 6985 : IMIX Genome : Specification of variable packet sizes for additional testing
Traditionnellement, les mesures des caractéristiques d’un réseau en labo (RFC 2544) se faisaient avec des paquets de taille constante, afin de bien contrôler les conditions de la mesure, de savoir exactement ce qui était mesuré et donc de pouvoir reproduire la mesure à volonté. C’est par exemple ce que fait la commande ping avec son option -s. Mais les réseaux réels sont bien différents : ils font passer des paquets de taille très diverses. Il est donc fréquent aujourd’hui de tester avec un mélange de paquets de différentes tailles, ce qu’on nomme un #IMIX (Internet MIXture). De nos jours, les équipements de test ont souvent la possibilité d’utiliser des IMIX. Mais les tests doivent être reproductibles, il faut donc un moyen de caractériser un IMIX, d’indiquer sa composition (autrement que par un vague « on a utilisé un IMIX »). C’est le but du mini-langage présenté dans ce #RFC.
« Measuring Home Networks with HomeNet Profiler » de Lucas DiCioccio, Renata Teixeira, et Catherine Rosenberg
Très amusant article décrivant ce qu’on trouve comme équipements connectés à l’Internet dans une maison typique d’un pays riche. Les auteurs ont développé un logiciel que les volontaires installent chez eux (donc, comme beaucoup d’étude de ce genre, par exemple ▻http://seenthis.net/messages/151806 , il y a un biais d’auto-sélection) et le programme balaye le réseau local à la recherche de machines qui répondent.
En France, il y a entre 2 et 29 machines dont beaucoup ne sont pas connectées en permanence (la plupart des maisons n’ont jamais plus de 4 machines joignables en même temps).
L’article : ▻http://www.thlab.net/~dicioccio/publications/pam13/pam2013dicioccio.pdf Attention en le lisant, il y a deux jeux de maisons testées, un jeu de six maisons étudiées en détail (« the testbed ») et un autre jeu bien plus grand. L’article ne dit pas toujours clairement, pour chaque mesure, de quel jeu il s’agissait.
Le programme : ▻http://cmon.lip6.fr/hnp/pages/home
Un autre biais est que tout le monde n’a pas réussi à faire tourner le programme et que l’échantillon est donc biaisé en faveur de ceux qui maitrisent mieux l’informatique. Lisez bien les instructions. Dans mon cas, le rapport dit « Nous avons trouvé 7 interfaces réseau différentes (certains appareils peuvent en avoir plus d’une) connecté à votre réseau domestique » (et ensuite, il affiche une liste de 8 addresses MAC).
Lorsqu’il s’agit de performances des réseaux informatiques, le vocabulaire utilisé, que ce soit sur les forums, sur les réseaux sociaux ou même dans les livres est en général catastrophique, flou et mélangeant tout. D’où deux articles à moi pour préciser rigoureusement ce que sont la #latence et la #capacité :
▻http://www.bortzmeyer.org/latence.html
▻http://www.bortzmeyer.org/capacite.html
Les Francs-Comtois ne sont pas heureux, les Nordistes si.
▻http://www.macommune.info/article/les-francs-comtois-ne-nageraient-pas-dans-le-bonheur-81808
#societe #bonheur #metrologie
A la suite de l’homologation par le ministre chargé des communications électroniques de la décision de l’#ARCEP du 29 janvier 2013, l’Autorité met en place un dispositif de mesure et de suivi de la qualité du service fixe d’accès à l’internet. Les objectifs sont d’améliorer l’information des internautes et de donner à l’Autorité les moyens d’assurer sa mission de supervision du niveau général de qualité des services fixes de téléphonie et d’accès à l’internet. Ce dispositif s’insère également dans le cadre des travaux et des réflexions conduits par l’ARCEP depuis 2010 sur les aspects techniques et économiques de la neutralité d’internet.
Le communiqué de l’ARCEP :
▻http://www.arcep.fr/index.php?id=8571&tx_gsactualite_pi1[uid]=1597&tx_gsactualite_pi1[annee]=&tx_g
L’homologation au JO :
▻http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000027205928
Le résumé de Numerama :▻http://www.numerama.com/magazine/25492-l-arcep-prepare-le-test-de-qualite-des-acces-a-internet.html et celui de PC Inpact : ▻http://www.pcinpact.com/news/78545-neutralite-net-mesures-arcep-pour-suivre-qualite-reseaux.htm?vc=1#to
Voir aussi ►http://owni.fr/2012/01/12/les-telecoms-sans-autorite ►http://owni.fr/2012/06/04/internet-bat-la-mesure ►http://owni.fr/2012/01/19/mesure-internet-inria-metroscope-qos
« 10Gbps Open Source Routing » de Bengt Gördén, Olof Hagsand et Robert Olsson. Excellent article sur les performances d’un PC/Linux comme routeur sur de l’Ethernet 10 Gb/s. Les auteurs ont mesuré le débit qu’ils arrivaient à faire passer par un PC du commerce. Conclusion : c’est faisable, mais pas avec toutes les cartes et tous les pilotes, il faut passer du temps à faire des réglages et, le coût par paquet étant important, ce débit n’est atteint que pour les paquets de plus de 256 octets.
Deux avantages à de tels routeurs : 100 % logiciel libre (contrairement aux Cisco et Juniper) et le prix (un routeur Cisco ou Juniper dans ces gammes de performance se compte en dizaines de milliers d’euros.
Les volumes de données impressionnent, mais le facteur limitant est rarement le débit en termes de volume de données... Ne serait-il pas plus pertinent de se focaliser sur les performances en termes de paquets par seconde ?
@liotier C’est justement détaillé dans l’article.Plus de 10 Mp/s.
À noter qu’il y a eu des progrès depuis cet article, par exemple ▻http://fr.slideshare.net/brouer/linuxcon2009-10gbits-bidirectional-routing-on-standard-hardware-runni ou ▻http://ripe61.ripe.net/presentations/138-Deri_RIPE_61.pdf et, tout récemment ▻http://blog.scottlowe.org/2012/09/12/clds006-exploring-new-xeon-e5-optimizations-for-10-gb-ethernet et ▻http://info.iet.unipi.it/~luigi/papers/20120503-netmap-atc12.pdf
RFC 6808 : Test Plan and Results Supporting Advancement of RFC 2679 on the Standards Track
Voici le premier #RFC à mettre en application la démarche du RFC 6576, qui définissait la méthode pour faire avancer un RFC décrivant des métriques sur le chemin des normes. Si l’IETF avait une grande expérience dans la mesure du déploiement et de la qualité d’un protocole, c’était moins évident pour les métriques, ces grandeurs définies rigoureusement et qu’on cherche à mesurer. Le RFC 6576 ayant déblayé ce terrain, ceci est sa première application : l’étude de l’avancement de la métrique « délai d’acheminement d’un paquet », qui avait été normalisée dans le RFC 2679.
RFC 6815 : RFC 2544 Applicability Statement : Use on Production Networks Considered Harmful
Lors de la publication du RFC 2544, sur les tests de performances des équipements réseau, un point n’avait pas été mis assez clairement : comme tous les #RFC du groupe #BMWG, le RFC 2544 ne concerne que les tests en laboratoire, dans des conditions bien contrôlées, et sans avoir peur de gêner un réseau de production. Comme certains avaient apparemment raté cette limitation, notre RFC 6815 enfonce le clou : ne faites pas les tests du RFC 2544 sur un vrai réseau !
Le groupe de travail #IPPM de l’#IETF a défini de nombreuses métriques, des définitions rigoureuses de grandeurs qu’on peut mesurer sur un réseau. Ce nouveau #RFC porte sur un problème un peu différent : une fois qu’on a ces métriques, comment publier les résultats ? Quels sont les pièges de la publication ? Parmi les paramètres de la mesure, que mettre en évidence ? Ce RFC est loin de traiter en détail toutes ces questions, il décrit surtout les conséquences de deux points de vue différents : celui de l’ingénieur réseaux, intéressé surtout par les performances de son réseau, et celui du programmeur, intéressé par les performances de son application.
RFC 6673 : Round-trip Packet Loss Metrics
Tiens, le groupe de travail #ippm n’avait pas encore normalisé toutes les métriques possibles ? Il restait encore des indicateurs de performance et de qualité de service qui n’avaient pas de #RFC. En voici une nouvelle, le taux de pertes de paquets sur un trajet aller-retour.
Un groupe de travail de l’#ARCEP a pour activité la définition de mesures de la qualité d’accès à l’Internet. Sur quelle base dire que le FAI X est meilleur que Y ? En mesurant, bien sûr, mais en mesurant quoi ?
RFC 6534 : Loss Episode Metrics for IPPM
Le RFC 2680 définissait une #métrique (une grandeur mesurable et spécifiée rigoureusement) pour le taux de pertes de paquets entre deux points du réseau. Mais un certain nombre de logiciels ne sont pas sensibles uniquement à la moyenne du taux de pertes mais aussi à sa répartition. Sur un flot de cent paquets, ce n’est pas la même chose d’en perdre trois, répartis au hasard, et d’en perdre trois de suite, par exemple pour certains protocoles multimédia qui encodent les différences entre paquets. Ce nouveau #RFC définit donc des métriques pour caractériser les épisodes, ces pertes consécutives de paquets.
RFC 6555 : Happy Eyeballs : Success with Dual-Stack Hosts
Une question récurrente qu’#IPv6 pose aux développeurs d’application et aux administrateurs système qui déploieront ces applications ensuite est celle d’une machine accessible à la fois en IPv4 et IPv6. Si le pair cherchant à joindre cette machine croit avoir IPv6 mais que sa connectivité ne marche pas, ou mal, l’application arrivera-t-elle à se rabattre en IPv4 très vite ou bien imposera-t-elle à l’utilisateur un long délai avant de détecter enfin le problème ? Cette question est connue comme « le bonheur des globes oculaires » (les dits globes étant les yeux de l’utilisateur qui attend avec impatience la page d’accueil de YouPorn) et ce #RFC spécifie les exigences pour l’algorithme de connexion du client, afin de rendre les globes oculaires le plus heureux possible.
►http://www.bortzmeyer.org/6555.html
RFC 6556 : Testing Eyeball Happiness
L’incertitude à ce sujet est la principale cause du très faible nombre de sites Web qui ont un enregistrement AAAA (adresse IPv6) dans le DNS aujourd’hui.
Ce RFC ne propose pas de solution : issu de travaux mené notamment au sein du groupe de travail benchmarks de l’IETF, il propose simplement de mesurer ce bonheur des globes oculaires, de manière à ce qu’on puisse comparer les solutions. On pourra alors retenir les meilleures, de manière à faire sauter ce qui est aujourd’hui un sérieux obstacle au déploiement d’IPv6.
Et une nouvelle version, cette fois non spécifique à IPv6 mais gérant tous les cas multi-adresses ▻http://www.bortzmeyer.org/8305.html
L’#ARCEP lance deux consultations publiques en vue d’améliorer l’information à destination des utilisateurs et du régulateur.
Dans le cadre de ses travaux de mise en oeuvre de ses 10 propositions et recommandations sur la neutralité de l’internet et des réseaux publiées en septembre 2010, l’Autorité lance aujourd’hui deux consultations publiques.
La première consultation présente les orientations envisagées par l’Autorité pour la mise en place d’un suivi de la qualité du service d’accès à l’internet sur les réseaux fixes. Il s’agira, à l’issue de travaux à conduire en 2012, de mesurer la qualité du service offert par les différents fournisseurs d’accès à l’internet (FAI) à leurs abonnés et de diffuser des informations claires et comparables, utiles tant aux utilisateurs qu’au régulateur.
La seconde consultation prépare la mise en place d’une collecte régulière d’informations sur les conditions techniques et tarifaires d’interconnexion et d’acheminement de données. Cette collecte permettra à l’Autorité d’améliorer sa connaissance et sa compréhension des marchés de l’interconnexion et de l’acheminement de données.
Ces consultations sont disponibles en téléchargement sur le site de l’Autorité. Les parties intéressées peuvent y répondre jusqu’au 17 février 2012.
http://www.arcep.fr/index.php?id=8571&tx_gsactualite_pi1[uid]=1469&tx_gsactualite_pi1[backID]=1&cH
#neutralité #FAI #Internet #Grenouille #métrologie #peering #CDN
Grosse #SeenThis_Bug, l’URL est tronqué en deux parties et donc ne fonctionne plus.
T’as vu la tronche de l’URL, aussi ? :-))
(J’ai corrigé mon regexp. Maintenant c’est OK.)
Avis personnel, après avoir tout lu : techniquement, c’est un très bon document, très bien fait, avec peu ou pas d’erreurs techniques. Cela vaut donc la peine de le lire, et de répondre à la consultation.