L’intelligence artificielle (IA) et le calcul haute performance (HPC) se développent rapidement grâce aux progrès réalisés dans les domaines du machine learning, du traitement automatique du langage naturel, de l’IA générative, de la robotique et des systèmes autonomes.
Ces innovations reposent sur des modèles d’entraînement distribués à grande échelle, avec des milliards et des milliards de paramètres sur plusieurs GPU. Pendant l’entraînement, les nœuds échangent une quantité astronomique de données et de gradients pour se synchroniser via la fabric Ethernet IA en back-end. Mais la perte de paquets peut gravement perturber cette synchronisation, entraînant des retransmissions ou des blocages de communication, et donc plus de latence, des délais de traitement (JCT) allongés et une utilisation inefficace de ressources GPU coûteuses.
Le défi : les pertes de paquets invisibles dans la fabric IA des datacenters
Le JCT est un indicateur essentiel, et les charges de travail IA modernes, en particulier les tâches d’entraînement et d’inférence à grande échelle, reposent sur une synchronisation rigoureuse entre les clusters. Même la perte d’un seul paquet peut avoir un impact significatif sur les performances et augmenter les coûts opérationnels.
Par exemple, en cas de congestion du réseau, les paquets RoCE v2 peuvent être perdus dans la fabric Ethernet/IP dédiée à l’IA quand les tampons des commutateurs sont saturés. Ces paquets perdus doivent alors être retransmis, ce qui provoque des retards et perturbe le bon déroulement des processus d’entraînement ou d’inférence.
Si l’ECN (Explicit Congestion Notification) signale la congestion en modifiant des bits dans l’en-tête IP, il n’identifie pas les paquets spécifiques perdus à cause de la congestion et qui doivent donc être renvoyés.
La solution : le DCN (Drop Congestion Notification)
Pour répondre à ce problème, Juniper a développé le Drop Congestion Notification (DCN), une nouvelle fonctionnalité de gestion de la congestion disponible dans la version 23.4x100d40 du logiciel Junos OS(TM) Evolved, pour les plateformes Ethernet/IP QFX5240-OD et QFX5240-QD à base de puces Tomahawk 5, offrant 64 ports 800GbE.
En cas de congestion, le commutateur envoie des notifications de perte de paquets en réduisant la charge utile du paquet et en transmettant cette information à l’hôte destinataire via une file prioritaire. Les commutateurs de transit de la fabric réseau reconnaissent ces paquets DCN tronqués et les redirigent vers la file prioritaire.
L’hôte final doit ensuite traiter ces paquets DCN tronqués, identifier ceux qui ont été perdus explicitement à cause de la congestion et demander rapidement leur retransmission à la source.
Les paquets tronqués, toutefois, ne sont pas envoyés dans la mémoire du serveur cible : ils servent uniquement à identifier précisément quels paquets nécessitent une retransmission sélective. Cela permet d’éviter les mécanismes de retransmission standard plus longs qui raccourcissent les délai de traitement global des tâches.
La figure suivante représente une configuration réseau simplifiée où, en cas de forte congestion dépassant les seuils ECN, les paquets qui arrivent au premier commutateur sont tronqués plutôt que supprimés, puis acheminés vers la carte NIC du serveur GPU destinataire. Durant ce processus, les commutateurs de transit peuvent identifier ces paquets tronqués et les transmettre directement via la file d’attente prioritaire. Lorsque le paquet incomplet est reçu par la carte NIC destinataire, celle-ci demande automatiquement la retransmission du paquet complet au serveur source.
Figure 1 : DCN (Drop Congestion Notification)
Dans les commutateurs QFX5240-OD et QFX5240-QD, les paquets DCN sont traités via une file d’attente dédiée, distincte des paquets de données. Cette séparation permet à l’utilisateur de gérer plus efficacement la latence et la bande passante attribuées aux paquets DCN.
Exemples de configuration :
- Configuration permettant de définir le numéro de port UDP L4 personnalisé comme numéro de protocole DCN, que le commutateur utilisera pour identifier les paquets DCN. Cette configuration est INDISPENSABLE pour activer le DCN.
set class-of-service drop-congestion-notification udp-port <0.65535>
- Configuration permettant de définir la file d’attente de sortie pour tous les paquets DCN perdus. Il s’agit d’une configuration globale. Cette file d’attente doit être de type unicast et configurée avec une priorité stricte élevée. Pour des performances optimales, nous vous conseillons de la réserver exclusivement au trafic DCN. Comme pour les autres paramètres CoS, la file d’attente est identifiée à l’aide de la classe de transfert (forwarding-class). Cette configuration est également INDISPENSABLE pour activer le DCN.
set class-of-service drop-congestion-notification forwarding-class <nom de la classe de transfert>
- Pour que l’appareil QFX5240 agisse en tant que nœud de transit DCN, il suffit d’appliquer les deux configurations mentionnées précédemment (protocole et classe de transfert). Dans ce contexte, le terme « transit » fait uniquement référence à l’identification des paquets DCN et à leur transmission dans la file prioritaire. Toutefois, si vous voulez que le commutateur QFX5240 génère des paquets DCN en cas de congestion, vous devez compléter ces paramètres par une configuration DCN spécifique au niveau des ports.
- Configuration permettant d’activer le DCN sur des ports individuels. Si le DCN est activé sur le port, un paquet DCN de notification de perte est envoyé lorsque du trafic DCN entrant sur ce port est perdu dans le MMU à cause d’une congestion.
set class-of-service interface <nom de l’interface de sortie> drop-congestion-notification
- Si l’utilisateur souhaite activer le DCN sur tous les ports, il doit utiliser un caractère générique pour appliquer la configuration ci-dessus.
set class-of-service interface et-* drop-congestion-notification
- La configuration DCN n’est prise en charge que sur une interface physique et sur l’interface AE parent.
set class-of-service drop-congestion-notification forwarding-class dcn
set class-of-service drop-congestion-notification udp-port 13742
1set class-of-service interface et-0/0/0 drop-congestion-notification
Commande d’affichage des statistiques DCN de paquets abandonnés
root@QFX5240# run show interfaces queue et-0/0/0 forwarding-class dcn
Physical interface: et-0/0/0, up, Physical link is Down
Interface index: 1205, SNMP ifIndex: 503
Forwarding classes: 12 supported, 9 in use
Egress queues: 10 supported, 9 in use
Queue: 7, Forwarding classes: dcn
Queued:
Packets : 0 0 pps
Bytes : 0 0 bps
Transmitted:
Packets : 0 0 pps
Bytes : 0 0 bps
Tail-dropped packets : 0 0 pps
Tail-dropped bytes : 0 0 bps
RED-dropped packets : 0 0 pps
RED-dropped bytes : 0 0 bps
ECN-CE packets : 0 0 pps
ECN-CE bytes : 0 0 bps
Conclusion :
Maintenir des performances constantes et des opérations parfaitement synchronisées est essentiel dans les fabrics Ethernet dédiées à l’IA, surtout à mesure que les charges de travail se déploient sur des clusters GPU distribués. Le DCN comble une lacune majeure en offrant une visibilité en temps réel sur les pertes de paquets lors de congestions importantes. En signalant les paquets perdus aux points de terminaison, le DCN accélère la récupération, limite les retards non détectés et permet de préserver les JCT pour l’IA.
En définitive, le DCN fait le lien entre la fabric réseau et les charges de travail IA, ce qui en fait une capacité essentielle pour bâtir une infrastructure IA hautes performances et évolutive.
Pour plus d’informations sur les fonctionnalités IA/ML dans les datacenters, veuillez consulter le guide utilisateur.
