Des chercheurs d'Alibaba éliminent 95 % des ralentissements réseau

Les dispositifs de contrôle Ethernet inefficaces avec RoCEv2

« Pour fonctionner de manière optimale, ces ressources ont en moyenne besoin d’une latence minimale de 3 à 5 microsecondes et d’une bande passante de 40 à 100 Gbits. Pour y parvenir, le marché a déployé ces dernières années de nouvelles infrastructures réseau très prometteuses, de type RDMA (Remote Direct Memory Access) over Converged Ethernet Version 2 (RoCEv2). Mais nous avons découvert que cette technologie posait des problèmes inédits », explique l’équipe d’Alibaba dans un livre blanc.

Elle cite en exemple la génération, sous certaines conditions, d’une « tempête » de paquets de contrôle, ce qui a pour conséquence de faire dramatiquement chuter la vitesse de circulation des informations utiles. Le principe-même du RoCEv2, qui est de faire converger tous les flux sur les mêmes liens, est également pointé du doigt : les chercheurs ont constaté que mélanger les communications inter-applicatives et celles destinées au stockage, augmentait la latence au-delà de 100 microsecondes sur un cluster de Machine Learning, alors que celui-ci avait été spécifiquement construit pour fonctionner avec une latence de moins de 50 microsecondes.

L’équipe en conclut que les dispositifs de contrôle de congestion (CC) disponibles sur les équipements réseau, et qui ont été conçus avant RoCEv2, ne sont de fait plus adaptés au fonctionnement de cette nouvelle génération d’infrastructure Ethernet. Ces dispositifs, pourtant écrits avec l’arrivée du RDMA, sont connus sous les noms DCQCN et TIMELY.

« Les relevés de contrôle étant en RoCEv2 émis sans rythme particulier, les dispositifs CC existants ne savent plus vraiment quand il faut augmenter ou réduire les débits de tel ou tel flux. Et plus ils monopolisent les équipements pour déterminer le débit idéal, plus ils ralentissent l’ensemble du réseau », indiquent les chercheurs.

Sont aussi cités certains arbitrages qui, selon les conditions, provoquent des files d’attente juste pour déterminer quelle ampleur elles peuvent prendre. Ils pointent enfin la complexité d’ajuster à la main des règles en rapport avec ces problèmes, ce qui présente le risque important d’aboutir à des erreurs de configuration qui aggraveraient encore plus la lenteur des transmissions.

Le principe : utiliser les informations INT des nouveaux équipements

HPCC se propose de prendre plusieurs dispositions pour éviter ces écueils. En particulier, il pose d’autorité une limite de débit par flux, elle est toujours inférieure à la bande passante maximale que supporte un lien.

Également, HPCC utilise désormais trois paramètres indépendants pour calculer en une seule passe le débit optimal d’un flux, notamment les relevés INT (In-Network-Telemetry) qui ont récemment fait leur apparition sur les équipements réseau. Le document n’indique pas de références de switches, mais suggère que tous ceux à base d’ASICs Tofino, de Barefoot, ou Tomahawk3/Trident3, de Broadcom, sont compatibles.

« Cela dit, ce genre de dispositifs n’a pas été simple à implémenter, car nous avons dû trouver le bon équilibre entre la réaction tardive et la surréaction à la congestion d’un lien », précise le document qui parle d’algorithmes qui, dans certains cas, multiplient ou divisent les bandes passantes, dans d’autres les additionnent ou les soustraient.

Dans la pratique, il s’agit d’accoler à chaque paquet d’information en transit sur le réseau des métadonnées de débit qui modifient et sont modifiées par les métriques INT de chacun des switches traversés. Lorsque la machine de destination reçoit ces informations, elle renvoie à la machine expéditrice, au travers d’un petit paquet de contrôle ACK, la valeur finale des métadonnées, afin qu’elle sache avec quel débit envoyer les paquets suivants.

Sans ce dispositif propre à HPCC, la machine expéditrice envoie en rafale ses paquets et ne se rend compte d’une congestion que lorsque les switches, débordés, lui demandent de recommencer les envois. Ou lorsque le dispositif CC de sa carte contrôleur l’alerte sur un risque de congestion.

La subtilité, en revanche, est d’éviter de noyer le réseau sous les paquets de contrôle ACK. Pour y parvenir, HPCC se sert des métadonnées afin de n’envoyer qu’une seule fois le signal ACK correspondant à un segment de données. La taille de ce segment correspond à la quantité de paquets qu’un émetteur peut envoyer entre le moment où il émet un premier paquet et l’instant où il reçoit l’accusé de réception de la part du destinataire (dit temps aller-retour, ou RTT pour Round Trip Transfer).

Selon l ‘équipe, le mérite supplémentaire de HPCC est de ne plus se baser que sur des informations précises, alors que les dispositifs précédents de CC pouvaient croiser diverses statistiques. « Il en résulte que les opérateurs n’ont plus de règles compliquées à écrire, sur la base d’une multitude de paramètres, pour optimiser le réseau », indiquent les chercheurs. Ils préconisent d’ailleurs que les implémentations de HPCC ne fonctionnent qu’en automatique.

Des tests concluants mais pas de date de disponibilité

L’équipe d’Alibaba a atteint des tests concluants en ajoutant les fonctions de HPCC au travers de processeurs reprogrammables FPGA ajoutés à des cartes contrôleurs réseau et via la reconfiguration des puces ASIC qui pilotent les switches.

Sur un équipement de test qui comprend 32 serveurs montés en cluster, HPCC parvient à éviter la création de toute file d’attente quand la charge est de 50 % et limite la latence à 7,3 microsecondes quand cette charge est maximale. Soit un résultat 95 % meilleur qu’avec les dispositifs CC habituels. Dans une configuration avec 320 serveurs, l’équipe indique ne plus avoir constaté de tempête de paquets de contrôle.

Précisons que, dans ce test, les serveurs sont équipés de cartes 100 Gbits/s et sont reliés par groupes de 16 à un switch dont la bande passante est de 400 Gbits/s, avec 32 Mo de mémoire cache dévolus à la file d’attente. Quand le débit global des serveurs dépasse 400 Gbits/s, la mémoire cache se remplit. La congestion survient quand elle est pleine.

Selon les ingénieurs d’Alibaba, même si ces développements ne concernent que les réseaux RoCEv2, ils devraient néanmoins être facilement transposables à d’autres protocoles réseaux à haute vitesse, comme le RDMA-over-Infiniband dans le cadre des supercalculateurs ou, à un plus haut niveau, le NVMe-over-RoCEv2.

La difficulté que pose HPCC est que son algorithme tient pour l’heure dans 12.000 lignes de code à implémenter sur les cartes contrôleurs, là où les dispositifs précédents de CC n’occupaient que 800 à 2000 lignes de code. L’équipe d’Alibaba veut cependant croire que cela ne posera pas de problème sur les nouvelles générations de cartes, plus capacitives.

Pour l’heure, HPCC est à l’état de propositions technologiques adressées aux fabricants d’équipements réseau. Alibaba ne se prononce pas quant à une date de disponibilité dans les produits de série. Il est probable que, en tant que concurrent asiatique d’AWS, Azure et Google, il développe lui-même des solutions pour en équiper en premier son offre de cloud IaaS.