Domaine principal
Technologie
Au sein de la facette Domaine principal, l'analyse Technologie regroupe les articles par domaine principal afin que les lecteurs puissent suivre un périmètre précis de l'infrastructure Internet, de la gouvernance, des marchés de connectivité ou du capital numérique. Cette page rassemble les articles associés, les preuves publiques, les institutions, les entreprises, les personnes, l'exposition régionale, les dépendances opérationnelles et le contexte de marché qui pourraient sinon être répartis entre différentes pages de catégories. Elle explique le domaine, la classe d'acteurs probable, le contexte de marché ou de gouvernance, ainsi que les sources que les lecteurs devraient utiliser pour comparer les signaux. Opérateurs, analystes et lecteurs de gouvernance peuvent voir comment un même domaine se manifeste à travers les événements, les profils, les évolutions de marché, les preuves issues de sources publiques, les dépendances régionales et les décisions d'infrastructure à plus long cycle au fil du temps.
Tendances mondiales des services cloud
Broadcom lance VMware AI Factory pour l’IA privée
VMware AI Factory automatise le déploiement et la gestion du cycle de vie des infrastructures d’IA privée, Broadcom visant à accélérer la mise à disposition du premier modèle.
Tendances mondiales des télécoms nationaux
Qualcomm dévoile le processeur IQ-2390 pour l’edge industriel
Qualcomm a dévoilé l’IQ-2390, qui réunit IA embarquée, vision industrielle, contrôle en temps réel et réseau TSN pour les systèmes edge industriels.
Créateurs
Albert Greenberg et le réseau comme ordinateur distribué
Chez AT&T, Microsoft Azure et Uber, Albert Greenberg a travaillé sur une même question: comment faire fonctionner un grand réseau comme un système cohérent lorsque la topologie, le trafic, le logiciel de contrôle, le matériel et les pannes évoluent à des rythmes différents. Son…
Créateurs
Albert Greenberg et le réseau comme ordinateur distribué
Chez AT&T, Microsoft Azure et Uber, Albert Greenberg a travaillé sur un même problème: faire d’un vaste réseau un système cohérent malgré l’évolution de la topologie, du trafic, des logiciels, du matériel et des pannes. Son influence se lit dans les boucles reliant mesure…
Tendances mondiales des FAI régionaux
Un deuxième service de peering distant n’est pas un deuxième chemin
Le peering distant rapproche logiquement un réseau d’un point d’échange. Il ne démontre pas que deux services empruntent deux chaînes physiques et opérationnelles indépendantes.
IETF
Eric Rescorla et le ClientHello chiffré qui ne pouvait pas nommer le serveur
Chiffrer le premier message TLS retire un indice très visible. Cela ne transforme pas la poignée de main restante en registre d’identité. La RFC 9849, rédigée collectivement par Eric Rescorla, Kazuho Oku, Nick Sullivan et Christopher A. Wood, dessine une enveloppe de…
IETF
Wesley George et la clé d’ASN ancienne qui ne pouvait pas annoncer une fusion
Le résumé de veille Wesley George et la clé d’ASN ancienne qui ne pouvait pas annoncer une fusion explique le développement, les preuves publiques disponibles, les organisations concernées, le contexte régional, l’exposition au marché et les conséquences possibles pour…
IETF
Martin Duke et la version QUIC qui ne pouvait pas déclarer son déploiement
QUIC v2 possède une RFC, une entrée IANA et une valeur de fil précise. Rien de cela n’installe v2 sur un endpoint. La RFC 9369 de Martin Duke rend cette différence volontairement visible: « version 2 » est un nom pratique pour le document, tandis que le protocole emploie sur le…
IETF
Joseph Touch et les options UDP qui laissent l’application décider
Un champ supplémentaire à la fin d’un paquet UDP peut étendre un protocole sans devenir une autorisation. La RFC 9868, cosignée par Joseph D. Touch, trace cette limite: les options de transport vivent après les données déclarées par l’utilisateur, tandis que l’application…
IETF
Loa Andersson et la décision MPLS qui s’arrêtait à la charte
Un groupe de travail peut décider de son prochain chantier sans choisir le protocole d’un réseau réel. La RFC 3468, cosignée par Loa Andersson et George Swallow, consigne le choix du groupe MPLS de concentrer son travail d’ingénierie de trafic sur RSVP-TE et de ne plus ouvrir de…
IETF
Deborah Brungard et le profil de transport qui ne choisissait pas un réseau
Une exigence de normalisation peut rendre une capacité disponible sans choisir le réseau qui l'emploiera. La RFC 5654, éditée notamment par Deborah Brungard, décrit les exigences d'un profil de transport MPLS. Elle trace surtout une limite: les exigences portent sur le…
Créateurs
Jakub Kicinski: comment Linux transforme les fonctions réseau en infrastructure durable
Une nouvelle carte réseau peut offrir une capacité remarquable sous forte pression commerciale. Linux doit toutefois poser une question plus lente: cette capacité peut-elle être comprise sur d’autres matériels, observée par les opérateurs, reproduite par les tests et maintenue…
IETF
Alia Atlas et la métrique TE qui ne promettait pas de chemin
Une métrique de performance peut éclairer une décision sans garantir son résultat. La RFC 7471, dont Alia Atlas est l’une des coauteures, permet de diffuser dans OSPF des informations de performance de lien destinées à l’ingénierie de trafic. Elle ne dicte ni la mesure de ces…
IETF
Jari Arkko et le champ du registre dont le protocole n’avait pas besoin
Un registre public donne facilement l’illusion que chaque colonne est indispensable parce qu’elle existe depuis longtemps. La RFC 8602 impose une discipline plus sobre: pour deux procédures d’enregistrement TRIP, l’adresse postale n’avait pas d’usage identifié. IANA a donc cessé…
IETF
Lars Eggert et le datagramme UDP qui n’échappait pas aux coûts partagés
UDP offre à une application un contrat de transport réduit. Il ne lui offre pas un réseau privé. Le travail de Lars Eggert sur la RFC 8085 fixe cette frontière: choisir le datagramme laisse la conception locale, mais pas le coût de la congestion sur un chemin partagé.
IETF
Nandita Dukkipati et la reprise TCP qui a cessé d’avancer par à-coups
En reprise après perte, le silence n’est pas forcément de la prudence. Un émetteur qui ne transmet plus pendant une partie du temps aller-retour, puis rattrape son retard par une rafale, peut finir sur la bonne fenêtre tout en imposant au réseau le mauvais trajet. Les travaux de…
IETF
Ashesh Mishra et la vérification BFD qui devait pouvoir revenir en arrière
Un paquet encore suspect demandait au récepteur de calculer une valeur située dans son avenir. Le simple fait de vérifier cette valeur pouvait pourtant effacer l'état nécessaire pour répondre « non ».
IETF
Wes Hardaker et le serveur DNS contraint de survivre à deux TTL
Une migration DNS ne s'achève pas quand le nouveau serveur répond. Elle s'achève quand plus aucun cache encore légitime ne peut conduire une requête vers l'ancien — et cette frontière dépend parfois d'une horloge que l'opérateur de la zone ne commande pas.
IETF
Mirja Kühlewind et le spin bit QUIC qui mesurait la cadence de l’application, pas le RTT du réseau
Un observateur voit une transition toutes les 200 millisecondes et inscrit « RTT: 200 ms ». Le calcul est exact, mais l’attribution ne l’est pas forcément: une application peu active peut émettre toutes les 200 ms sur un chemin dix fois plus rapide.
IETF
Murray Kucherawy et la signature DKIM qui laissait la fin hors signature
Un message peut porter un résultat DKIM valide et contenir, après la zone validée, plusieurs milliers d’octets que la signature n’a jamais vus. Le paradoxe disparaît dès que l’on lit `l=` non comme un détail de syntaxe, mais comme la frontière exacte de la preuve.