Résumé

  • L'Ultra Ethernet Consortium est un projet de la Joint Development Foundation, lancé le 19 juillet 2023 par AMD, Arista Networks, Broadcom, Cisco, Eviden/Atos, Hewlett Packard Enterprise, Intel, Meta et Microsoft. Il s'agit d'un consortium industriel de développement de spécifications, et non d'une entreprise ordinaire ni d'un opérateur de réseau.
  • La portée de l'UEC dépasse largement une liaison Ethernet plus rapide ou un simple remplacement de RoCE. La spécification 1.0.3, longue de 573 pages, couvre les couches logicielle, transport, réseau, liaison et physique, auxquelles s'ajoutent les travaux sur la gestion, le stockage, les tests et la conformité.
  • Ultra Ethernet Transport combine plusieurs modes de livraison, le trajets multiples par paquet, la retransmission sélective, le contrôle de congestion piloté par l'émetteur et le récepteur, ECN, le Packet Trimming optionnel, la répétition optionnelle de liaison locale (Link Layer Retry), le contrôle de flux optionnel à base de crédits et la sécurité de transport optionnelle de bout en bout.
  • Les produits et démonstrations d'AMD, Broadcom, Nokia et Keysight montrent que la mise en œuvre a commencé. Cependant, la conformité publique repose principalement sur des autodéclarations des implémenteurs; aucun registre de certification indépendant complet ou recensement de déploiements à grande échelle n'a été publié.
  • L'opportunité stratégique de l'UEC réside dans la base Ethernet installée et la chaîne d'approvisionnement multi-fournisseurs. Les principaux risques sont la complexité des points terminaux, la fragmentation due aux fonctions optionnelles, les obligations de brevets RAND, la maturité insuffisante de la gestion et des tests, ainsi que l'écart entre une spécification publiée et l'interopérabilité démontrée en production.

Pourquoi l'IA a fait du réseau une partie de l'ordinateur

L'Ultra Ethernet Consortium est né d'une transformation de l'économie informatique. Dans un réseau d'entreprise classique, la structure (fabric) doit transporter de nombreux flux de données indépendants avec un débit et une disponibilité acceptables. En revanche, dans un grand système d'entraînement d'IA ou une machine de calcul haute performance, le réseau devient partie intégrante d'un calcul unique synchronisé. Des milliers d'accélérateurs peuvent échanger des paramètres de modèle, des gradients ou des données scientifiques lors d'opérations collectives.

Une phase ne progresse souvent que lorsque le entité le plus lent a reçu les informations requises. Ainsi, même un petit déséquilibre entre les chemins, un événement de congestion ou une perte de paquet peut mettre en attente des processeurs coûteux, même si l'utilisation moyenne de la structure (fabric) semble saine.

Cela modifie les objectifs d'optimisation des opérateurs. La bande passante agrégée reste importante, mais ne suffit plus. Le temps d'achèvement des tâches, la latence de queue, l'incast, la correction des pertes, la distribution du trafic sur des chemins parallèles et la quantité d'état que les points terminaux doivent conserver sont tout aussi pertinents. Un réseau qui délivre presque tous les paquets rapidement, mais en retarde une petite fraction, peut bloquer une opération collective entière.

Une procédure de retransmission acceptable pour le trafic conventionnel peut engendrer des pertes de temps excessives lorsqu'un seul paquet manque dans un long message. Un flux lié à un seul chemin équivalent peut offrir des performances médiocres, alors qu'ailleurs dans la topologie de la capacité reste inutilisée.

La thèse fondatrice du UEC postulait que ces problèmes ne peuvent être résolus par une seule nouvelle fonction de commutateur ou un seul algorithme de congestion remanié. Le chemin de communication commence au-dessus du réseau, dans les bibliothèques logicielles et la sémantique applicative. Il traverse l'enregistrement mémoire, les opérations distantes, l'état de transport, la livraison de paquets, le contrôle de congestion, le routage IP, les liaisons Ethernet, l'optique et la signalisation physique.

Si ces couches sont conçues indépendamment, une optimisation à un endroit risque de ne faire que déplacer le goulot d'étranglement ou de créer des hypothèses incompatibles ailleurs.

La réponse de l'UEC est une architecture coordonnée. Elle conserve Ethernet et IP, car les opérateurs maîtrisent ces technologies et parce qu'une vaste chaîne d'approvisionnement s'est constituée autour des commutateurs, de l'optique, des câbles, des systèmes d'exploitation réseau, de la télémétrie et de la gestion. En même temps, elle modifie ou étend les domaines que le consortium juge insuffisants pour les charges de travail massives d'IA et de HPC. Le résultat n'est pas « de l'Ethernet ordinaire avec un nouveau logo ».

C'est la tentative de faire supporter à un réseau familier un transport spécialisé dont le comportement est défini depuis l'API logicielle jusqu'au débit par voie.

Cette distinction explique l'importance de l'UEC pour l'infrastructure numérique. Le projet ne possède ni accélérateurs, ni usines, ni centres de données, ni régions cloud. Il définit des contrats que les entreprises membres et d'autres implémenteurs peuvent intégrer dans des cartes réseau (NIC), des ASIC de commutation, des systèmes, des pilotes, des bibliothèques et des équipements de test. L'influence ne se matérialise que lorsque ces produits indépendants échangent correctement des données face aux erreurs, à la congestion, aux mises à niveau et aux combinaisons multi-fournisseurs.

Ce qu'est l'UEC — et ce qu'il n'est pas

Ultra Ethernet Consortium est le nom public d'un projet formel, dont la série juridique est Joint Development Foundation Projects, LLC, Consortium for HPC/AI/ML Ethernet Series. La structure en série rattache le projet à la Joint Development Foundation et à l'écosystème Linux Foundation. Elle fournit un cadre juridique existant pour l'adhésion, la gouvernance, la propriété intellectuelle, le financement et les relations extérieures, sans que les entités aient besoin de créer une nouvelle entité indépendante.

Cette structure est importante car l'UEC est souvent qualifié à tort d'entreprise, d'alliance ou d'organisme de normalisation. Il ne s'agit pas d'une société commerciale avec actionnaires, capitaux propres, valorisation ou états financiers déposés séparément. Il ne vend pas de produits Ethernet, n'exploite pas de réseau public et ne possède pas le matériel que ses membres promeuvent. C'est un consortium de développement de spécifications doté d'un cadre juridique et de propriété intellectuelle. Ses documents publics sont destinés à devenir des contrats de mise en œuvre entre plusieurs entreprises.

L'UEC ne se résume pas non plus à l'Ultra Ethernet Transport. UET est l'architecture de transport au cœur de la spécification, mais les travaux du consortium vont au-delà. Ils englobent le mappage logiciel sur libfabric, la sémantique des paquets et des messages, les hypothèses réseau, les options de couche liaison, les exigences de couche physique, la gestion, l'alignement sur le stockage, la performance et le débogage, la conformité et les tests. Le réduire à « un nouveau protocole RDMA » occulte la conception transversale qui rend le projet à la fois ambitieux et difficile.

L'UEC n'est pas non plus le groupe de travail IEEE 802.3. IEEE 802.3 élabore les standards Ethernet MAC et PHY fondamentaux selon un processus distinct. L'UEC s'appuie sur cet écosystème et entretient une liaison avec lui, mais ne le remplace pas. La même limite s'applique aux mécanismes IETF sous-jacents à UET, notamment IPv4, IPv6 et Explicit Congestion Notification; à l'écosystème OpenFabrics qui maintient libfabric; et aux organisations qui travaillent sur le stockage, le matériel ouvert et les interconnexions d'accélérateurs.

Le site web du projet a parfois utilisé un vocabulaire suggérant le statut d'organisme de normalisation international. La description la plus rigoureuse et la mieux étayée est la suivante: l'UEC est une organisation internationale de développement de spécifications dans le cadre JDF. Rien ne prouve que l'UEC fasse partie de l'Organisation internationale de normalisation (ISO), que ses documents soient des normes ISO ou qu'il possède un numéro de norme ISO. La différence n'est pas seulement linguistique.

Elle indique d'où provient l'autorité, comment la participation fonctionne et à quelles obligations juridiques les implémenteurs peuvent être exposés.

Il convient donc de juger l'UEC sur son fonctionnement réel. Il coordonne des concurrents et des opérateurs autour d'une conception technique commune, publie des spécifications, gère des groupes de travail et des obligations déclarées de brevets, élabore des documents de conformité et des relations avec les organisations voisines. Par sa simple existence, il ne peut ni rendre un produit interopérable ni pousser le marché à adopter son architecture.

La coalition fondatrice de neuf entreprises

Le consortium a été annoncé le 19 juillet 2023 par neuf organisations situées à différents maillons de la chaîne de valeur de l'IA et du HPC: AMD, Arista Networks, Broadcom, Cisco, Eviden — alors lié à Atos —, Hewlett Packard Enterprise, Intel, Meta et Microsoft. Cette diversité était un avantage stratégique dès le départ. Un transport conçu uniquement par des fabricants de commutateurs risquerait de négliger les contraintes applicatives et de points terminaux. Un design mené uniquement par des fabricants d'accélérateurs pourrait s'optimiser étroitement autour d'un écosystème matériel.

Un projet purement cloud risquerait de manquer des compétences en silicium, optique et intégration système nécessaires pour transformer l'architecture en produits réels.

AMD apportait processeurs, accélérateurs et réseau de points terminaux. Arista et Cisco apportaient leur expérience du commutation Ethernet à grande échelle et de l'exploitation. Broadcom contribuait par ses siliciums de commutation, ses NIC et ses SerDes haut débit. HPE et Eviden apportaient des systèmes HPC et l'historique d'interconnexions spécialisées. Intel apportait ses compétences en processeurs, Ethernet et logiciels. Meta et Microsoft représentaient des opérateurs hyperscale ayant un intérêt direct à augmenter l'utilisation de leurs grands clusters d'IA et à réduire la dépendance à un unique fournisseur intégré.

La coalition comprend aussi des intérêts commerciaux concurrents. Les membres vendent des NIC, des ASIC de commutation, des systèmes, de la capacité cloud, de l'optique, des logiciels et du support. Certains détiennent des portefeuilles de brevets qui pourraient être nécessaires pour une implémentation. Certains profitent d'un large standard multi-fournisseurs tout en pouvant tirer profit de fonctions propriétaires différenciées. Le consortium ne supprime donc pas la concurrence.

Il crée une enceinte où des concurrents s'accordent sur des interfaces minimales tout en continuant à rivaliser sur la qualité de mise en œuvre, la performance, l'intégration et les conditions commerciales.

L'interconnexion Slingshot de HPE est un bon exemple d'héritage technique. Slingshot est une structure HPC commerciale compatible Ethernet, avec routage adaptatif et gestion de congestion. Des commentaires proches de HPE ont déclaré qu'une spécification « HPC Ethernet » avait été apportée à l'UEC, et ont estimé qu'une grande partie de l'UET provenait des idées de transport de Slingshot. Le pourcentage exact n'est pas vérifié de manière indépendante et ne doit pas être traité comme un chiffre officiel du consortium.

Le point plus général est bien étayé: l'UEC n'est pas parti d'une feuille blanche, mais a puisé dans l'expérience de production du HPC, des réseaux cloud, de RDMA et d'Ethernet.

Ce mélange d'héritages explique pourquoi le mot « ouvert » doit être utilisé avec précision. La spécification UEC ratifiée est téléchargeable publiquement. L'architecture est conçue pour des implémentations multi-fournisseurs. Cependant, le projet est aussi un lieu où les membres apportent des connaissances, des brevets et des feuilles de route produits existants. Le caractère ouvert du document ne supprime pas les conditions économiques ou juridiques de la technologie.

Une série juridique pour la collaboration entre concurrents

Le modèle de la Joint Development Foundation donne une enveloppe formelle à l'UEC sans en faire une société d'exploitation ordinaire. Le projet possède son propre nom, sa portée, ses classes de membres, son comité de pilotage (Steering Committee), ses groupes de travail et ses obligations en matière de propriété intellectuelle. L'égide JDF fournit une infrastructure juridique à but non lucratif et peut détenir les actifs et les contrats du projet. Cela réduit les coûts de formation du consortium et offre aux concurrents un processus reconnu de collaboration.

Le Steering Committee dirige le projet. Parmi ses missions documentées figurent la coordination des groupes de travail, l'admission des membres, la gestion des actifs et des finances, la sélection ou la révocation du président, le suivi de l'avancement et le pilotage des publications publiques et des marques du projet. Le consensus est la règle privilégiée. En cas d'échec, la charte prévoit un mécanisme de majorité qualifiée des trois quarts parmi les membres éligibles ayant satisfait aux obligations de présence. Les réclamations écrites peuvent être adressées au président.

Le président initial était Brad Booth de Meta. La spécification 1.0.3 actuelle cite J Metz de AMD comme président (Chair), Barry Davis de HPE comme vice-président (Vice Chair), Hugh Holbrook de Arista comme président du Technical Advisory Committee (TAC) et Puneet Agarwal de Marvell comme vice-président du TAC. Paul Congdon est mentionné comme éditeur de la spécification. Le document nomme également des responsables et des auteurs pour les travaux sur la couche physique, la liaison, le transport et les logiciels. L'ordre du jour du sommet 2026 énumère d'autres responsables opérationnels.

Ces rôles ne remplacent pas nécessairement les titres formels de la spécification; un organigramme complet à jour n'est pas disponible publiquement.

La charte distingue trois classes de membres: Steering, General et Contributor. Les membres Steering participent à la gouvernance et nomment généralement des représentants au Steering Committee. Les membres General peuvent travailler dans tous les groupes techniques mais ne siègent pas au Steering Committee. Les membres Contributor participent à des groupes choisis et n'ont pas de droit de vote lors des décisions à la majorité qualifiée. La page publique actuelle des membres présente les niveaux General et Contributor avec des frais de projet annuels de 20 000 et 5 000 dollars US respectivement, en plus de l'adhésion à la Linux Foundation.

Elle n'explique pas clairement le chemin d'admission ni le tarif actuel pour le statut Steering.

Les différences de pouvoir formel sont pertinentes. Une large adhésion peut apporter expertise et couverture d'implémentation, mais la gouvernance n'est pas uniformément répartie. Les grandes entreprises qui occupent des postes Steering, délèguent des ingénieurs dans de nombreux groupes et maintiennent des programmes de brevets et de produits disposent d'une influence pratique plus grande que les petits membres Contributor. Les non-membres peuvent télécharger la spécification finale, mais ils ne voient pas l'ensemble du processus d'élaboration et ne participent pas à des conditions égales.

Les informations internes du projet ne sont pas traitées comme des données confidentielles d'entreprise ordinaires, mais les membres ne peuvent divulguer les documents en cours avant que le comité compétent n'autorise la publication. Cela facilite les échanges entre concurrents sur des idées non finalisées sans signal prématuré au marché. En contrepartie, les personnes extérieures ne peuvent consulter les propositions rejetées, les procès-verbaux de vote, les réserves intermédiaires sur l'implémentation ou les négociations derrière les fonctions optionnelles.

Le résultat final est ouvert; le chemin pour y parvenir n'est que partiellement visible.

De quatre groupes de travail à une spécification de 573 pages

La première structure publique de l'UEC en 2023 se concentrait sur quatre groupes de travail: Logiciel, Transport, Liaison et Couche physique. L'ordre reflétait l'ambition de bout en bout. La liste de membres n'a pas été immédiatement ouverte comme une liste de diffusion publique sans restriction. Plus de 200 organisations avaient manifesté leur intérêt, et le consortium a procédé à l'intégration par étapes avec une formation aux processus et aux règles de concurrence. Cette prudence était compréhensible, car les entités sont en concurrence directe sur plusieurs marchés et allaient discuter d'exigences communes de produits et de protocoles.

En décembre 2023, l'UEC annonçait environ 40 entreprises et plus de 300 personnes. Il avait créé un comité technique consultatif (TAC) et s'était étendu à huit groupes de travail. La mission du TAC était la cohérence architecturale: une conception de transport ne devait pas présupposer un comportement de commutateur, une signalisation ou une API qu'un autre groupe n'aurait pas accepté de prendre en charge. En mars 2024, le consortium faisait état de 55 entreprises et de plus de 750 entités actifs, et publiait une description nettement plus claire de l'architecture prévue.

La mise à jour de mars introduisait les concepts qui allaient ensuite apparaître dans la spécification normative: libfabric comme API logicielle, dispersion de paquets (Packet Spraying), ordonnancement flexible, plusieurs modes de livraison, contrôle de congestion piloté par l'émetteur et le récepteur, ECN, Packet Trimming, Link Layer Retry, contrôle de flux optionnel à crédits, sécurité de transport et futurs collectifs dans le réseau. Elle soulignait également que l'UET pouvait fonctionner sur des commutateurs Ethernet existants, tandis que des commutateurs avancés pourraient apporter des performances supplémentaires.

La portée institutionnelle croissait parallèlement aux travaux techniques. L'UEC annonçait 1 193 entités actifs en juillet 2024 et 97 organisations membres en août. Il s'agit de chiffres datés du consortium, basés sur des définitions qui ne sont pas entièrement publiques. Ils ne doivent pas être additionnés mécaniquement aux déclarations ultérieures. En 2025, l'UEC a déclaré que 27 entreprises supplémentaires avaient rejoint le consortium, mais les départs, les fusions et les périodes de rapport qui se chevauchent empêchent d'obtenir un total actuel exact. Le site web lui-même indique que tous les membres ne sont pas affichés.

Le consortium a publié la spécification Ultra Ethernet 1.0 le 11 juin 2025, faisant passer l'UEC d'une feuille de route à une base d'implémentation publique. La version 1.0.1 a suivi en septembre, corrigeant l'algorithme source du contrôle de crédit basé récepteur ainsi que des points rédactionnels. La version 1.0.2 est sortie en janvier 2026, corrigeant des algorithmes de gestion de congestion, les documents officiels divergeant sur la date de publication, qui serait soit le 21, soit le 28 janvier. L'incohérence doit rester visible et ne pas être résolue en silence.

La version 1.0.3, publiée le 16 juillet 2026, est la référence actuelle à la date de recherche. Elle compte 573 pages et ajoute la prise en charge de la signalisation à 200 Gb/s par voie et une capacité de négociation booléenne. Les notes de version mentionnent en outre des corrections nécessaires concernant la livraison de paquets, les crédits de congestion, Link Layer Retry et les Control Ordered Sets de la couche physique, ainsi que des clarifications sur la sécurité de transport, les opérations atomiques et les paquets tronqués.

La distinction entre corrections nécessaires et clarifications rédactionnelles est importante: certaines modifications concernent le comportement conforme et donc la maintenance des implémentations.

Le sommet des membres de 2026 à Denver a marqué une nouvelle transition. L'ordre du jour mettait l'accent sur le déploiement, l'industrialisation, la conformité, la gestion, la performance, le débogage, l'intégration du stockage et les tests des commutateurs et des points terminaux. Le document d'architecture central existe; la crédibilité du projet dépend désormais de plus en plus de la capacité des implémenteurs à construire, qualifier, exploiter et mettre à jour la pile à travers les frontières organisationnelles.

Une architecture à cinq couches fonctionnelles

La spécification actuelle divise Ultra Ethernet en couche logicielle, transport, réseau, liaison et physique. Cette division est utile, mais la valeur du projet réside dans les hypothèses qui relient les couches entre elles.

Au sommet, les frameworks d'IA, MPI, SHMEM et les bibliothèques collectives interagissent via les interfaces OpenFabrics, en particulier libfabric. La sous-couche Semantic Services de l'UET traduit les opérations applicatives en transactions de transport. La sous-couche Packet Delivery décide comment les messages sont mis en paquets, ordonnés, acquittés et récupérés. La gestion de congestion contrôle la quantité de données admises dans la structure (fabric) et la manière dont le trafic est réparti sur les chemins. Une sécurité de transport optionnelle protège le trafic de bout en bout. Le routage IPv4 ou IPv6 standard assure la couche réseau.

Ethernet fournit la liaison avec tronçonnage optionnel des paquets (Packet Trimming), Link Layer Retry, contrôle de flux à crédits (CBFC) et négociation des fonctionnalités. La couche physique définit les exigences de statistiques et de signalisation à 100 ou 200 Gb/s par voie.

Cette structure préserve des parties importantes du réseau existant. L'UEC ne définit pas de remplacement du routage IP. Elle s'attend à des commutateurs ECMP et compatibles ECN standard. Une grande partie de l'intelligence reste dans les points terminaux de la structure (Fabric Endpoints), qui manipulent l'entropie, suivent l'état de transport, placent les données et réagissent aux signaux de congestion. Les commutateurs avancés peuvent ajouter des fonctions, mais la conception n'exige pas que chaque installation remplace l'intégralité de sa structure (fabric) avant que le trafic UET puisse passer.

Cela crée un avantage de migration et un problème de classification. Une installation peut déployer des points terminaux UET sur un Ethernet conventionnel avec ECMP et ECN. Une autre peut ajouter le tronçonnage, Link Retry, des crédits par canal virtuel, une télémétrie plus riche et, plus tard, des fonctions dans le réseau. Ces deux installations peuvent être appelées « Ultra Ethernet », bien que la performance, la récupération et la complexité opérationnelle divergent considérablement.

L'approche en cinq couches complique également la localisation des pannes. Un mauvais résultat peut provenir du mappage applicatif, de la machine d'état du point terminal, des paramètres de congestion, de la configuration des files d'attente du commutateur, du mappage DSCP, de l'optique, du micrologiciel ou du système de sécurité. Transmettre des paquets ne suffit pas. Le système doit préserver la sémantique et la performance attendues en présence de mise à l'échelle, de trafic mixte, d'erreurs et de changements de version.

Le contrat logiciel: libfabric plutôt qu'une API applicative propriétaire

L'UEC choisit libfabric 2.0 comme API northbound fondamentale pour les points terminaux conformes. Cette décision relie le projet à un écosystème HPC et réseau avancé existant, au lieu de forcer chaque framework à adopter une nouvelle interface propriétaire. Libfabric décrit déjà les structures (fabrics), domaines, points terminaux, files d'achèvement, files d'événements, vecteurs d'adresses, régions mémoire, messagerie, opérations mémoire distantes et atomiques. L'UEC mappe ces concepts et les restreint afin que les fournisseurs puissent traduire les appels en comportement UET.

La valeur stratégique est la continuité au-dessus du transport. MPI, SHMEM et les bibliothèques de communication pour accélérateurs peuvent utiliser des abstractions familières pendant que le fournisseur sous-jacent change. En principe, une application peut demander une opération sans savoir quel fournisseur fournit la carte réseau ou quel silicium de commutation achemine les paquets. C'est là un mécanisme central par lequel un transport commun pourrait permettre la sélection des fournisseurs.

L'abstraction ne garantit pas des implémentations équivalentes. Les fournisseurs peuvent différer sur la taille d'injection, les limites de scatter/gather, le nombre de points terminaux, les opérations atomiques, l'enregistrement mémoire, le comportement d'achèvement, le déchargement matériel et les fonctions de sécurité. Une bibliothèque compilée contre la même API peut donc rencontrer des limites de performance ou de capacité différentes. L'approvisionnement et la qualification logicielle nécessitent plus qu'une coche « compatible libfabric ».

La couche logicielle de l'UEC prend également en charge la sémantique des tâches (jobs) et d'autorisation. Les systèmes d'IA et HPC exécutent souvent de nombreuses tâches sur une infrastructure partagée, chacune avec ses propres processus, régions mémoire et périmètres de sécurité. La spécification doit déterminer quel point terminal appartient à quelle tâche, quels tampons sont accessibles, comment les opérations distantes sont mises en correspondance et comment les informations d'achèvement ou d'erreur remontent au logiciel.

Ces décisions déterminent si un réseau rapide est utilisable par l'ordonnanceur, le runtime et l'application, ou s'il n'impressionne que dans un benchmark de paquets.

Le projet dépend de l'écosystème OpenFabrics car il ne possède pas libfabric. Cette relation illustre une caractéristique plus large de l'UEC: l'architecture est composée de composants pilotés à différents endroits. L'UEC peut définir comment son transport se mappe sur libfabric, mais doit se coordonner avec les mainteneurs et les utilisateurs de l'API. Des dépendances similaires existent avec Ethernet IEEE, le réseau IETF, les organisations de stockage et les systèmes d'exploitation des fournisseurs.

Points terminaux de structure (Fabric Endpoints) et profils de charge de travail

Un point terminal de structure (Fabric Endpoint, FEP) est l'emplacement logique où l'UET se termine. Il connecte une instance de système d'exploitation à un ou plusieurs plans de structure (fabric) isolés et peut inclure un fournisseur en espace utilisateur, un pilote noyau, un transport côté carte réseau ou accélérateur, un enregistrement mémoire, un contexte de sécurité, des files d'achèvement, des vecteurs d'adresses, ainsi que l'état pour la livraison de paquets et le contrôle de congestion.

Cette conception centrée sur les points terminaux laisse la plupart des commutateurs reconnaissables en tant que périphériques Ethernet et IP. Le FEP choisit les valeurs d'entropie, maintient l'état des paquets et de la congestion, place les données dans la mémoire autorisée et interprète les accusés de réception, les troncatures et autres signaux de retour. Cela peut réduire la dépendance à une intelligence de routage propriétaire dans le commutateur. En parallèle, cela concentre la complexité dans le silicium de la carte réseau, le micrologiciel, les pilotes et les logiciels.

L'UEC définit trois profils de mise en œuvre: AI Base, AI Full et HPC. Il ne s'agit pas de types de réseau distincts, mais de paquets définissant les fonctions qu'une implémentation doit prendre en charge. AI Base est conçu pour couvrir les communications IA ordinaires avec des coûts d'implémentation et d'état réduits. AI Full ajoute des fonctions telles que les envois différables (Deferrable Sends), la correspondance exacte et les opérations atomiques de type Fetch ou Compare. Le profil HPC inclut la majeure partie de AI Full, exclut Deferrable Send et met davantage l'accent sur l'ordonnancement, les messages courts et la sémantique HPC.

Le système de profils vise à éviter que chaque produit doive implémenter l'ensemble maximal des fonctionnalités. Il reconnaît qu'une carte réseau IA grand volume peut privilégier le déplacement collectif de données, tandis qu'un point terminal HPC a besoin d'un ordonnancement et d'opérations atomiques plus solides. L'optionalité ne disparaît pas pour autant. Un produit peut implémenter des fonctions optionnelles au sein d'un profil, et deux produits portant le même nom de profil peuvent différer sur la sécurité, les extensions de liaison, la capacité et les performances.

La terminologie elle-même est un signal d'avertissement. La spécification normative 1.0.3 utilise AI Base, AI Full et HPC. Un fichier Readme de conformité distinct de 2025 utilise AI Base, AI Extended et HPC. L'interprétation la plus étayée est que « AI Full » est le terme actuel et que le document de conformité est obsolète ou incohérent. Tant que le kit de test public n'est pas corrigé, les fournisseurs et les acheteurs doivent mentionner à la fois la version de la spécification et la terminologie précise du profil derrière une affirmation.

De l'intention applicative à la livraison de paquets

Au sein d'UET, la sous-couche Semantic Services porte l'intention de l'application. Elle définit l'identité du message, l'adressage des tampons, les opérations taguées et non taguées, l'accès mémoire distant, les opérations atomiques, le comportement d'achèvement, les identifiants de job, l'autorisation des tampons, les réponses et les erreurs. La sous-couche Packet Delivery détermine ensuite comment cette intention devient des paquets et comment ils atteignent un autre point terminal.

Pour les modes fiables, les points terminaux établissent des contextes de livraison de paquets (Packet Delivery Contexts, PDC). Un PDC contient l'état tel que les numéros de séquence de paquets, les accusés de réception, la détection de doublons, le mode d'ordonnancement, les informations de congestion, l'état du chemin de retour et la classe de trafic. Un PDC est associé à un mode de livraison et à une classe de trafic; plusieurs PDC peuvent exister entre une même paire de FEP.

Cet état n'est pas un détail d'implémentation secondaire. Les grands clusters peuvent générer un nombre énorme de relations communicantes. Si chaque relation exige un état cible important, le stockage aux points terminaux et les coûts de recherche peuvent devenir limitants. L'UEC n'impose donc pas à chaque opération un modèle de connexion unique, mais définit quatre services de livraison avec des contrats différents pour la fiabilité et l'ordonnancement.

La livraison fiable non ordonnée (Reliable Unordered Delivery, RUD) délivre chaque paquet exactement une fois à la couche sémantique, mais autorise une arrivée dans le désordre. Elle prend en charge la dispersion de paquets (Packet Spraying) sur plusieurs chemins, la retransmission sélective, la suppression des doublons et le placement direct des données. Comme la destination peut placer les données en fonction des offsets, sans attendre un tampon de réordonnancement de transport, une longue opération collective peut utiliser plusieurs chemins sans sérialiser tous les paquets derrière une unité manquante.

La livraison fiable ordonnée (Reliable Ordered Delivery, ROD) garantit une livraison unique et ordonnée. Elle utilise un seul chemin et une seule valeur d'entropie, rejette les paquets hors séquence et utilise une retransmission Go-Back-N à partir du premier numéro de séquence manquant. Cela paraît moins avancé que RUD, mais préserve la sémantique pour les opérations nécessitant un ordre strict. L'UEC traite l'ordonnancement comme une exigence applicative, au lieu d'en faire supporter le coût à chaque transmission.

La livraison fiable non ordonnée pour opérations idempotentes (Reliable Unordered Delivery for Idempotent Operations, RUDI) met l'accent sur un autre point. Elle délivre au moins une fois et autorise les doublons, ce qui réduit l'état habituel de séquence et d'acquittement à la destination. Cela peut être utile lorsqu'une opération répétée ne modifie pas le résultat final, par exemple pour des transferts mémoire distants sélectionnés suivis d'une barrière de synchronisation séparée. Mal utilisée, elle est dangereuse. La couche paquets ne détermine pas elle-même l'idempotence; c'est au logiciel de décider.

Utiliser RUDI pour une opération non idempotente peut produire un état applicatif invalide.

La livraison non fiable non ordonnée (Unreliable Unordered Delivery, UUD) délivre des datagrammes au mieux, sans garantie normale de fiabilité ou d'ordre. Elle appartient au même cadre sémantique, mais n'implique pas les mêmes exigences de contrôle de congestion que RUD et ROD. Les applications doivent empêcher que le trafic UUD ne nuise au trafic contrôlé par la congestion si les files d'attente ou les classes de trafic sont partagées.

Les quatre modes illustrent une philosophie centrale de l'UEC: le réseau doit fournir plusieurs mécanismes afin que le logiciel puisse adapter les coûts de transport à la sémantique de l'opération. Le bénéfice est l'efficacité. Le prix est une surface d'implémentation et de test plus grande, avec plus de possibilités pour le fournisseur, l'application ou l'opérateur de choisir une combinaison incompatible.

Dispersion de paquets (Packet Spraying): exploiter la structure (fabric) plutôt qu'espérer un chemin chanceux

Le chemin multiple à coût égal (ECMP) conventionnel place souvent un flux entier sur une route unique via un hachage. Dans une large structure (fabric) Clos, cela crée une loterie. Plusieurs gros flux peuvent entrer en collision sur les mêmes liaisons tandis que de la capacité équivalente reste inutilisée ailleurs. Un long transfert d'IA est alors limité pendant toute sa durée de vie par un hachage malchanceux.

L'UET répond à cela en modifiant l'entropie au niveau paquet. Un émetteur peut utiliser des dizaines ou des centaines de valeurs d'entropie, de sorte que les mécanismes ECMP existants des commutateurs distribuent les paquets sur de nombreuses routes. La sous-couche Packet Delivery fournit les informations de séquence; la sous-couche Congestion Management choisit l'entropie ou le chemin; les commutateurs exécutent leur hachage normal; les signaux de retour indiquent à l'émetteur quelles valeurs sont suspectes de congestion.

La dispersion de paquets n'est viable que parce que d'autres parties de la conception la soutiennent. Les paquets peuvent arriver dans le désordre. RUD peut placer les données directement au lieu d'attendre une remise en ordre complète au niveau transport. La retransmission sélective ne reprend que ce qui est perdu. Les signaux de congestion réduisent l'utilisation des chemins problématiques. Le mécanisme n'est donc pas une astuce d'équilibrage de charge isolée; il fait partie intégrante d'un modèle de transport qui s'appuie sur la diversité des chemins.

L'UEC n'exige pas de chaque commutateur un algorithme propriétaire de routage adaptatif. Les implémentations de base peuvent utiliser un round-robin ou une entropie pseudo-aléatoire sur l'ECMP standard. Les points terminaux plus avancés peuvent associer les signaux ECN, de latence ou de tronçonnage à des valeurs d'entropie spécifiques et éviter les chemins congestionnés. Un acheminement adaptatif propre à un fournisseur peut coexister avec UET, mais n'est pas la seule source de connaissance des chemins.

La promesse est une meilleure utilisation de la structure (fabric) et une latence de queue plus faible. Reste à savoir dans quelle mesure différents points terminaux interprètent les signaux de retour de manière uniforme et comment la dispersion de paquets interagit avec les tampons des commutateurs, le réordonnancement, les erreurs et le trafic mixte. Un algorithme qui fonctionne dans un laboratoire homogène peut se comporter différemment dans une vaste structure (fabric) comportant plusieurs générations de commutateurs et classes de trafic. Les preuves indépendantes multi-fournisseurs restent limitées.

Trois mécanismes de congestion pour trois goulots d'étranglement distincts

L'UEC ne définit pas un algorithme de congestion universel. Il distingue la congestion dans le cœur de réseau, l'incast au niveau du récepteur et les tampons limités aux points terminaux.

Le contrôle de congestion signalé par le réseau (Network-signal Congestion Control, NSCC) est piloté par la source. L'émetteur maintient une fenêtre de congestion, estime les octets en vol et ajuste la fenêtre en fonction des accusés de réception, des accusés de réception négatifs, des délais d'attente, de la latence et des signaux réseau tels qu'ECN. Le comportement de la fenêtre est coordonné avec le trajets multiples par paquet.

L'UEC soutient qu'une fenêtre arrête naturellement l'admission de nouvelles données lorsque les paquets ne quittent plus le réseau, tandis qu'un contrôleur purement basé sur le débit peut mal interpréter l'absence de signal de retour.

C'est là l'argument architectural du consortium, pas une preuve indépendante que toute implémentation NSCC surpasse DCQCN ou d'autres méthodes de congestion RoCE. Les résultats dépendent des détails de l'algorithme, du marquage des commutateurs, de la topologie, des motifs de trafic et des paramètres. « Utilise NSCC » n'est donc pas une déclaration de performance suffisante.

Le contrôle de congestion par crédit récepteur (Receiver-credit Congestion Control, RCCC) s'attaque à l'incast. Lorsque de nombreuses sources émettent simultanément vers une destination, le dernier lien peut devenir le goulot même si le cœur de réseau n'est pas congestionné. Le récepteur suit la demande et distribue des crédits entre les émetteurs, cadence ainsi l'arrivée globale et fait varier la fenêtre effective de chaque source en fonction de la concurrence. RCCC peut fonctionner avec NSCC, car la congestion au récepteur et la congestion dans le cœur sont des problèmes différents.

Le contrôle de flux de transport (Transport Flow Control, TFC) utilise également des crédits, mais il est prévu pour les services point à point avec des tampons limités. L'objectif est d'empêcher directement le débordement du tampon de réception lorsque la tolérance aux pertes est faible. TFC peut être utilisé avec ou sans trajets multiples. Mettre tous les mécanismes à crédits sur le même plan masquerait les domaines de défaillance distincts qu'ils sont censés contrôler.

La spécification s'attend à une notification explicite de congestion (ECN) dans toute la structure (fabric) et inclut des hypothèses opérationnelles sur le marquage, y compris le marquage au défilement plutôt qu'exclusivement à l'encodage. Les points terminaux interprètent ECN en combinaison avec les accusés de réception, la latence et le tronçonnage. Une configuration uniforme des commutateurs est donc indispensable. Une implémentation de transport correcte peut néanmoins produire de mauvais résultats dans une structure (fabric) mal configurée.

L'historique de maintenance illustre la difficulté. La version 1.0.1 a corrigé l'algorithme source RCCC. La version 1.0.2 a corrigé des cas de gestion de congestion. La version 1.0.3 a corrigé les interactions entre les crédits et Link Layer Retry. Ce sont des signes normaux d'une spécification vivante, mais aussi des preuves que l'état de crédit, de retransmission et de contrôle de chemin interagissent subtilement. Les opérateurs ont besoin de discipline de version et de tests de régression, pas seulement de conformité au premier jour.

Tronçonnage de paquets (Packet Trimming) et récupération précise des pertes

Le tronçonnage de paquets (Packet Trimming) modifie ce que fait un commutateur approprié lorsqu'il ne peut pas conserver un paquet complet. Au lieu de rejeter la trame sans autre information, le commutateur supprime la majeure partie ou la totalité de la charge utile, conserve suffisamment d'en-tête et de métadonnées pour l'identification, marque le paquet comme « tronqué » et achemine la notification raccourcie vers le récepteur. Celui-ci peut ensuite signaler à l'émetteur précisément les données manquantes.

Cela est plus informatif qu'un marquage ECN. ECN dit qu'une congestion s'est produite; le tronçonnage désigne un paquet dont la charge utile n'a pas survécu. En combinaison avec RUD et la retransmission sélective, cela peut accélérer la récupération sans attendre un délai d'attente ni réémettre une longue séquence à cause d'une perte unique.

La fonction de commutateur est optionnelle, mais les points terminaux conformes doivent pouvoir recevoir et interpréter les paquets tronqués selon les exigences applicables. Cette asymétrie permet des déploiements sur des commutateurs conventionnels tout en offrant aux structures (fabric) avancées des informations de perte plus riches. En même temps, cela crée un problème de mise à niveau. Un réseau partiellement amélioré peut devoir limiter le tronçonnage par chemin, profil ou topologie afin que chaque point terminal récepteur le gère correctement.

L'UEC définit également différentes classes de trafic pour les requêtes, les paquets de contrôle, les retransmissions et le trafic tronqué. Les opérateurs doivent mapper de manière cohérente les valeurs DSCP, les files d'attente des commutateurs, les files d'attente des points terminaux et les niveaux de priorité. La spécification ne fournit pas de système universel de gestion pour cela. Un mauvais mappage peut affamer le trafic de contrôle, fausser les signaux de congestion ou mettre les paquets de récupération en concurrence avec le trafic qu'ils sont censés réparer.

Le tronçonnage de paquets illustre la tâche d'implémentation plus large du projet. Le protocole peut définir le comportement sur le câble, mais le résultat opérationnel dépend de la mise en file d'attente du commutateur, de la logique du point terminal, de la télémétrie, de la configuration et du traitement des erreurs. L'interopérabilité est une propriété du système, pas seulement une propriété du format de paquet.

Récupération de liaison, crédits et négociation des fonctionnalités

Link Layer Retry (LLR) tente de corriger les erreurs sur une liaison physique avant que le transport de bout en bout ne réagisse. Un pair détecte une lacune de séquence ou une trame corrompue, envoie un accusé de réception négatif local à la liaison et incite l'émetteur à répéter la trame concernée depuis un tampon local. Si la récupération réussit rapidement, le transport peut éviter une retransmission de bout en bout plus longue.

La valeur potentielle augmente avec les débits par voie et la densité de ports. Des erreurs optiques ou électriques occasionnelles pourraient autrement engendrer des retards disproportionnés dans un job étroitement synchronisé. LLR ajoute cependant un état de séquence, un tampon de rejeu, des messages de contrôle, une fenêtre de rejet et de nouveaux modes de défaillance. Il doit également coexister avec les mises à jour de crédits et les réinitialisations de liaison. La version 1.0.3 a corrigé plusieurs cas limites, dont une condition de concurrence entre les informations de crédit CBFC et LLR.

Le contrôle de flux à base de crédits (Credit-Based Flow Control, CBFC) fonctionne au niveau liaison par canal virtuel. Il indique à un émetteur la capacité de réception restante et peut être plus granulaire qu'une pause de priorité étendue. L'UEC le décrit comme un moyen d'obtenir un comportement sans perte contrôlé, sans exiger que chaque structure (fabric) UET soit entièrement sans perte. CBFC est optionnel et UET doit également fonctionner sur des réseaux au mieux (best-effort).

CBFC n'est pas simplement un autre nom pour le contrôle de flux prioritaire (Priority Flow Control). La signalisation et la granularité diffèrent, bien que les deux visent à prévenir le débordement de tampon. CBFC nécessite toujours une configuration cohérente et la livraison correcte de ses propres trames de contrôle. De plus, les crédits locaux peuvent interagir avec les fenêtres de bout en bout et les crédits du récepteur, créant plusieurs boucles de contrôle imbriquées.

L'UEC utilise une négociation basée sur LLDP pour découvrir les fonctionnalités optionnelles de liaison et empêcher qu'un côté n'active une capacité que le voisin ne prend pas en charge. La négociation doit tenir compte des profils, des canaux virtuels, du mappage DSCP et de priorité, des réinitialisations, des mises à niveau logicielles et des combinaisons partielles de fonctionnalités. La version 1.0.3 a ajouté une capacité de négociation booléenne, soulignant le besoin d'un accord explicite sur chaque liaison.

Ces options créent un chemin depuis l'Ethernet de base vers l'Ethernet avancé. En même temps, cela engendre une matrice que le langage d'approvisionnement peut masquer. Un commutateur peut parfaitement acheminer UET sans prendre en charge le tronçonnage, LLR ou CBFC. Un autre peut offrir les fonctions uniquement dans certaines versions logicielles ou modes de port. Une preuve crédible de déploiement nécessite l'ensemble exact des fonctionnalités, pas seulement le nom du consortium.

Signalisation physique à 100 et 200 gigabits par voie

La couche physique ancre l'UEC dans la feuille de route matérielle. Le travail initial de la version 1.0 était axé sur la signalisation à 100 Gb/s par voie. La version 1.0.3 a ajouté 200 Gb/s par voie. Cela aligne la spécification sur une génération de liaisons et de systèmes plus denses; mais la présence d'une capacité dans le document ne prouve pas que tous les produits UEC la prennent en charge immédiatement.

Le travail PHY traite également des statistiques de correction d'erreurs directe (FEC), des ratios de mots de code corrigés et incorrigibles, des Control Ordered Sets, des rapports de qualité de liaison et de l'interaction des erreurs physiques avec LLR. Ces détails sont importants car les décisions de transport sur la récupération dépendent de ce que les couches inférieures peuvent observer et rapporter.

Avec des débits de signalisation plus élevés, la frontière entre optique, SerDes, FEC, Link Retry et récupération de transport devient économiquement significative. Une FEC plus forte peut réduire les erreurs résiduelles au prix de la latence et de l'énergie. Link Retry peut corriger les erreurs locales plus rapidement, mais exige des tampons et de l'état. La retransmission de bout en bout est plus simple à l'échelle du réseau, mais peut gaspiller plus de temps. L'UEC tente de définir comment ces couches interagissent, au lieu de laisser chaque fournisseur optimiser isolément.

L'ajout des voies à 200G montre aussi la cible mouvante du consortium. Les implémenteurs de la version 1.0 doivent maintenir la compatibilité tout en planifiant de nouvelles capacités physiques. Les équipements de test, le micrologiciel et les systèmes de gestion doivent distinguer ce que chaque port prend en charge. Les acheteurs ne doivent pas déduire le débit par voie d'une déclaration UEC générique.

Sécurité de transport optionnelle de bout en bout

La sous-couche de sécurité de transport (Transport Security Sublayer, TSS) offre une protection optionnelle de point terminal à point terminal. Son modèle de menace n'exige pas de confiance dans les commutateurs. Elle peut fournir confidentialité, intégrité, protection contre le rejeu, isolation des jobs, domaines sécurisés, clés de groupe, rotation des clés et intégration de racines de confiance matérielles.

La conception utilise des domaines sécurisés dont les membres partagent un contexte cryptographique. Les identifiants, les numéros d'association, les époques, l'identité de source sécurisée et la dérivation des clés visent à mieux passer à l'échelle qu'une session distincte pour chaque paire de points terminaux. Cela est nécessaire lorsque les populations d'accélérateurs et les appartenances de jobs changent rapidement.

Le protocole n'est qu'une partie du système de sécurité. Un opérateur en production doit gérer des autorités de clés, des certificats ou d'autres racines de confiance, des services d'appartenance aux jobs, la distribution et la révocation, les changements d'époque, la récupération des points terminaux, la cryptographie matérielle et la télémétrie de sécurité. Un réseau peut être conforme à un profil sans activer toutes les fonctions optionnelles TSS. « Conforme UEC » ne signifie pas automatiquement « chiffré ».

L'optionalité reflète des hypothèses de déploiement différentes. Une structure (fabric) dédiée et contrôlée physiquement peut privilégier la performance et s'appuyer sur des mesures environnementales. Un cloud multi-locataire peut exiger une isolation forte et une protection cryptographique. Les systèmes de profils et d'approvisionnement doivent rendre la différence visible.

Le plus grand risque n'est pas seulement le surcoût de chiffrement. C'est la défaillance du cycle de vie à grande échelle: appartenance obsolète, révocation tardive, époques incohérentes, récupération après défaillance d'un point terminal, ou incapacité à démontrer quel job peut accéder à quelle mémoire. Ces problèmes relient la sécurité de transport aux systèmes d'orchestration et d'identité en dehors du cœur de la spécification.

Ce que « conforme UEC » signifie actuellement

L'UEC a commencé à publier des documents de conformité avec la version 1.0, mais le système public n'est pas un régime de certification indépendant mature. Le kit disponible est principalement conçu pour des autodéclarations des implémenteurs. Des matrices mappent les exigences de la spécification aux profils, et des guides de banc d'essai décrivent les configurations recommandées pour les points terminaux et les commutateurs. Aucun registre public complet dans lequel une entité indépendante répertorierait les produits comme ayant réussi ou échoué à un programme UEC complet n'a été trouvé.

La distinction est essentielle car différentes affirmations circulent sur le marché. Un produit peut être conçu autour des fonctionnalités UEC en évolution. Il peut implémenter des fonctions de câble sélectionnées. Il peut prendre en charge un profil ou des parties de celui-ci dans une version logicielle donnée. Un fournisseur peut revendiquer une conformité complète des fonctionnalités. Un laboratoire peut générer du trafic UET à travers un commutateur. Aucune de ces déclarations n'équivaut automatiquement à une certification indépendante, de bout en bout et multi-fournisseurs.

Les recommandations publiques de banc d'essai sont utiles, mais délibérément limitées. Elles fournissent des bonnes pratiques de topologie et des vérifications plutôt qu'une qualification système complète. L'interopérabilité plus large, la performance, le stress, l'échelle et le cycle de vie des API sont exclus ou pas entièrement couverts. Les documents ne prouvent pas le comportement avec du trafic mixte UET et RoCE, des mises à niveau partielles, des erreurs répétées, de grands domaines de clés ou les chiffres les plus ambitieux de points terminaux du consortium.

L'incohérence entre AI Full et AI Extended montre aussi pourquoi la conformité exige un versionnage rigoureux. Les acheteurs devraient demander quelle spécification, quel niveau de correctif, quel profil, quelles fonctions optionnelles, quels modes de liaison et quelles fonctions de sécurité une déclaration englobe. La réponse devrait expliquer si la preuve provient de tests internes, d'une démonstration bilatérale, d'un événement du consortium ou d'un laboratoire indépendant.

Une prochaine étape crédible serait des définitions de test publiques liées à des versions de spécification précises, des plugfests multi-fournisseurs, des résultats gérés de manière indépendante incluant les résultats négatifs, et un registre distinguant les points terminaux, les commutateurs, les logiciels et les systèmes complets. D'ici là, « conforme UEC » est une question d'entrée, pas une assurance complète.

Un document ouvert avec des obligations de brevets RAND

La spécification Ultra Ethernet 1.0.3 est téléchargeable publiquement et diffusée sous Creative Commons Attribution-NoDerivatives 4.0. Cela autorise la redistribution avec attribution, mais pas la diffusion de versions modifiées sous cette licence. Plus important encore, l'accès au droit d'auteur et l'accès aux brevets sont distincts.

Les chartes documentées des groupes de travail utilisent généralement un modèle de spécification traditionnel avec licence de brevet raisonnable et non discriminatoire (RAND). RAND ne signifie pas nécessairement sans redevance. Cela ne garantit pas un prix uniforme, n'élimine pas les négociations et n'empêche pas les litiges sur la validité, le caractère essentiel, la géographie ou les conditions défensives. La position commerciale réelle dépend de chaque brevet déclaré, de l'engagement du membre et d'une licence bilatérale.

L'UEC tient un registre public des déclarations de revendications nécessaires (Necessary Claims). À la date d'arrêté, des déclarations de Broadcom, Microsoft, Huawei, Qualcomm, AMD, HPE, Google, Marvell et d'autres étaient visibles, y compris des soumissions pour les travaux futurs de la version 1.1. Ce registre accroît la transparence, car il montre que les implémenteurs doivent examiner la propriété intellectuelle avant de développer ou livrer un produit.

Le consortium ne décide pas expressément si un brevet déclaré est valide, effectivement essentiel, contrefait ou disponible à un prix donné. Il ne publie pas non plus de licence commune. Les petits implémenteurs peuvent donc supporter des coûts juridiques et de transaction que les grands membres absorbent plus facilement. Une spécification accessible au public peut néanmoins produire un écosystème commercialement concentré si la mise à disposition des brevets, les coûts du silicium et les charges de test sont élevés.

Le cadre de PI façonne également les incitations de gouvernance. Les entreprises apportent de la technologie pour créer un vaste marché pour leurs produits et s'assurer que les capacités existantes sont représentées dans la conception commune. Les déclarations de brevets ne protègent les implémenteurs des surprises que si elles sont faites en temps voulu et de manière suffisamment claire. Elles n'éliminent pas la possibilité que la licence devienne une barrière après une adoption croissante.

La description honnête est donc « publié ouvertement et multi-fournisseurs, avec des obligations de brevet RAND », et non « universellement sans redevance ». Les équipes d'approvisionnement ont besoin à la fois du profil technique et du chemin de licence.

La première vague de produits et de tests

Des preuves d'implémentation sont apparues autour de la publication de la version 1.0, mais les exemples se situent à différents stades de maturité.

AMD a rendu sa carte réseau IA Pollara 400 commercialement disponible en avril 2025 et l'a décrite comme conçue autour des capacités UEC en évolution. Pollara est une plateforme de point terminal programmable et un signal important que le transport est passé dans du matériel livrable. La formulation est cruciale: une conception pour des fonctionnalités UEC en évolution n'est pas une certification indépendante par rapport à toutes les exigences finales de la version 1.0.3.

Broadcom a annoncé Tomahawk 6 en juin 2025 comme un ASIC de commutation à 102,4 térabits par seconde avec des fonctions pertinentes pour UEC. En octobre a suivi la carte réseau Thor Ultra 800G avec l'affirmation par le fournisseur d'une conformité totale aux fonctionnalités UEC. C'est une déclaration significative, mais les preuves publiques n'en font pas un certificat indépendant du consortium. L'échantillonnage, la maturité logicielle et la prise en charge exacte du profil doivent être indiqués séparément.

Nokia et Keysight ont annoncé en octobre 2025 une démonstration de bout en bout de trafic UET sur les familles de commutateurs de centre de données 7220 et 7250 de Nokia à 800 Gigabit Ethernet. Keysight a fourni la génération de trafic et la validation. Le test montre que le trafic UET peut traverser des systèmes de commutation commerciaux et qu'un support d'équipement de test émerge. Il ne démontre pas un profil de point terminal multi-fournisseurs complet, une échelle de production ni une certification indépendante de toutes les fonctions optionnelles.

D'autres membres ont décrit des commutateurs, systèmes, logiciels ou plans de test compatibles UEC, et le sommet de 2026 s'est fortement concentré sur l'industrialisation. Les preuves corroborent la transition vers la mise en œuvre. Elles ne corroborent pas encore un nombre précis de cartes réseau UET en cours de livraison, de commutateurs certifiés, de régions cloud productives ou de structures (fabric) complètes.

Le plus pertinent est de lire la vague de produits comme une chaîne de preuves. Une spécification publique permet la conception. Les annonces de silicium et de cartes réseau montrent l'investissement. Les démonstrations de trafic montrent une partie de l'interopérabilité. Les matrices de conformité mappent les exigences. Des rapports de déploiement par les opérateurs montreraient la valeur opérationnelle. Des plugfests indépendants et des résultats de production apporteraient la crédibilité plus large qui fait actuellement défaut.

RoCE, InfiniBand, Slingshot et UALink

L'UEC entre sur un marché doté d'alternatives matures et de technologies adjacentes. L'argument stratégique n'est pas qu'Ethernet n'a jamais transporté RDMA ou que les structures (fabric) spécialisées ne fonctionnent pas. Il est que l'échelle et la synchronisation des charges de travail IA actuelles justifient une nouvelle architecture Ethernet de bout en bout avec une livraison plus flexible, une utilisation des chemins et un contrôle de congestion plus adaptés.

RoCEv2 est le prédécesseur direct et une technologie installée importante. Il transporte RDMA sur Ethernet routable et est largement pris en charge par les applications et les produits. L'UEC critique les installations RoCE typiques pour le fait de lier des flux entiers à un seul chemin, la reprise Go-Back-N, le réordonnancement au récepteur, le réglage difficile de DCQCN, la dépendance au Priority Flow Control dans de nombreuses conceptions et un comportement faible en situation d'incast ou de rafales collectives. Ce sont des positions techniques de l'UEC, pas une preuve que chaque réseau RoCE fonctionne mal.

La comparaison est dynamique. Les fournisseurs peuvent intégrer le routage adaptatif, la dispersion de paquets, de meilleurs algorithmes de congestion ou d'autres fonctions de type UEC dans des cartes réseau programmables tout en conservant la compatibilité RoCE. La présentation par AMD de Pollara, par exemple, présente RoCEv2 et UEC RDMA comme des options sur du matériel programmable. L'UEC peut donc concurrencer RoCE en tant que transport complet tout en influençant le développement des futurs produits RoCE.

InfiniBand est la principale alternative de structure (fabric) spécialisée. Il offre un écosystème intégré de RDMA, de congestion, de fiabilité de liaison et de gestion avec une longue expérience HPC. Les travaux de la version 2.0 de l'InfiniBand Trade Association incluent la prise en charge XDR pour 200 Gb/s par voie et une télémétrie mise à jour. La différenciation la plus forte de l'UEC n'est pas l'affirmation qu'InfiniBand manque de performance. C'est la possibilité d'obtenir un comportement IA et HPC à travers la chaîne d'approvisionnement Ethernet plus large, le routage IP standard et un plus grand choix multi-fournisseurs.

HPE Slingshot occupe une position intermédiaire. C'est une structure (fabric) HPC commerciale compatible Ethernet avec routage adaptatif et gestion de congestion, et il a fourni des précurseurs techniques importants pour UET. Il montre qu'un comportement spécialisé peut être construit sur Ethernet, tout en montrant la différence entre une plateforme commerciale contrôlée et une spécification à l'échelle de l'industrie.

UALink est généralement complémentaire plutôt que remplacement direct. Sa spécification publique actuelle à 200G vise les connexions scale-up à faible latence entre accélérateurs au sein d'un pod et décrit des systèmes jusqu'à 1 024 accélérateurs. UEC 1.0 est principalement une structure (fabric) scale-out reliant des nœuds via des commutateurs. Un centre de données peut utiliser une liaison scale-up à l'intérieur d'un pod de calcul et UEC entre pods ou nœuds. De futurs travaux UEC sur le transport scale-up optimisé et les collectifs dans le réseau pourraient rapprocher les frontières et créer convergence ou concurrence.

NVIDIA Spectrum-X et les structures (fabric) d'accélérateurs propriétaires constituent une autre comparaison. Une pile étroitement intégrée peut optimiser rapidement le matériel, les logiciels et le support, mais augmente la dépendance à un écosystème unique. L'UEC échange une partie de cette intégration contre la promesse d'interfaces communes et de choix de fournisseurs. La pertinence de cet échange dépend de la performance, du support, des conditions de brevets, de l'interopérabilité et du coût total de possession — et non de « l'ouverture » comme étiquette abstraite.

Le problème opérationnel est plus grand que le protocole

Une spécification de 573 pages peut définir de nombreuses exigences, mais une structure (fabric) productive nécessite toujours un modèle opérationnel. UEC 1.0 laisse d'importants travaux de gestion en dehors ou à la marge du noyau normatif. Les opérateurs doivent configurer de manière cohérente les profils, les classes de trafic, les seuils ECN, les quantités d'entropie, les fonctions de liaison optionnelles, les clés, le micrologiciel, la télémétrie et les règles d'erreur à travers les points terminaux et les commutateurs.

Le trafic mixte complique la tâche. Une structure (fabric) de centre de données peut transporter UET, RoCE, TCP, du stockage, de la gestion ainsi que des services UET ordonnés et non ordonnés. L'allocation des files d'attente et l'équité entre ces classes ne sont pas résolues uniquement parce que chaque protocole est correctement implémenté. Un algorithme de congestion peut bien fonctionner isolément et mal en concurrence avec un autre contrôleur ayant des signaux de retour et des hypothèses différents.

La complexité des points terminaux est un autre risque structurel. UET place le trajets multiples, le placement direct, la retransmission sélective, plusieurs modes de livraison, le contrôle par fenêtre et par crédit, la réception de tronçonnage, la sécurité et beaucoup d'état dans le FEP. Cela peut augmenter la surface de la puce de la carte réseau, la taille du micrologiciel, l'effort de vérification, la consommation d'énergie et le nombre de conditions d'erreur à diagnostiquer.

L'intelligence aux points terminaux permet une large chaîne d'approvisionnement, mais peut déplacer la mise en œuvre la plus difficile dans le composant que chaque serveur doit acheter.

Les fonctions optionnelles créent simultanément une différenciation produit et une fragmentation. Un fournisseur peut optimiser un point terminal AI Base de base pour ECMP et ECN conventionnels. Un autre prend en charge AI Full, TSS, le tronçonnage, LLR et CBFC. Tous deux appartiennent à l'écosystème UEC, mais les opérateurs ne doivent pas présumer de la même sémantique, performance ou sécurité. Les matrices de conformité doivent devenir des matrices de capacité opérationnelle.

La maintenance des versions sera continue. Les correctifs de 1.0.1 à 1.0.3 ont touché la congestion, les crédits, les reprises et le comportement des paquets. Un grand cluster peut contenir plusieurs états de micrologiciel de carte réseau, versions de commutateur et outils de test. Mettre à jour une couche sans coordination avec les autres peut déclencher précisément les conditions de concurrence transversales que le consortium cherche à éviter.

Les alliances externes de l'UEC sont donc centrales et non protocolaires. L'Open Compute Project relie le transport aux systèmes ouverts et au matériel. L'OpenFabrics Alliance et la communauté libfabric connectent les applications. IEEE 802.3 fournit les travaux Ethernet formels. SNIA et NVM Express apportent les exigences de stockage et de gestion. Les technologies IETF fournissent IP, ECN et les mécanismes connexes. Ces organisations ont des processus de décision et des feuilles de route différents; la liaison réduit les doublons, mais ne garantit pas une adoption simultanée.

Le test opérationnel ultime est l'infrastructure en fonctionnement. Un document peut spécifier un comportement, un fournisseur annoncer un produit et un consortium organiser un sommet. Rien de tout cela ne remplace un cluster dans lequel des points terminaux et commutateurs indépendants terminent des jobs réels sous congestion, erreurs et mises à niveau, et où les opérateurs peuvent expliquer ce qui s'est passé.

Pertinence actuelle: du succès de la spécification à la crédibilité de la mise en œuvre

En juillet 2026, l'UEC avait atteint plusieurs objectifs qui étaient incertains au départ. Il a formé une large coalition, créé une architecture intégrée à cinq couches, publié une spécification 1.0 complète, l'a maintenue avec des versions correctives, ajouté le 200G par voie, divulgué les déclarations de brevets et suscité des annonces de produits et de tests. Le projet est actif, et son agenda a nettement basculé vers la mise en œuvre.

Ce progrès rend les prochaines incertitudes plus importantes, et non moins. L'effectif exact des membres et la composition du Steering Committee ne sont pas publiés dans un registre unique faisant autorité. Les pages publiques des membres et la charte décrivent l'accès de manière différente. La direction formelle du TAC n'est pas entièrement alignée avec les rôles du sommet. La date de la version 1.0.2 est contradictoire dans les documents officiels. Le kit de conformité utilise une terminologie de profil obsolète.

Aucun de ces points ne détruit l'architecture, mais chacun est un signal sur le contrôle documentaire et la transparence dans un projet où les versions exactes comptent.

Des lacunes plus importantes concernent l'adoption. L'UEC ne publie ni recensement de déploiement, ni registre de produits vérifié de manière indépendante, ni budget autonome, ni états financiers audités. Les preuves publiques ne démontrent pas un réseau UEC 1.0 entièrement interopérable aux objectifs d'échelle maximale du consortium. Les démonstrations et affirmations des fournisseurs sont précieuses, mais elles proviennent de parties ayant un intérêt commercial. Les comparaisons de performance neutres avec les dernières versions de RoCE, InfiniBand et les plates-formes Ethernet intégrées restent limitées.

L'opportunité reste considérable. Ethernet est le dénominateur commun dans les centres de données, et le marché de l'infrastructure IA est assez grand pour de nouvelles générations de cartes réseau, commutateurs, optiques et logiciels. Les opérateurs ont de fortes incitations à éviter la dépendance à un fournisseur unique et à augmenter l'utilisation des accélérateurs. Une pile commune pourrait traduire ces incitations en pouvoir d'achat.

Le risque est que « Ultra Ethernet » devienne un chapeau pour des sous-ensembles de fonctionnalités incompatibles. Si le transfert de base fonctionne, tandis que les profils, la congestion, la sécurité et la gestion divergent, la marque peut se répandre plus vite que l'interopérabilité. Si la licence RAND est coûteuse ou floue, le cercle des fournisseurs peut se restreindre. Si les produits RoCE adoptent les idées les plus attractives sans nouveau transport, l'UEC peut influencer le marché sans devenir le label dominant.

La question décisive n'est plus de savoir si le consortium peut publier une spécification ambitieuse. Il l'a fait. La question est de savoir si des organisations indépendantes peuvent implémenter les mêmes contrats, concéder sous licence la technologie nécessaire, exploiter la structure (fabric) à grande échelle et maintenir la compatibilité tout en évoluant. L'UEC ne deviendra une infrastructure que dans la mesure où ces prétentions résisteront au contact du code en fonctionnement.