Mises à jour des groupes de travail du consortium UItra Ethernet

Orientations de recherche du consortium UItra Ethernet

Le consortium Ethernet UItra s'engage à améliorer la technologie Ethernet depuis la couche physique, la couche liaison, la couche transport et la couche logicielle. Sur la base d'être compatible avec l'écosystème Ethernet actuel, il améliore les performances de transfert d'Ethernet et s'engage à améliorer les protocoles de communication Ethernet et l'interface des programmes d'application. Il améliore également les capacités de stockage, de gestion, de sécurité et de télémétrie, afin que la technologie Ethernet UItra puisse répondre aux besoins réseau de l'intelligence artificielle et du calcul haute performance.

L'Ultra Ethernet Consortium a identifié le type de réseau sur lequel il faut se concentrer comme étant le réseau de type 2 (réseau back-end) et ne s'oppose pas à son utilisation dans le réseau de type 1 (réseau frontal), mais cela ne réduira pas les performances du réseau de type 2 car il doit s'adapter au Type1.

Réseaux Type1 et Type2

L'UEC détermine des mesures de performances pour chaque type de réseau

Groupes de travail du CUE

L'UEC a initialement créé quatre groupes de travail, à savoir les groupes de travail sur la couche physique, la couche liaison, la couche transport et la couche logicielle, qui ont obtenu des résultats exceptionnels. Récemment, des groupes de travail sur le stockage, la gestion, la compatibilité et les tests, les performances et le débogage ont été créés et viennent de commencer leurs travaux. La figure ci-dessous montre les groupes de travail de l'UEC :

Les quatre groupes de travail de l'UEC

Groupe de travail sur la couche physique

Le groupe de travail sur la couche physique s'engage à améliorer les performances physiques, à réduire la latence et à améliorer la gestion de l'infrastructure physique Ethernet. Il comprend le développement de spécifications de couche physique Ethernet, de caractéristiques de signaux électriques et optiques, d'interfaces d'application et de structures de données. Son objectif est de renforcer les fondations et de garantir qu'Ethernet puisse répondre aux exigences rigoureuses de l'Al et du HPC. Le groupe de travail actuel sur la couche physique s'est engagé à formuler des spécifications PHY pour 100G/Lane et 200G/Lane et a déterminé le type de support 100G/Lane ainsi que le débit et le type pris en charge par PHY. Les spécifications pour 200G/Lane seront déterminées après l'approbation de la norme IEEE P802.3dji.

Le groupe de travail sur la couche physique a introduit plusieurs nouveaux concepts pour la prédiction de la qualité des liaisons : UCR (uncorrigable codeword ratio), MTBPE (le temps moyen entre les erreurs PHY) et MTTFPA (le temps moyen jusqu'à l'acceptation de faux paquets), dédiés à la prévision et à la mesure des erreurs physiques. qualité du lien de couche avec plus de précision.

Groupe de travail sur la couche de liaison

Le groupe de travail sur la couche liaison s'engage à améliorer la fiabilité et l'efficacité de la transmission de la couche liaison et à améliorer les capacités de télémétrie de la couche liaison.

Les principaux axes de recherche de la couche liaison sont :

Fiabilité de la couche de liaison :

Ajoutez une sous-couche LLR à la couche liaison, située entre les sous-couches LLC et MAC CONTROL, pour la retransmission des paquets d'erreur de bout en bout au niveau de la couche liaison.

Contrôle des flux basé sur le crédit :

Prend en charge un mécanisme de contrôle de flux basé sur le crédit de bout en bout au niveau de la couche liaison pour gérer la transmission sans perte de trames entre les liaisons. Le mécanisme CBFC (Credit-Based Flow Control) est utilisé pour remplacer le contrôle de flux PFC. Le récepteur envoie périodiquement de l'espace tampon au homologue et l'expéditeur envoie des messages en fonction de la priorité du message et de la taille du tampon. L'espace tampon peut également être utilisé pour la sélection de routage adaptatif.

Contrôle des flux basé sur le crédit

Amélioration du débit de paquets :

Il s'engage à compresser les en-têtes de messages Ethernet pour augmenter l'efficacité de la transmission des trames. Au cours de l'évolution à long terme d'Ethernet, les en-têtes de messages ont continué à se développer, ce qui a entraîné une efficacité de transmission relativement faible. De nombreux domaines ne sont pas utilisés dans les réseaux informatiques intelligents. Par conséquent, il est impératif de compresser les en-têtes de message et d’améliorer l’efficacité de la transmission des trames.

Il doit y avoir un indicateur dans l'en-tête du message pour indiquer si le message est compressé ou non compressé pour que le message compressé et le message non compressé coexistent dans le réseau. L'expéditeur peut choisir de compresser le message sans affecter la fonction d'origine.

Il existe actuellement plusieurs solutions pour la compression des en-têtes de messages, qui sont en cours de discussion.

Négociation:

Il établit une méthode de négociation pour les paramètres et les caractéristiques de la couche liaison. Plusieurs nouvelles capacités au niveau de la couche liaison, telles que LLR, CBFC et PRI, nécessitent des négociations pour être prises en charge. L'idée principale est d'étendre LLDP et d'ajouter un UEC OUI pour la négociation de nouvelles capacités de couche liaison entre les appareils.

Groupe de travail sur la couche transport

Le groupe de travail UET (UEC transport layer) s'engage à étendre les applications les plus difficiles, à transmettre des messages de manière fiable, à sécuriser la transmission de données et à éviter la congestion du réseau. Son objectif est de résoudre les lacunes de la transmission RoCE et de fournir une transmission à grande échelle efficace, fiable et sécurisée. Le point de terminaison de transport cible atteint 256,000 100,000,000 et le nombre de processus pris en charge atteint XNUMX XNUMX XNUMX.

Les principaux modules de l'UET sont présentés dans la figure ci-dessous :

Principaux modules de l'UET

UET contient trois modules : livraison de paquets, sécurité et sémantique. Les fonctions de chaque module sont les suivantes :

• Sous-couche de livraison de paquets (PDS) :

PDS contient deux modules : fiabilité et gestion de la congestion.

Le module de fiabilité doit répondre à trois exigences clés :

1. Évolutivité extrême
2. Transmission ordonnée des messages
3. Transmission de messages non ordonnée

Le module de fiabilité est conçu avec quatre modes de transmission de messages et chaque mode est utilisé dans un but spécifique pour répondre aux scénarios HPC, Al, ML et autres scénarios d'application. Les quatre modes de transmission des messages sont :

Livraison fiable et ordonnée (ROD) :

Ce mode transmet les messages dans l'ordre et est utilisé pour les applications nécessitant une transmission ordonnée des messages.

Livraison fiable et non ordonnée pour les opérations (RUD) :

Ce mode ne peut transmettre des messages à la couche sémantique qu'une seule fois mais peut tolérer une livraison non ordonnée dans le réseau. La couche de transport fiable doit détecter les messages en double pour garantir que chaque message ne peut être transmis à la couche sémantique qu'une seule fois.

Livraison fiable et non ordonnée pour les opérations idempotentes (RUDI) :

Ce mode est optimisé pour les opérations de lecture et d'écriture de RDMA.

Livraison peu fiable et non commandée (UUD) :

Les messages peu fiables peuvent véhiculer de nombreuses nouvelles sémantiques de l'UET. Les utilisateurs d'UDD n'ont pas besoin d'une transmission fiable et utilisent d'autres méthodes de fiabilité.

Le module de gestion de la congestion est encore à l'étude, y compris la gestion de la congestion et l'équilibrage de charge, et peut effectuer une gestion de la congestion basée sur chaque FEP. Le noyau est le contrôle de flux basé sur le crédit du destinataire. Le contrôle de la congestion définit la taille de la fenêtre et le taux d'injection. L’objectif est de réduire le débit et de limiter les messages pour éviter la congestion au niveau des nœuds intermédiaires et des points finaux. L'équilibrage de charge du chemin définit le chemin choisi par un message spécifique, et ECMP peut être utilisé pour sélectionner le chemin.

• Sécurité des transports :

La sécurité du transport est une priorité absolue dans la conception des UET, avec un cryptage et une authentification en option de toutes les charges utiles de données et de la plupart des en-têtes de transmission.

• Sémantique:

La couche sémantique UET fournit des opérations hautes performances et hautement évolutives, permettant un déploiement spécialisé d'Al et de HPC complet.

La couche sémantique est le pont entre le logiciel utilisateur et le PDS (message Delivery Layer). La couche sémantique définit une série de
opérations, telles que l'envoi, la réception, l'écriture, la lecture, etc. La couche fournit un tri facultatif, y compris divers initiateurs facultatifs et des capacités de notification d'achèvement de la cible.

La couche sémantique fournit une API d'appel sans connexion et doit prendre en charge nativement *CCL, MPI, OpenSHMEM et d'autres API.

Groupe de travail sur la couche logicielle

La couche logicielle favorise l'adoption rapide de l'UEC en utilisant l'API libfabric comme cadre de plan de données grâce à la compatibilité avec diverses bibliothèques de communication actuellement largement adoptées telles que *CCL, MPI et SHMEM. Il définit l'interaction entre divers accélérateurs et FEP, y compris les API d'accélérateur associées. Il définit les mécanismes du plan de contrôle et du plan de données pour les commutateurs, les FEP et les gestionnaires d'agrégation (AM) afin de permettre l'interopérabilité entre les différents fournisseurs d'UEC. Il répond à la nécessité pour UEC de prendre en charge plusieurs profils de charge de travail.

Groupe de travail sur la couche logicielle

Le travail que la couche logicielle doit effectuer pour INC comprend :

• Définir un APL (en langage C) en utilisant la communication de collection d'INC (libfabric).

• Définissez un mécanisme de découverte pour confirmer les capacités de déchargement INC disponibles.

• Définissez l'interface RPC utilisée par ces bibliothèques pour communiquer avec Aggregation Manager (AM). Spécifiez l'interface RPC utilisée pour la communication entre l'AM et le commutateur UEC fournissant les ressources INC.

• Extension OpenConfig pour configurer le FEP des périphériques réseau (configurés par AM) pour le déchargement des communications collectives et la surveillance des performances et des erreurs.

• Comportement des périphériques réseau compatibles INC avec plusieurs profils de fonctionnalités. Guider le développement de protocoles de transmission UEC afin que la technologie INC puisse être facilement appliquée à la mise en œuvre matérielle.