Ultra Ethernet Consortium : reconstruire Ethernet pour l’IA à grande échelle

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 de spécification industrielle, et non d’une entreprise classique ou d’un opérateur de réseau.
• Le périmètre de l’UEC dépasse une liaison Ethernet plus rapide ou un simple remplacement de RoCE. Sa spécification 1.0.3 de 573 pages couvre les couches logiciel, transport, réseau, liaison et physique, avec des travaux complémentaires sur la gestion, le stockage, les essais et la conformité.
• Ultra Ethernet Transport associe plusieurs modes de livraison, le multipath au niveau du paquet, la retransmission sélective, des contrôles de congestion pilotés par l’émetteur et le récepteur, ECN, la troncature facultative des paquets, la reprise locale facultative, le contrôle de flux par crédits facultatif et une sécurité de transport de bout en bout facultative.
• Les produits et démonstrations d’AMD, Broadcom, Nokia et Keysight montrent que l’implémentation a commencé, mais la conformité publique repose encore surtout sur l’auto-attestation des fournisseurs, sans registre complet de certification indépendante ni recensement des déploiements à grande échelle.
• L’opportunité stratégique de l’UEC vient de la base installée d’Ethernet et de sa chaîne d’approvisionnement multi-fournisseurs. Ses principaux risques sont la complexité des points d’extrémité, la fragmentation par fonctions optionnelles, les obligations de brevets RAND, la maturité limitée de la gestion et des essais, et l’écart entre la publication d’une spécification et l’interopérabilité vérifié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 du calcul. Dans un réseau d’entreprise ordinaire, la fabrique doit transporter de nombreux flux indépendants avec un débit et une disponibilité acceptables. Dans un grand système d’entraînement d’intelligence artificielle ou une machine de calcul haute performance, le réseau devient une composante d’un même calcul synchronisé. Des milliers d’accélérateurs peuvent échanger des paramètres de modèle, des gradients ou des données scientifiques au cours d’opérations collectives.

Une phase peut rester bloquée tant que le participant le plus lent n’a pas reçu les informations requises. Un léger déséquilibre de chemin, un épisode de congestion ou une perte de paquet peut donc laisser des processeurs très coûteux inactifs, même si l’utilisation moyenne de la fabrique semble satisfaisante.

Les critères d’optimisation changent. La bande passante agrégée reste importante, mais elle ne suffit plus. Les opérateurs surveillent aussi le temps d’achèvement des tâches, la latence de queue, l’incast, la reprise après perte, la répartition du trafic entre chemins parallèles et la quantité d’état que les points d’extrémité doivent conserver. Un réseau qui livre rapidement la plupart des paquets mais retarde une faible fraction peut ralentir toute une opération collective. Une méthode de retransmission acceptable pour un trafic conventionnel peut perdre trop de temps lorsqu’un seul paquet manque dans un message long.

Un flux fixé sur un seul chemin ECMP peut sous-performer alors que de la capacité reste disponible ailleurs dans la topologie.

La proposition fondatrice de l’UEC était que ces difficultés ne pouvaient pas être résolues par une seule fonction de commutateur ni par un seul algorithme de congestion. 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 du transport, la livraison des paquets, le contrôle de congestion, le routage IP, les liaisons Ethernet, l’optique et la signalisation physique.

Si ces couches sont conçues séparément, une optimisation locale peut simplement déplacer le goulet d’étranglement ou créer des hypothèses incompatibles ailleurs.

La réponse de l’UEC est une architecture coordonnée. Elle conserve Ethernet et IP parce que les opérateurs les connaissent déjà et qu’une immense chaîne industrielle existe autour des commutateurs, des optiques, des câbles, des systèmes d’exploitation réseau, de la télémétrie et de la gestion. Elle remplace ou étend les parties que le consortium juge mal adaptées aux charges IA et HPC de grande taille. Le résultat n’est pas « Ethernet ordinaire avec un nouveau logo ». C’est une tentative de faire porter à 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 les infrastructures numériques. Le projet ne possède ni accélérateurs, ni usines, ni centres de données, ni régions cloud. Il définit les contrats que ses membres et d’autres implémenteurs peuvent intégrer dans des cartes réseau, des ASIC de commutation, des systèmes, des pilotes, des bibliothèques et des équipements de test. Son influence ne deviendra réelle que lorsque ces produits indépendants échangeront correctement du trafic en situation de panne, de congestion, de mise à niveau et de mélange 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 s’intitule Joint Development Foundation Projects, LLC, Consortium for HPC/AI/ML Ethernet Series. Cette structure en série place le projet dans la Joint Development Foundation et, plus largement, dans la famille Linux Foundation. Elle offre aux participants un cadre préexistant pour l’adhésion, la gouvernance, la propriété intellectuelle, le financement et les relations externes, sans exiger la création d’une nouvelle société autonome.

Cette structure est importante, car l’UEC est souvent décrit de manière imprécise comme une entreprise, une alliance ou un organisme de normalisation. Ce n’est pas une société commerciale avec actionnaires, capital, valorisation ou comptes 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 promu par ses membres. Il s’agit d’un consortium de développement de spécifications doté d’un cadre juridique et de propriété intellectuelle. Ses documents publics ont vocation à devenir des contrats d’implémentation entre plusieurs entreprises.

L’UEC n’est pas non plus synonyme d’Ultra Ethernet Transport. UET est l’architecture de transport au cœur de la spécification. Les travaux du consortium sont plus vastes : mappage logiciel vers libfabric, sémantique des messages et paquets, hypothèses réseau, options de couche liaison, exigences physiques, gestion, alignement avec le stockage, performance et débogage, conformité et essais. Réduire le projet à « un nouveau protocole RDMA » masquerait précisément l’ambition transversale qui le rend à la fois prometteur et difficile.

L’UEC n’est pas davantage le groupe de travail IEEE 802.3. IEEE 802.3 élabore les normes essentielles de couche MAC et physique Ethernet selon son propre processus formel. L’UEC dépend de cet écosystème et entretient une liaison avec lui, sans le remplacer. La même limite vaut pour les mécanismes IETF sous-jacents à UET, notamment IPv4, IPv6 et Explicit Congestion Notification ; pour l’écosystème OpenFabrics qui maintient libfabric ; et pour les organisations actives dans le stockage, le matériel ouvert et les interconnexions d’accélérateurs.

Le site du projet a employé une formulation suggérant le statut d’organisation internationale de normalisation. La description la plus sûre et la mieux étayée est celle d’une organisation internationale de développement de spécifications sous l’égide de la JDF. Rien ne permet d’affirmer qu’elle appartient à l’Organisation internationale de normalisation, que ses documents sont des normes ISO ou qu’ils disposent d’un numéro ISO. Cette nuance n’est pas cosmétique : elle permet de comprendre d’où vient l’autorité du projet, comment la participation fonctionne et quelles obligations juridiques peuvent peser sur les implémenteurs.

L’UEC doit donc être évalué selon son rôle réel. Il coordonne concurrents et opérateurs autour d’une conception technique commune. Il publie des spécifications, administre des groupes de travail et des déclarations de brevets, développe des documents de conformité et entretient des relations avec des organisations adjacentes. Mais aucune déclaration ne suffit à rendre un produit interopérable ou à imposer l’adoption au marché.

La coalition fondatrice de neuf organisations

Le consortium a été annoncé le 19 juillet 2023 par neuf organisations situées à différents niveaux de la chaîne d’approvisionnement IA et HPC : AMD, Arista Networks, Broadcom, Cisco, Eviden, alors lié à Atos, Hewlett Packard Enterprise, Intel, Meta et Microsoft. Cette diversité constituait dès l’origine un atout stratégique. Un transport conçu uniquement par des fournisseurs de commutateurs risquerait de négliger les contraintes applicatives et de terminaison. Une architecture dominée par les fabricants d’accélérateurs pourrait être étroitement optimisée pour un seul écosystème.

Un projet exclusivement mené par des clouds manquerait peut-être de l’expertise silicium, optique et système nécessaire à la transformation d’une architecture en produits.

AMD apportait processeurs, accélérateurs et réseau de terminaison. Arista et Cisco apportaient la commutation Ethernet à grande échelle et l’expérience opérationnelle. Broadcom contribuait aux ASIC de commutation, aux cartes réseau et aux SerDes à haut débit. HPE et Eviden apportaient les systèmes HPC et l’histoire des interconnexions spécialisées. Intel contribuait par les processeurs, Ethernet et le logiciel. Meta et Microsoft représentaient des opérateurs hyperscale directement intéressés par une meilleure utilisation des grands clusters IA et une moindre dépendance envers un fournisseur intégré unique.

La coalition réunissait aussi des intérêts commerciaux concurrents. Ses membres vendent des cartes réseau, des ASIC, des systèmes, de la capacité cloud, des optiques, des logiciels et du support. Certains détiennent des portefeuilles de brevets potentiellement indispensables à l’implémentation. Certains profitent d’une norme multi-fournisseurs étendue, tout en pouvant monétiser des fonctions propriétaires différenciées. Le consortium ne supprime donc pas la concurrence.

Il crée un espace où les concurrents conviennent d’interfaces minimales tout en continuant de se distinguer par la qualité de mise en œuvre, les performances, l’intégration et les conditions commerciales.

L’interconnexion Slingshot de HPE fournit un exemple utile de filiation technique. Slingshot est une fabrique HPC compatible Ethernet, dotée de fonctions de routage adaptatif et de gestion de congestion. Des commentaires associés à HPE ont indiqué qu’une spécification « HPC Ethernet » avait été apportée à l’UEC et ont estimé qu’une grande partie d’UET provenait d’idées de transport Slingshot. Le pourcentage exact n’a pas été vérifié indépendamment et ne doit pas être présenté comme une comptabilité du consortium. Le point plus large est solidement étayé : l’UEC n’est pas parti d’une feuille blanche.

Il a puisé dans l’expérience de production du HPC, du cloud, du RDMA et d’Ethernet.

Ce mélange de systèmes antérieurs explique aussi pourquoi le mot « ouvert » doit être défini avec précision. La spécification ratifiée est téléchargeable publiquement et l’architecture vise des implémentations multi-fournisseurs. Mais le projet est aussi un lieu où les membres apportent connaissances existantes, brevets et feuilles de route produits. L’ouverture du document ne supprime pas les conditions économiques et juridiques attachées à la technologie.

Une série juridique conçue pour la collaboration entre concurrents

Le modèle de la Joint Development Foundation donne à l’UEC une enveloppe formelle sans en faire une société opérationnelle classique. Le projet dispose de son identité, de son périmètre, de ses catégories de membres, de son Steering Committee, de ses groupes de travail et de ses obligations de propriété intellectuelle. L’enveloppe JDF fournit l’infrastructure juridique et à but non lucratif, et peut détenir les actifs et accords du projet. Ce modèle réduit le coût de création d’un consortium et offre aux concurrents un processus reconnu pour collaborer.

Le Steering Committee gouverne le projet. Ses responsabilités documentées comprennent la coordination des groupes de travail, l’approbation des nouveaux membres, la gestion des actifs et des finances, la désignation ou le remplacement du président, le suivi des progrès et le contrôle de la publication et des marques du projet. Le consensus est privilégié. En cas d’échec, la charte prévoit une majorité qualifiée des trois quarts parmi les participants éligibles qui satisfont aux exigences de présence. Des appels écrits peuvent être adressés au président.

Le premier président était Brad Booth de Meta. La spécification 1.0.3 actuelle cite J Metz d’AMD comme président, Barry Davis de HPE comme vice-président, Hugh Holbrook d’Arista comme président du Technical Advisory Committee et Puneet Agarwal de Marvell comme vice-président du TAC. Paul Congdon y figure comme éditeur de la spécification. Le document identifie également des responsables et auteurs pour les travaux physiques, liaison, transport et logiciel. L’ordre du jour du sommet 2026 mentionne d’autres responsables opérationnels.

Ces rôles de sommet ne remplacent pas nécessairement les titres formels de la spécification ; les documents publics ne fournissent pas un organigramme actuel complet.

La charte reconnaît trois catégories : Steering, General et Contributor. Les membres Steering participent à la gouvernance et désignent normalement un représentant au Steering Committee. Les membres General peuvent travailler dans tous les groupes techniques mais ne siègent pas au comité. Les membres Contributor participent à des groupes sélectionnés et n’ont pas de droit de vote dans les décisions à supermajorité. La page publique d’adhésion commercialise les niveaux General et Contributor, avec des tarifs annuels de 20 000 et 5 000 dollars américains, auxquels s’ajoute l’adhésion Linux Foundation.

Elle n’explique pas clairement le parcours d’admission ni le tarif actuel du niveau Steering.

Cette différence de pouvoir formel est importante. Une base de membres large peut fournir expertise et portée d’implémentation, mais la gouvernance n’est pas distribuée de manière égale. Les grandes entreprises capables d’occuper des positions Steering, d’affecter des ingénieurs à plusieurs groupes et de maintenir des programmes de brevets et de produits disposent d’une influence pratique supérieure à celle des petits membres Contributor. Les non-membres peuvent télécharger la spécification finale mais ne voient pas tout le processus de brouillon et ne participent pas à égalité.

Les informations internes ne sont pas considérées comme des secrets d’entreprise ordinaires, mais les membres ne peuvent pas rendre publics les brouillons avant approbation du comité compétent. Cette règle facilite la discussion entre concurrents sans signaler trop tôt des orientations au marché. Elle empêche aussi les observateurs externes de connaître les propositions rejetées, les votes, les préoccupations provisoires d’implémentation ou les négociations qui ont conduit aux fonctions optionnelles. La spécification finale est ouverte ; le chemin qui y mène ne l’est que partiellement.

Du lancement à quatre groupes à une spécification de 573 pages

La structure publique initiale de 2023 reposait sur quatre groupes de travail : logiciel, transport, liaison et physique. Cette séquence reflétait l’ambition de bout en bout du projet. L’adhésion ne s’est pas ouverte comme une liste de diffusion publique sans restriction. Plus de 200 organisations avaient manifesté leur intérêt, et le consortium a échelonné l’intégration tout en exigeant une formation au processus et aux règles antitrust. Cette prudence était compréhensible, car les participants sont des concurrents directs sur plusieurs marchés et discutent d’exigences communes de produits et de protocoles.

En décembre 2023, l’UEC indiquait compter environ 40 entreprises et plus de 300 personnes. Il avait créé un Technical Advisory Committee et élargi sa structure à huit groupes. Le TAC devait assurer la cohérence architecturale : un transport ne pouvait supposer un comportement de commutateur, une méthode de signalisation ou une API qu’un autre groupe n’avait pas accepté. En mars 2024, le consortium annonçait 55 entreprises et plus de 750 participants actifs et publiait une présentation beaucoup plus claire de son architecture prévue.

Cette mise à jour de mars introduisait les idées principales qui ont ensuite rejoint la spécification normative : libfabric comme API orientée logiciel, répartition des paquets, ordre flexible, plusieurs modes de livraison, contrôle de congestion côté émetteur et récepteur, ECN, troncature des paquets, Link Layer Retry, contrôle de flux par crédits facultatif, sécurité de transport et futures opérations collectives dans le réseau. Elle confirmait également qu’UET pouvait fonctionner sur des commutateurs Ethernet existants, des équipements enrichis pouvant apporter des performances supplémentaires.

La portée institutionnelle a grandi en parallèle. L’UEC a déclaré 1 193 participants actifs en juillet 2024 et 97 organisations membres en août. Il s’agit de chiffres datés dont les définitions ne sont pas entièrement publiques. Ils ne doivent pas être additionnés mécaniquement avec des annonces ultérieures. En 2025, l’UEC a indiqué l’arrivée de 27 nouvelles entreprises, mais les départs, fusions et périodes de référence qui se chevauchent empêchent d’en déduire un total actuel exact. Le site précise lui-même que tous les membres ne sont pas affichés.

La version 1.0 d’Ultra Ethernet Specification a été publiée le 11 juin 2025. À partir de ce moment, l’UEC n’était plus seulement une feuille de route, mais une référence d’implémentation publique. La version 1.0.1, publiée en septembre, a corrigé l’algorithme source du contrôle de congestion par crédits récepteur et des problèmes éditoriaux. La version 1.0.2 est arrivée en janvier 2026 et a corrigé des algorithmes de congestion, mais deux documents officiels divergent entre le 21 et le 28 janvier. Cette incohérence doit être conservée plutôt que résolue silencieusement.

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 signalisation à 200 Gbit/s par voie ainsi qu’une capacité de négociation booléenne. Ses notes de version identifient aussi des corrections obligatoires concernant la livraison des paquets, les crédits de congestion, Link Layer Retry et les ensembles ordonnés de contrôle physique, ainsi que des clarifications sur la sécurité de transport, les opérations atomiques et les paquets tronqués.

La distinction entre correction obligatoire et clarification éditoriale est essentielle : certaines modifications changent le comportement conforme et imposent donc une maintenance des implémentations.

Le Member Summit 2026 de Denver a signalé une seconde transition. Son programme portait sur le déploiement, la productisation, la conformité, la gestion, la performance, le débogage, l’intégration du stockage et les tests entre commutateurs et points d’extrémité. Le document architectural existe ; la crédibilité du projet dépend désormais davantage de la capacité des implémenteurs à construire, qualifier, exploiter et mettre à niveau la pile au-delà des frontières organisationnelles.

Une seule architecture sur cinq couches fonctionnelles

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

Au sommet, les frameworks IA, MPI, SHMEM et les bibliothèques collectives interagissent par OpenFabrics Interfaces, en particulier libfabric. Le UET Semantic Services Sublayer traduit les opérations applicatives en transactions de transport. Le Packet Delivery Sublayer décide de la segmentation, de l’ordre, des acquittements et de la reprise. La gestion de congestion contrôle la quantité de données injectée dans la fabrique et leur répartition entre chemins. La sécurité de transport facultative protège les échanges de point à point. IPv4 ou IPv6 assure le transfert réseau.

Ethernet fournit la liaison, avec troncature, Link Layer Retry, Credit-Based Flow Control et négociation de fonctions en option. La couche physique spécifie les statistiques et la signalisation à 100 ou 200 Gbit/s par voie.

Cette structure préserve des éléments essentiels du réseau existant. L’UEC ne définit pas un remplacement du routage IP. Il attend des commutateurs qu’ils assurent l’ECMP conventionnel et ECN. Une grande partie de l’intelligence reste dans les Fabric Endpoints, qui manipulent l’entropie, maintiennent l’état du transport, placent les données et réagissent aux signaux de congestion. Des commutateurs enrichis peuvent ajouter des fonctions, mais le modèle n’oblige pas à remplacer toute la fabrique avant de transporter UET.

Cela crée un avantage de migration et un problème de classification. Un déploiement peut utiliser des points d’extrémité UET sur Ethernet conventionnel avec ECMP et ECN. Un autre peut ajouter troncature, reprise de lien, crédits par canal virtuel, télémétrie avancée et futures opérations dans le réseau. Les deux peuvent être qualifiés d’Ultra Ethernet alors que leurs performances, caractéristiques de reprise et complexité opérationnelle diffèrent sensiblement.

L’approche sur cinq couches rend aussi les échecs plus difficiles à isoler. Un mauvais résultat peut venir du mappage applicatif, de la machine d’état du point d’extrémité, des paramètres de congestion, de la configuration des files, du mappage DSCP, de l’optique, du firmware ou du système de sécurité. Faire passer des paquets ne suffit pas. Le système doit préserver la sémantique et les performances attendues à grande échelle, en trafic mixte, pendant les pannes et lors des changements de version.

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

L’UEC retient libfabric 2.0 comme API nord de référence pour les points d’extrémité conformes. Ce choix rattache le projet à un écosystème logiciel existant du HPC et des réseaux avancés au lieu d’exiger de chaque framework l’adoption d’une nouvelle interface propriétaire. Libfabric représente déjà les fabriques, domaines, points d’extrémité, files d’achèvement, files d’événements, vecteurs d’adresses, régions mémoire, messages, opérations mémoire distantes et opérations atomiques. L’UEC mappe et contraint ces concepts 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 d’accélérateurs peuvent conserver des abstractions familières alors que le fournisseur sous-jacent change. En principe, une application peut demander une opération sans connaître la marque de la carte réseau qui assure la livraison ni le silicium qui commute les paquets. C’est l’un des mécanismes principaux par lesquels un transport commun pourrait créer un véritable choix de fournisseurs.

L’abstraction ne garantit pas des implémentations équivalentes. Les fournisseurs peuvent offrir des tailles d’injection, des limites scatter-gather, des nombres de points d’extrémité, des opérations atomiques, des techniques d’enregistrement mémoire, des comportements d’achèvement, des accélérations matérielles et des fonctions de sécurité différents. Une bibliothèque compilée pour la même API peut donc rencontrer des limites de capacité ou de performance distinctes. L’achat et la qualification logicielle exigent davantage qu’une case « libfabric pris en charge ».

La couche logicielle porte également la sémantique des tâches et de l’autorisation. Les systèmes IA et HPC exécutent souvent de nombreux jobs sur une infrastructure partagée, chacun avec ses processus, ses régions mémoire et ses limites de sécurité. La spécification doit identifier quel point d’extrémité appartient à quelle tâche, quels tampons peuvent être accessibles, comment une opération distante est appariée et comment les informations d’achèvement ou d’erreur reviennent au logiciel.

Ces décisions déterminent si le réseau rapide est réellement utilisable par l’ordonnanceur, le runtime et l’application, plutôt que seulement impressionnant 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 générale : l’architecture UEC est assemblée à partir de composants gouvernés ailleurs. L’UEC peut définir la manière dont son transport se mappe sur libfabric, mais il doit se coordonner avec les mainteneurs et utilisateurs de l’API. Des dépendances comparables existent avec Ethernet IEEE, les mécanismes IETF, les organisations de stockage et les systèmes d’exploitation des fournisseurs.

Fabric Endpoints et profils de charge

Un Fabric Endpoint, ou FEP, est le point logique où UET se termine. Il relie une instance de système d’exploitation à une ou plusieurs fabriques isolées et peut inclure un fournisseur en espace utilisateur, un pilote noyau, un transport sur carte réseau ou accélérateur, un système d’enregistrement mémoire, un contexte de sécurité, des files d’achèvement, des vecteurs d’adresses et l’état nécessaire à la livraison et au contrôle de congestion.

Cette conception centrée sur le point d’extrémité permet aux commutateurs de rester principalement des équipements Ethernet et IP reconnaissables. Le FEP choisit les valeurs d’entropie, conserve l’état de paquet et de congestion, place les données dans la mémoire autorisée et interprète acquittements, troncature et autres retours. Cela peut réduire la dépendance envers une intelligence de routage propriétaire dans le commutateur. Cela concentre aussi la complexité dans le silicium de la carte réseau, son firmware, les pilotes et le logiciel.

L’UEC définit trois profils d’implémentation : AI Base, AI Full et HPC. Ce ne sont pas trois réseaux différents, mais des ensembles de fonctions obligatoires. AI Base vise les communications IA courantes avec un coût et une quantité d’état plus faibles. AI Full ajoute notamment les envois différables, l’appariement exact et certaines opérations atomiques de lecture ou de comparaison. Le profil HPC reprend la plupart des capacités AI Full, exclut l’envoi différable et insiste davantage sur l’ordre, les petits messages et la sémantique HPC.

Le système de profils cherche à éviter que chaque produit doive implémenter l’ensemble maximal. Il reconnaît qu’une carte IA de grand volume peut privilégier les échanges collectifs, tandis qu’un point d’extrémité HPC peut exiger un ordre plus fort et davantage d’opérations atomiques. Les profils ne suppriment toutefois pas les options. Un produit peut implémenter des fonctions facultatives au sein d’un profil, et deux produits portant la même étiquette peuvent encore différer sur la sécurité, les améliorations de liaison, la capacité et les performances.

La terminologie constitue déjà un signal d’alerte. La spécification 1.0.3 faisant autorité emploie AI Base, AI Full et HPC. Un document de conformité de 2025 utilise AI Base, AI Extended et HPC. L’interprétation la plus solide est qu’« AI Full » est la dénomination actuelle et que le document de conformité est ancien ou incohérent. Tant que le paquet d’essais n’est pas corrigé, les fournisseurs et acheteurs doivent identifier la version de la spécification et le vocabulaire exact derrière chaque revendication.

De l’intention applicative à la livraison des paquets

Dans UET, le Semantic Services Sublayer transporte l’intention applicative. Il définit l’identité des messages, l’adressage des tampons, les opérations avec ou sans tag, l’accès mémoire distant, les opérations atomiques, le comportement d’achèvement, les identifiants de tâche, l’autorisation des tampons, les réponses et les erreurs. Le Packet Delivery Sublayer détermine ensuite comment cette intention devient des paquets et comment ceux-ci atteignent l’autre point d’extrémité.

Pour les modes fiables, les points d’extrémité établissent des Packet Delivery Contexts. Un PDC contient notamment les numéros de séquence, les acquittements, la détection de doublons, le mode d’ordre, les informations de congestion, l’état du sens retour et la classe de trafic. Un PDC correspond à un mode de livraison et une classe de trafic, et plusieurs PDC peuvent exister entre les mêmes FEP.

Cette quantité d’état n’est pas secondaire. Les grands clusters peuvent créer un très grand nombre de relations de communication. Si chacune exige un état de destination important, la mémoire et le coût de recherche deviennent limitants. L’UEC ne force donc pas toutes les opérations dans un seul modèle de connexion. Il définit quatre services aux contrats différents.

Reliable Unordered Delivery, ou RUD, garantit une livraison exactement une fois à la couche sémantique tout en permettant une arrivée désordonnée. Il prend en charge la répartition des paquets 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 selon leurs offsets au lieu d’attendre un tampon de réordonnancement du transport, une longue opération collective peut exploiter plusieurs chemins sans bloquer tous les paquets derrière une seule unité manquante.

Reliable Ordered Delivery, ou ROD, garantit une livraison exactement une fois et dans l’ordre. Il utilise un seul chemin et une seule valeur d’entropie, rejette les paquets hors ordre et repose sur une reprise Go-Back-N à partir du premier numéro manquant. Ce modèle paraît moins avancé que RUD, mais il préserve la sémantique nécessaire aux opérations exigeant un ordre strict. L’UEC traite l’ordre comme une exigence de l’application plutôt que comme un coût imposé à tous les transferts.

Reliable Unordered Delivery for Idempotent Operations, ou RUDI, effectue un autre compromis. Il assure une livraison au moins une fois et autorise les doublons, ce qui réduit l’état ordinaire de séquence et d’acquittement à la destination. Il peut convenir à certains mouvements de mémoire distante suivis d’une barrière séparée. Il devient dangereux s’il est mal appliqué : la couche paquet ne déduit pas si une opération est idempotente. Le logiciel doit le savoir. Employer RUDI pour une opération non idempotente peut rendre l’état applicatif invalide.

Unreliable Unordered Delivery, ou UUD, fournit des datagrammes best effort sans garantie normale de fiabilité ou d’ordre. Il appartient au même cadre sémantique mais n’assume pas les mêmes exigences de contrôle de congestion que RUD et ROD. Les applications doivent éviter de nuire au trafic contrôlé lorsqu’UUD partage les mêmes files ou classes.

Ces quatre modes révèlent une philosophie centrale : le réseau doit exposer plusieurs mécanismes afin que le logiciel aligne le coût du transport sur la sémantique de l’opération. Le bénéfice est l’efficacité. Le prix est une surface d’implémentation et d’essai plus grande, avec davantage de combinaisons incompatibles possibles.

Répartir les paquets : utiliser toute la fabrique plutôt qu’un chemin chanceux

L’ECMP conventionnel fixe souvent un flux entier sur une seule route par hachage. Dans une large fabrique Clos, cela crée une loterie : plusieurs flux lourds peuvent se rencontrer sur les mêmes liens alors qu’une capacité équivalente reste libre ailleurs. Un long transfert IA peut être limité par ce mauvais tirage pendant toute sa durée.

UET modifie l’entropie au niveau de chaque paquet. L’émetteur peut utiliser des dizaines ou des centaines de valeurs, ce qui laisse aux mécanismes ECMP existants la possibilité de répartir les paquets entre plusieurs chemins. Le Packet Delivery Sublayer fournit la séquence, le Congestion Management Sublayer choisit l’entropie ou le chemin, les commutateurs appliquent leur hachage normal, et le retour indique à l’émetteur quelles valeurs semblent congestionnées.

Cette répartition n’est praticable que parce que les autres composants la supportent. Les paquets peuvent arriver dans le désordre. RUD peut placer les données directement au lieu d’attendre un réordonnancement complet. La retransmission sélective ne récupère que ce qui manque. Les signaux de congestion réduisent l’usage des chemins difficiles. Il ne s’agit donc pas d’une simple astuce d’équilibrage, mais d’un modèle de transport construit autour de la diversité des chemins.

L’UEC n’exige pas que chaque commutateur exécute un algorithme propriétaire de routage adaptatif. Les implémentations de base peuvent utiliser une sélection pseudo-aléatoire ou en rotation sur l’ECMP standard. Les points d’extrémité plus avancés peuvent associer ECN, latence ou troncature à certaines valeurs d’entropie et éviter les chemins problématiques. Un routage adaptatif spécifique à un fournisseur peut coexister avec UET, mais il n’est pas l’unique source de conscience du chemin.

La promesse est une meilleure utilisation et une latence de queue plus faible. La question ouverte est la cohérence avec laquelle différents points d’extrémité interprètent le retour et la manière dont la répartition interagit avec les tampons, le désordre, les pannes et les trafics mixtes. Un algorithme efficace dans un laboratoire homogène peut se comporter autrement dans une grande fabrique composée de plusieurs générations de commutateurs. Les preuves indépendantes et multi-fournisseurs restent limitées.

Trois mécanismes de congestion pour trois goulets différents

L’UEC ne définit pas un algorithme universel. Il distingue la congestion dans le cœur du réseau, l’incast au récepteur et les limites de tampon du point d’extrémité.

Network-signal Congestion Control, ou NSCC, est piloté par la source. L’émetteur maintient une fenêtre de congestion, estime les octets en vol et ajuste cette fenêtre selon les acquittements, NACK, délais, latence et signaux du réseau comme ECN. Il coordonne la fenêtre avec le multipath au niveau du paquet. L’UEC soutient qu’une fenêtre cesse naturellement d’admettre des données lorsque les paquets ne quittent plus le réseau, alors qu’un contrôleur purement basé sur le débit peut mal interpréter un retour absent.

Il s’agit de l’argument architectural du consortium, pas d’une preuve indépendante que toute implémentation NSCC surpasse DCQCN ou d’autres contrôles RoCE. Les résultats dépendent des détails de l’algorithme, du marquage des commutateurs, de la topologie, du trafic et des paramètres. « Utilise NSCC » n’est donc pas une revendication de performance suffisante.

Receiver-credit Congestion Control, ou RCCC, cible l’incast. Lorsque de nombreuses sources envoient simultanément vers une destination, le dernier lien peut devenir le goulet alors que le cœur n’est pas congestionné. Le récepteur suit la demande, distribue des crédits, cadence l’arrivée agrégée et adapte la fenêtre implicite de chaque source selon la concurrence. RCCC peut fonctionner avec NSCC, car la surcharge du récepteur et la congestion du cœur sont différentes.

Transport Flow Control, ou TFC, emploie aussi des crédits mais pour des services point à point disposant de petits tampons et tolérant mal la perte. Son objectif est d’empêcher directement le débordement. Il peut être utilisé avec ou sans multipath. Confondre tous les mécanismes de crédit masquerait les domaines de panne distincts qu’ils contrôlent.

La spécification attend ECN dans toute la fabrique et pose des hypothèses opérationnelles, notamment le marquage à la sortie plutôt qu’exclusivement à l’entrée. Les points d’extrémité interprètent ECN avec les acquittements, la latence et la troncature. Une configuration cohérente de tous les commutateurs est donc indispensable. Un transport peut être correctement implémenté et donner de mauvais résultats dans une fabrique mal configurée.

L’historique de maintenance montre la difficulté. La version 1.0.1 a corrigé l’algorithme source RCCC. La 1.0.2 a corrigé des cas de gestion de congestion. La 1.0.3 a corrigé des interactions entre crédits et Link Layer Retry. Ces corrections sont normales pour une spécification vivante, mais elles prouvent aussi que crédits, retransmissions et chemins interagissent de manière subtile. Les opérateurs devront maintenir une discipline de version et des tests de régression, pas seulement une conformité initiale.

Troncature des paquets et reprise précise après perte

La troncature change ce que fait un commutateur capable lorsqu’il ne peut conserver un paquet entier. Au lieu de jeter la trame sans information, il retire tout ou partie de la charge utile, conserve suffisamment d’en-tête et de métadonnées pour identifier le paquet, le marque comme tronqué et transmet cette notification réduite au récepteur. Celui-ci peut alors signaler précisément les données manquantes à l’émetteur.

Cette information est plus riche qu’un marquage ECN. ECN indique qu’une congestion a été rencontrée ; la troncature identifie un paquet dont la charge utile n’a pas survécu. Avec RUD et la retransmission sélective, elle peut accélérer la reprise sans attendre un timeout ni retransmettre une longue séquence pour une seule perte.

La fonction de commutation est facultative, mais les points d’extrémité conformes doivent recevoir et interpréter les paquets tronqués selon les exigences applicables. Cette asymétrie autorise le déploiement sur des commutateurs conventionnels tout en donnant aux fabriques enrichies un retour plus précis. Elle crée aussi un problème de mise à niveau. Un réseau partiellement modernisé devra peut-être limiter la troncature selon les chemins, profils ou topologies afin que tous les récepteurs la comprennent.

L’UEC définit également des classes différenciées 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 des commutateurs et points d’extrémité ainsi que les niveaux de priorité. La spécification ne fournit pas un système universel de gestion de ce mappage. Une erreur peut affamer le trafic de contrôle, déformer le retour de congestion ou mettre les paquets de reprise en concurrence avec les flux qu’ils doivent réparer.

La troncature illustre le défi global du projet. Le protocole peut définir le comportement sur le fil, mais le résultat dépend des files, de la logique de terminaison, de la télémétrie, de la configuration et de la gestion des pannes. L’interopérabilité est une propriété du système, pas seulement du format de paquet.

Reprise de liaison, crédits et négociation de fonctions

Link Layer Retry, ou LLR, tente de récupérer une corruption sur un lien physique avant la réaction du transport de bout en bout. Un pair détecte une rupture de séquence ou une trame corrompue, envoie un NACK de liaison et provoque la relecture de la trame depuis un tampon local. Si la reprise réussit rapidement, le transport peut éviter une retransmission plus longue.

La valeur potentielle augmente avec le débit par voie et la densité de ports. Des erreurs optiques ou électriques occasionnelles peuvent autrement produire un retard disproportionné dans une tâche synchronisée. LLR ajoute toutefois état de séquence, tampons de relecture, messages de contrôle, fenêtres de rejet et nouveaux modes de panne. Il doit aussi coexister avec les mises à jour de crédits et les réinitialisations. La version 1.0.3 a corrigé plusieurs cas limites, dont une course entre les informations CBFC et LLR.

Credit-Based Flow Control, ou CBFC, fonctionne par canal virtuel au niveau de la liaison. Il indique à l’émetteur la capacité de réception restante et peut offrir un contrôle plus granulaire que la pause par priorité. L’UEC le présente comme un moyen de créer un comportement sans perte maîtrisé sans exiger que tous les déploiements UET soient globalement lossless. CBFC est facultatif, et UET doit fonctionner sur des réseaux best effort.

CBFC n’est pas un autre nom de Priority Flow Control. Les mécanismes diffèrent par leur signalisation et leur granularité, même s’ils cherchent tous deux à éviter le débordement. CBFC exige néanmoins une configuration cohérente et la livraison correcte de ses propres trames de contrôle. Les crédits locaux peuvent interagir avec les fenêtres de bout en bout et les crédits du récepteur, produisant plusieurs boucles de régulation imbriquées.

L’UEC utilise une négociation basée sur LLDP pour découvrir les fonctions optionnelles et empêcher un côté d’activer une capacité absente chez son voisin. La négociation doit tenir compte des profils, canaux virtuels, mappages DSCP et priorité, réinitialisations, mises à niveau et combinaisons partielles. La version 1.0.3 a ajouté une capacité de négociation booléenne, renforçant l’importance d’un accord explicite sur chaque lien.

Ces options créent une trajectoire depuis Ethernet de base vers une fabrique enrichie, mais aussi une matrice que le langage commercial peut dissimuler. Un commutateur peut transporter UET correctement sans troncature, LLR ni CBFC. Un autre peut les prendre en charge uniquement dans certaines versions ou certains modes de port. Un dossier de déploiement crédible doit donc décrire l’ensemble exact de fonctions, pas seulement citer 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 1.0 était centré sur 100 Gbit/s par voie. La version 1.0.3 a ajouté 200 Gbit/s par voie. Cette évolution aligne la spécification avec une nouvelle génération de liaisons à plus forte densité, mais elle ne prouve pas que tous les produits UEC supportent immédiatement ce débit.

Les travaux PHY couvrent également les statistiques de correction d’erreurs, les taux de mots de code corrigés et non corrigibles, les ensembles ordonnés de contrôle, le reporting de qualité de liaison et l’interaction entre erreurs physiques et LLR. Ces détails comptent parce que les décisions de reprise dépendent de ce que les couches basses peuvent observer et signaler.

À des débits supérieurs, la frontière entre optiques, SerDes, FEC, reprise locale et retransmission de transport devient économiquement importante. Un FEC plus fort peut réduire les erreurs résiduelles au prix de latence et d’énergie. LLR peut récupérer plus vite une corruption locale mais exige des tampons et de l’état. La reprise de bout en bout est plus simple dans le réseau, mais peut gaspiller davantage de temps. L’UEC tente de définir la coopération entre ces couches plutôt que de laisser chaque fournisseur optimiser seul.

L’ajout des voies 200G montre aussi que la cible bouge. Les implémenteurs de la version 1.0 doivent préserver la compatibilité tout en préparant de nouvelles capacités physiques. Les équipements de test, firmwares et systèmes de gestion doivent distinguer ce qui est pris en charge sur chaque port. Les acheteurs ne doivent pas déduire le débit de voie d’une revendication UEC générique.

Sécurité de transport de bout en bout facultative

Le Transport Security Sublayer, ou TSS, fournit une protection facultative entre points d’extrémité. Son modèle de menace ne suppose pas les commutateurs dignes de confiance. Il peut assurer confidentialité, intégrité, protection contre le rejeu, isolation des tâches, domaines sécurisés, clés de groupe, rotation des clés et intégration avec des racines matérielles de confiance.

La conception utilise des domaines sécurisés dont les membres partagent un contexte cryptographique. Des identifiants, numéros d’association, époques, identités de source sécurisée et mécanismes de dérivation doivent permettre une échelle supérieure à celle d’une session indépendante pour chaque paire de points d’extrémité. C’est nécessaire lorsque les populations d’accélérateurs et l’appartenance aux jobs changent rapidement.

Le protocole ne constitue qu’une partie du système de sécurité. Un opérateur doit gérer les autorités de clés, certificats ou autres racines de confiance, l’appartenance des tâches, la distribution et la révocation, les changements d’époque, la reprise des points d’extrémité, la cryptographie matérielle et la télémétrie. Un réseau peut être conforme à un profil sans activer chaque fonction TSS. « Conforme UEC » ne signifie donc pas automatiquement chiffré.

Le caractère facultatif reflète des hypothèses de déploiement différentes. Une fabrique dédiée et physiquement contrôlée peut privilégier la performance et s’appuyer sur des contrôles environnementaux. Un cloud multi-tenant peut exiger une isolation forte et une protection cryptographique. Les profils et la procédure d’achat doivent rendre cette différence visible.

Le risque le plus grave n’est pas seulement le surcoût du chiffrement. Il est lié aux défaillances du cycle de vie à grande échelle : appartenance périmée, révocation tardive, époques incohérentes, reprise après panne ou incapacité à prouver quelle tâche peut accéder à quelle mémoire. Ces problèmes relient la sécurité de transport aux systèmes d’orchestration et d’identité extérieurs au cœur de la spécification.

Ce que signifie aujourd’hui « conforme UEC »

L’UEC a commencé à publier des documents de conformité avec la version 1.0, mais le système public ne constitue pas encore un régime mature de certification indépendante. Le paquet disponible est conçu principalement pour l’auto-attestation par les implémenteurs. Des matrices relient les exigences aux profils, et des recommandations de banc d’essai décrivent des configurations de points d’extrémité et de commutateurs. Aucun registre public complet n’a été identifié dans lequel une autorité indépendante consignerait les réussites et échecs de produits soumis à un programme UEC exhaustif.

La distinction est essentielle, car plusieurs types de revendications circulent. Un produit peut avoir été conçu autour de fonctions UEC en développement. Il peut implémenter certains comportements sur le fil. Il peut prendre en charge un profil, ou une partie d’un profil, dans une version logicielle précise. Un fournisseur peut affirmer une conformité complète. Un laboratoire peut générer du trafic UET à travers un commutateur. Aucune de ces affirmations n’équivaut automatiquement à une certification indépendante, multi-fournisseurs et de bout en bout.

Les recommandations de banc d’essai sont utiles mais volontairement limitées. Elles fournissent des topologies et contrôles de bonne pratique plutôt qu’une qualification complète du système. Elles excluent ou ne couvrent pas entièrement l’interopérabilité générale, les performances, le stress, l’échelle et le cycle de vie des API. Elles ne prouvent pas le comportement en trafic mixte UET/RoCE, pendant des mises à niveau partielles, des pannes répétées, dans de grands domaines de clés ou aux nombres de points d’extrémité les plus ambitieux.

L’incohérence entre AI Full et AI Extended montre également pourquoi la conformité doit être rigoureusement versionnée. Un acheteur doit demander quelle spécification, quel niveau de correction, quel profil, quelles fonctions optionnelles, quels modes de liaison et quelles fonctions de sécurité sont couverts. Il doit aussi savoir si la preuve vient d’un test interne, d’une démonstration bilatérale, d’un événement du consortium ou d’un laboratoire indépendant.

L’étape suivante crédible serait un ensemble de tests publics liés à des versions exactes, des plugfests multi-fournisseurs, des résultats administrés indépendamment, y compris les échecs, et un registre distinguant points d’extrémité, commutateurs, logiciel et systèmes complets. D’ici là, « conforme UEC » doit être le début de l’enquête, pas sa conclusion.

Un document ouvert assorti d’obligations de brevets RAND

La spécification 1.0.3 est téléchargeable publiquement et distribuée sous licence Creative Commons Attribution-NoDerivatives 4.0. Cette licence autorise la redistribution avec attribution mais pas la diffusion de versions modifiées. Surtout, l’accès au droit d’auteur et l’accès aux brevets sont deux questions séparées.

Les chartes des groupes de travail utilisent généralement un modèle traditionnel fondé sur des licences de brevet raisonnables et non discriminatoires. RAND ne signifie pas nécessairement gratuit. Le terme ne garantit pas un prix unique, n’élimine pas la négociation et n’empêche pas les litiges sur la validité, l’essentialité, la géographie ou les conditions défensives. La position commerciale dépend de chaque brevet déclaré, de l’engagement du membre et de toute licence bilatérale.

L’UEC tient un registre public de déclarations de Necessary Claims. À la date de recherche, des déclarations liées notamment à Broadcom, Microsoft, Huawei, Qualcomm, AMD, HPE, Google et Marvell étaient visibles, y compris des dépôts associés aux futurs travaux 1.1. Le registre améliore la transparence en signalant que les implémenteurs peuvent devoir enquêter sur la propriété intellectuelle avant de construire ou vendre un produit.

Le consortium ne détermine pas si un brevet déclaré est valide, réellement essentiel, enfreint ou disponible à un prix donné. Il ne publie pas non plus une licence commune. Les petits implémenteurs peuvent donc supporter des coûts juridiques et transactionnels que les grands membres absorbent plus facilement. Une spécification publique peut tout de même conduire à un marché concentré si la clarification des brevets, le coût du silicium et les essais sont élevés.

Le cadre de propriété intellectuelle influence aussi les incitations de gouvernance. Les entreprises apportent une technologie pour élargir le marché de leurs produits et pour que leurs capacités existantes soient représentées dans la conception commune. Les déclarations de brevets réduisent les surprises uniquement si elles sont précoces et suffisamment claires. Elles n’éliminent pas le risque que les licences deviennent une barrière après l’adoption de l’architecture.

La description honnête est donc « spécification publiée ouvertement et multi-fournisseurs, avec engagements de brevets RAND », et non « universellement libre de redevances ». Les acheteurs ont besoin à la fois du profil technique et d’un chemin de licence.

La première vague de produits et d’essais

Les preuves d’implémentation sont devenues visibles autour de la version 1.0, mais elles correspondent à des niveaux de maturité différents.

AMD a rendu disponible sa carte Pollara 400 AI en avril 2025 et l’a décrite comme conçue autour de capacités UEC en développement. Pollara est une plateforme programmable importante, montrant que le transport a atteint du matériel commercial. La formulation demeure essentielle : être conçu pour des fonctions UEC évolutives n’est pas équivalent à une certification indépendante de toutes les exigences finales 1.0.3.

Broadcom a annoncé Tomahawk 6 en juin 2025 comme ASIC de commutation à 102,4 Tbit/s doté de fonctions adaptées aux fabriques UEC. En octobre, il a annoncé la carte Thor Ultra 800G et affirmé une conformité complète des fonctions UEC. C’est une revendication significative du fournisseur, mais les preuves publiques ne la transforment pas en certificat indépendant du consortium. L’échantillonnage du produit, la maturité logicielle et le profil exact doivent être distingués.

Nokia et Keysight ont annoncé en octobre 2025 une démonstration de trafic UET de bout en bout à travers les familles de commutateurs Nokia 7220 et 7250 à 800 Gigabit Ethernet. Keysight a fourni la génération et la validation du trafic. Le test montre qu’UET peut traverser des systèmes commerciaux et que les outils de test se développent. Il ne prouve pas un profil complet de points d’extrémité multi-fournisseurs, une échelle de production ni la certification indépendante de toutes les options.

D’autres membres ont décrit des commutateurs, systèmes, logiciels ou plans d’essai liés à l’UEC, et le sommet 2026 a accordé une place importante à la productisation. Les éléments disponibles soutiennent l’idée d’une transition vers l’implémentation. Ils ne permettent pas d’établir le nombre exact de cartes UET expédiées, de commutateurs certifiés, de régions cloud déployées ou de fabriques complètes.

La meilleure lecture de cette vague est celle d’une chaîne de preuves. Une spécification permet la conception. Les annonces de silicium et de cartes montrent l’investissement. Les démonstrations de trafic montrent une partie de l’interopérabilité. Les matrices organisent les exigences. Les rapports de déploiement opérateur montreraient la valeur en exploitation. Des plugfests indépendants et des résultats de production apporteraient la crédibilité plus large qui manque encore.

RoCE, InfiniBand, Slingshot et UALink

L’UEC arrive sur un marché où existent des technologies mûres et des systèmes adjacents. Son argument stratégique n’est pas qu’Ethernet n’a jamais porté du RDMA ni que les fabriques spécialisées ne fonctionnent pas. Il affirme que l’échelle et la synchronisation des charges IA actuelles justifient une nouvelle architecture Ethernet de bout en bout, avec plus de souplesse dans la livraison, l’utilisation des chemins et la congestion.

RoCEv2 est le prédécesseur direct et une technologie largement installée. Il transporte le RDMA sur Ethernet routable et dispose d’un vaste support applicatif et produit. L’UEC critique les déploiements courants pour la fixation d’un flux entier sur un chemin, la reprise Go-Back-N, le réordonnancement au récepteur, le réglage difficile de DCQCN, la dépendance envers Priority Flow Control dans de nombreuses architectures et le comportement sous incast ou rafales collectives. Il s’agit des positions techniques de l’UEC, pas d’une preuve que tous les réseaux RoCE sont médiocres.

La comparaison évolue. Des fournisseurs peuvent ajouter routage adaptatif, répartition des paquets, meilleurs contrôles de congestion ou autres idées UEC à des cartes programmables tout en conservant la compatibilité RoCE. La communication d’AMD autour de Pollara présente déjà RoCEv2 et UEC RDMA comme deux choix sur un matériel programmable. UEC peut donc concurrencer RoCE comme transport complet tout en influençant son évolution.

InfiniBand est la principale alternative spécialisée. Il fournit un écosystème intégré de RDMA, congestion, fiabilité de liaison et gestion, avec une longue expérience HPC. Les travaux 2.0 de l’InfiniBand Trade Association incluent des voies XDR à 200 Gbit/s et une télémétrie actualisée. La différenciation la plus solide de l’UEC n’est pas de prétendre qu’InfiniBand manque de performance, mais d’essayer d’obtenir un comportement IA/HPC à travers la chaîne Ethernet, le routage IP standard et un choix plus large de fournisseurs.

HPE Slingshot occupe une position intermédiaire. Cette fabrique HPC compatible Ethernet, avec routage adaptatif et gestion de congestion, a fourni des antécédents importants à UET. Elle démontre qu’un comportement spécialisé peut être construit sur Ethernet, tout en illustrant la différence entre une plateforme commerciale contrôlée et une spécification industrielle.

UALink est généralement complémentaire. Sa spécification publique 200G vise la connectivité scale-up à faible latence entre accélérateurs dans un pod et décrit jusqu’à 1 024 accélérateurs. UEC 1.0 est principalement une fabrique scale-out entre nœuds via des commutateurs. Un centre de données peut utiliser un lien scale-up dans un pod et UEC entre pods ou nœuds. Les futurs travaux UEC sur le scale-up optimisé et les opérations collectives dans le réseau peuvent rapprocher les frontières et produire soit une convergence, soit une concurrence.

NVIDIA Spectrum-X et les fabriques propriétaires illustrent un autre compromis : une pile intégrée peut optimiser matériel, logiciel et support rapidement, mais accroît la dépendance envers un écosystème. UEC échange une partie de cette intégration contre la promesse d’interfaces communes et de choix. La valeur du compromis dépendra des performances, du support, des brevets, de l’interopérabilité et du coût total, pas de l’ouverture comme simple slogan.

Le problème opérationnel dépasse le protocole

Une spécification de 573 pages peut définir de nombreuses exigences, mais une fabrique de production a encore besoin d’un modèle d’exploitation. La version 1.0 laisse des travaux de gestion importants autour du document normatif. Les opérateurs doivent configurer de manière cohérente profils, classes de trafic, seuils ECN, ensembles d’entropie, options de liaison, clés, firmwares, télémétrie et politiques de panne.

Le trafic mixte complique encore la tâche. Une fabrique peut transporter UET, RoCE, TCP, du stockage, de la gestion et des services UET ordonnés ou non. La répartition des files et l’équité ne sont pas résolues par la seule correction de chaque protocole. Un contrôle de congestion peut bien fonctionner isolément et mal se comporter face à un autre contrôleur utilisant des signaux différents.

La complexité des points d’extrémité est un autre risque structurel. UET y place multipath, placement direct, retransmission sélective, plusieurs modes, contrôle par fenêtre et crédits, réception de paquets tronqués, sécurité et beaucoup d’état. Cela peut augmenter la surface du silicium, la taille du firmware, l’effort de vérification, l’énergie et le nombre de pannes à diagnostiquer. L’intelligence de terminaison permet une chaîne de fournisseurs large, mais rend aussi complexe le composant présent dans chaque serveur.

Les fonctions facultatives créent à la fois différenciation et fragmentation. Un fournisseur peut optimiser AI Base pour ECMP et ECN conventionnels. Un autre peut prendre en charge AI Full, TSS, troncature, LLR et CBFC. Les deux participent au même écosystème, sans garantir les mêmes performances ou la même sécurité. Les matrices de conformité doivent devenir des matrices de capacités opérationnelles.

La maintenance de version sera continue. Les corrections 1.0.1 à 1.0.3 ont touché la congestion, les crédits, la reprise et les paquets. Un grand cluster peut contenir plusieurs versions de firmware de cartes, de logiciels de commutateurs et d’outils de test. Mettre à niveau une couche sans coordonner les autres peut exposer les courses transversales que le consortium cherche précisément à éviter.

Les alliances externes sont donc centrales. OCP relie le transport au matériel et aux systèmes ouverts. OFA et libfabric relient les applications. IEEE 802.3 apporte le processus Ethernet formel. SNIA et NVM Express apportent le stockage et la gestion. Les mécanismes IETF fournissent IP, ECN et d’autres bases. Ces organisations ont des processus et calendriers différents ; la liaison réduit les doublons sans garantir une adoption simultanée.

Le test final est l’infrastructure en fonctionnement. Un document peut définir le comportement, un fournisseur annoncer un produit et un consortium organiser un sommet. Aucun ne remplace un cluster où des points d’extrémité et commutateurs indépendants terminent de vrais jobs sous congestion, panne et mise à niveau, avec des opérateurs capables d’expliquer le résultat.

Pertinence actuelle : de la victoire documentaire à la crédibilité d’implémentation

En juillet 2026, l’UEC avait réalisé plusieurs objectifs incertains au lancement. Il avait formé une large coalition, produit une architecture intégrée sur cinq couches, publié une spécification 1.0 complète, assuré sa maintenance, ajouté les voies 200G, divulgué des déclarations de brevets et suscité des annonces de produits et d’essais. Le projet est actif et son agenda s’est clairement déplacé vers l’implémentation.

Cette progression rend les incertitudes plus importantes. Aucun registre unique ne publie le total actuel des membres et la composition du Steering Committee. Les pages d’adhésion et la charte décrivent différemment l’accès. La direction formelle du TAC n’est pas entièrement réconciliée avec les rôles du sommet. La date 1.0.2 diverge entre documents officiels. Le paquet de conformité emploie une terminologie de profil obsolète. Aucun de ces problèmes ne détruit l’architecture, mais chacun signale la qualité du contrôle documentaire dans un projet où les versions exactes comptent.

Les lacunes les plus importantes concernent l’adoption. L’UEC ne publie ni recensement de déploiement, ni registre indépendant de produits, ni budget autonome, ni comptes audités. Aucune preuve publique n’établit un réseau 1.0 pleinement interopérable à l’échelle maximale visée. Les démonstrations et revendications des fournisseurs sont utiles mais intéressées. Les comparaisons neutres avec RoCE, InfiniBand et les plateformes Ethernet intégrées restent limitées.

L’opportunité demeure considérable. Ethernet est le dénominateur commun des centres de données, et le marché IA peut soutenir de nouvelles générations de cartes, commutateurs, optiques et logiciels. Les opérateurs ont de fortes incitations à éviter la dépendance unique et à améliorer l’utilisation des accélérateurs. Une pile commune pourrait transformer ces incitations en levier d’achat.

Le risque est qu’« Ultra Ethernet » devienne un parapluie pour des sous-ensembles incompatibles. Si le transfert de base fonctionne mais que profils, congestion, sécurité et gestion divergent, la marque peut se diffuser plus vite que l’interopérabilité. Si les licences RAND sont coûteuses ou incertaines, le nombre de fournisseurs peut se réduire. Si RoCE absorbe les idées les plus attractives sans changer de transport, UEC peut influencer le marché sans devenir l’étiquette dominante.

La question décisive n’est plus de savoir si le consortium peut publier une spécification sophistiquée. Il l’a fait. Elle est de savoir si des organisations indépendantes peuvent implémenter les mêmes contrats, obtenir les licences nécessaires, exploiter la fabrique à grande échelle et préserver la compatibilité pendant l’évolution. UEC ne deviendra une infrastructure que dans la mesure où ses affirmations résisteront au code en production.