Ça plait bien, le thème du “less” en informatique.
Donc, suite au best seller diskless, le bouc émissaire du jour est TCP, et donc ça va causer tcpless.
Comme entrée en matière, je recommande le brulot It’s Time to Replace TCP in the Datacenter (publié en 2022, amendé en 2023).
L’article est plaisant, sans plus, mais il fournit des sources (ce que promet la lecture de documents touffus écrits en LaTeX, avec au moins une page de citation à la fin, sans URL).
L’auteur propose un nouveau protocole remplaçant TCP : HOMA, dont on reparlera plus tard.
Dans les arguments, il y a deux chouettes buzzwords de Google :
- La taxe datacenter
- L’attaque de la microseconde tueuse
L’article Profiling a warehouse-scale computer “profiler un ordinateur de la taille d’un hangar”,publié en 2015, analyse 3 ans de mesures sur les services Google, qui suit le précepte “le datacenter est l’ordinateur” (on parle de milliers de serveurs), pour découvrir qu’entre 22 et 27% du temps des CPU est utilisé par autre chose que le service métier : bloat rpc, serialisation/deserialisation, compression/décompression, chiffrage/déchiffrage, hashage, allocation mémoire, copies…
Ce surcout est nommé “la taxe datacenter”, et la réponse est de tout miser sur l’accélération matérielle (l’offloading).
L’article Attack of the Killer Microseconds se lamente de la fin de la loi de Moore, les CPU contemporains devraient être 20 fois plus performant alors que le réseau ou le stockage lui a follement progressé. Les ordinateurs ont été conçus pour gérer des millisecondes (réseau, disque dur…) avec un noyau qui a des latences en microsecondes (changement de contexte, interruptions, discussions entre threads …).
Tout allait bien jusqu’à ce que le matériel passe à la microseconde (réseau en 10G et plus, disques SSD puis NVMe…), rendant les latences du noyau agaçantes. La moindre action (pour le code de Google) étant massivement parallélisée (on parle de millier de rpcs pour une recherche), la latence du pire élément du groupe devient la latence du groupe.
Autre point évoqué dans l’article : gérer la parallélisation dans le code est une tannée. Gérer l’asynchrone avec des callbacks cochonne le code, et une simple abstraction comme des threads légers rendent le code plus concis et compréhensible. Un développeur javascript qui a vu l’arrivée de async/await pourra confirmer quel enfer sont les callbacks.
Ce point explique les choix originels de golang, et tourne le couteau dans la plaie async de Rust.
Matériel
Cartes Ethernet
On est maintenant dans l’ère du terabit Ethernet, Intel propose du 100G, NVidia du 400G (qui fait bien fructifier son rachat de Mellanox). Le 800G est spécifié, le 1.6T est en travaux. À partir de 400G, ce sera de l’agrégation (16 brins de 25G pour la première génération de 400G, 2 brins de 200G dans la dernière)
Oui, les plus gros débits consomment plus d’énergie, et il existe une norme qui s’en inquiète : EEE, Energy Efficient Ethernet. L’idée n’étant pas la sobriété, mais de densifier le datacenter qui est cappé par l’énergie disponible, plus que par le foncier.
Meta cause régulièrement de son matos, logique, car il est fondateur de Opencompute qui fournit des specs libres et travaille en collaboration avec des constructeurs.
Chez Meta, le 100G est généralisé, avec 16 planes en uplink pour un rack, toutes les machines dans un bâtiment sont accessibles en 6 sauts . Le 400G est vu (enfin, en 2021) comme spécifique à l’AI et à l’apprentissage machine.
SR-IOV
Une carte PCIe peut avoir l’option (capability) SR-IOV lui permettant de présenter à l’hôte des périphériques virtuels, avec chacun son bus et son espace mémoire, qui pourront être confié à des machines virtuelles. Azure propose ce genre de chose avec des VMs disposant d’un réseau de 25G, et l’accès au FPGA de la carte via DPDK.
Alibaba utilise ce découpage matériel pour qu’une carte réseau puisse être utilisée en espace utilisateur (avec DPDK) et par le noyau Linux, de manière classique.
Cadriciels réseaux
Netmap
netmap est un projet de l’université de Pise pour une gestion du réseau en espace utilisateur. Des outils sont fournis pour la gestion des switchs et machines virtuelles, ainsi que des papiers de recherche.
FreeBSD a intégré netmap les autres OS (Linux et Windows) sont moins enthousiastes, même si le code est fourni.
L’activité projet est très calme depuis 2019, mais il est souvent comparé à DPDK.
DPDK
DPDK, pour Data Plane Development Kit est un projet fourretout centré sur l’accélération matérielle.
Il permet de gérer des choses farfelues comme l’accélération matérielle d’expressions régulières (pour épauler un WAF ?), mais surtout les cartes réseau.
DPDK cible le SDN (Software Defined Network) et les switchs virtuels qui accompagnent si bien les machines tout aussi virtuelles. Il est pour ça une des cibles de P4, le DSL qui parle réseau.
En plus des possibles accélérations à tous les niveaux, on notera le brutal AF_PACKET qui permet d’envoyer et recevoir des paquets bruts en espace utilisateur, ainsi que AF_XDP qui fait partie de l’écosystème EBPF et XDP. EBPF et XDP permettent de router/bloquer des volumes énormes de paquets avant le noyau, mais la taille du code qui prend les décisions est limité, le routage pourra être fait vers un AF_INET (le classique réseau du noyau) ou un AF_XDP (des paquets bruts en espace utilisateur). AF pour Address Family (comme il existe un AF_UNIX).
DPDK permet la bifurcation de flot, pour répartir le flot réseau entre le noyau et l’espace utilisateur. SR-IOV permet de découper la carte en cartes virtuelles (SR-IOV présente différente adresse Mac sur ses ports Ethernet, et route en L2 le flot vers les cartes virtuelles présentées au bus PCIe), mais certaines cartes sont aussi capables de comprendre les couches suivantes du modèle OSI , et de router en fonction du VLAN, VXLAN, IP, port… que ce soit en IPv4 ou IPv6.
Une expertise “coin de nappe” permet d’affirmer que l’on parle de cartes à partir de 500$ (Metronome Chelsio par exemple).
DPDK fournit une liste des cartes réseau supportées, que vous pourrez explorer avec vos admin sys et vos acheteurs.
mTCP
mTCP a été la référence de TCP en espace utilisateur, et détail mignon, il propose d’utiliser différents projets pour gérer les cartes réseaux, et pas uniquement le maintenant incontournable DPDK.
De manière similaire, ils ont implémenté des alternatives pour la gestion de congestion.
Le projet est intouché depuis 2019.
IX
IX s’appuie sur dune pour régler les problèmes réseau de Linux.
Dune permet d’être plus que root en utilisant les fonctionnalités de virtualisation du processeur pour tripoter des trucs en ring 0, comme la gestion des interruptions.
IX se vante de faire mieux que mTCP, mais date d’avant ROCEv2 et les cartes 100G.
Le papier qui explique tout ça : IX: A Protected Dataplane Operating System for High Throughput and Low Latency.
Le choix de truander le ring 0 est d’une audace folle (dune semble être abandonnée depuis 2016).
f-stack
F-stack a été crée pour que le serveur DNS d’un hébergeur puisse survivre a un DDOS (en UDP donc).
Leur réponse est simple : transplantation de la stack IP de FreeBSD 11 en espace utilisateur.
L’accès au réseau passe par une lib asynchrone utilisant des coroutines ou un truandage pour exposer l’API POSIX avec epoll/kqeue.
C’est du réseau en espace utilisateur (basé sur DPDK), mais ça reste de l’IP traditionnelle, et donc pas du tcpless.
VPP
Vector Packet Processor se focalise sur l’optimisation de la gestion des paquets en vectorisant leur traitement. Plutôt que de travailler à la pièce, on passe à la palette. Les différents paquets sont traités par lot, pour bénéficier au maximum du cache du processeur dont le D-Cache (potentiellement au détriment du I-Cache).
VPP propose de pimper tout le modèle OSI, avec des applications extrêmement diverses (DHCP, Wiregard, V-Host pour virtio, switch virtuel, VRRP, VXLAN, QUIC) et bien sur d’utiliser les accélérations matérielles fournies par DPDK.
VPP a sa fan base, des ⭐️ et des contributeurs, mais ses sous-projets génèrent nettement moins d’enthousiasme.
- TLDK propose d’implémenter la couche L4, (UDP et TCP), avec l’inévitable fork de Nginx. Pas de commit depuis 2021.
- Contiv, officiellement déprécié, proposait un vSwitch par nodes K8s et le tricotage réseau des conteneurs qui allait avec.
K8s n’a pas abandonné VPP, c’est Calico qui a repris le flambeau des mains de Contiv, avec Calico-VPP.
VPP se voit comme un hub ultime du réseau en espace utilisateur, avec un système de plugin et de fallback pour atteindre l’universalisme.
Même s’il existe TLDK, VPP cible clairement l’infra réseau.
Protocoles
SRD
AWS a créé SRD, pour le calcul scientifique, j’en ai parlé dans l’article sur le diskless.
Pour résumer : nouvelle couche de transport sur IP non connecté, mais livraison garantie bien que non ordonnée, et surtout mise en avant du multipath. Leur implémentation utilise les buzzwords du moment : accélération matérielle, DMA, gestion de congestion, contournement du noyau. SRD est utilisé via libfabric pour le calcul scientifique, mais aussi pour tunneler le réseau des machines virtuelles (comme le ferait GRE, VXLAN…), en réordonnant les paquets (classique, UDP, indispensable aux VPN, a aussi besoin de réordonnement).
Snap et pony express
Google a rapidement exploité le réseau en espace utilisateur, déjà évoqué dans l’article précédant sur le diskless.
Pour résumer : snap est le service en espace utilisateur qui gère la carte réseau et du DMA, divers moteurs sont utilisés, les logiciels choisissent le moteur qu’ils veulent, selon les besoins de latence, de débit et de cout. “Pony Express” est le moteur détaillé dans l’article, qui propose un mix de messages courts et de simili RDMA, avec une gestion de congestion aux petits ognons.
HOMA
L’implémentation en espace utilisateur, utilisant DPDK est abandonnée, pour une implémentation en espace noyau, HOMA module. Le protocole est obnubilé par la notion de RPC, des petits messages avec une faible latence (10 fois moindre qu’en TCP). C’est utilisable en C++, en golang (avec go-homa), du Java est promis, et la cible est grpc (avec une promesse de thrift qui arrivera plus tard). Les switchs doivent gérer la qualité de service avec DCSP.
Le protocole est un ping pong, le client envoie un paquet DATA (avec la taille totale du message en meta donnée), le serveur valide et annonce la taille du prochain paquet avec un GRANT. Donc, le protocole fait l’impasse sur les paquets non ordonnés et à priori le multipath.
Aucune référence à RDMA, ou à de l’offloading.
Alibaba
Alibaba a fait évoluer la partie réseau de son stockage en mode bloc en plusieurs étapes.
What’s the Story in EBS Glory: Evolutions and Lessons in Building Cloud Block Store (2024)
RDMA
Pour suivre les performances des disques NVMe, Alibaba s’est orienté vers le RDMA (du RoCE, de l’Ethernet donc), qui permet du zero copy via PCIe entre le disque et la carte réseau. La copie entre le disque et la carte réseau les empêchait de saturer une carte 100G.
Après avoir bien lu les publications de Microsoft qui avait déjà déployé du RDMA à grande échelle, ils sont partis sur du DPDK+SPDK.
Le RDMA a été déployé de manière prudente, juste sur un niveau de switch au dessus des Top Of Rack pour limiter les tempêtes PFC, des racks de stockages, des racks de calcul (c’était pour leur site de vente en ligne, le ratio stockage par CPU est censé être prévisible). Le RDMA n’est activé qu’entre un serveur de calcul et un serveur de stockage, chaque famille de serveurs parle entre eux en TCP (en espace utilisateur).
Ils ont commencé avec des RNIC (du Mellanox) où la carte gère le RDMA, ce qui brime la possibilité de corriger des problèmes (comme ceux liés à PFC). Le RNIC s’est avéré pénible à l’usage, chaque constructeur implémente de manière subtilement différente les uns des autres, et un même constructeur ne fera pas les mêmes choix entre ses différentes gammes de cartes.
Le TCP a été utilisé comme fallback pour le RDMA, et l’isolation entre les deux protocoles n’a pas été sans heurts.
Pour profiter du zero-copy, un filesystem spécifique permet d’écrire directement des blocs, et de faire entre 4 et 10 fois plus d’IOPS que de l’ext4. L’article cite sur ce point Reflex (et son code d’exemple) et i10 (et son code d’exemple) qui anticipent NVMe-of en tcp (il n’était qu’en RDMA à ce moment).
Tous les détails sont dans le papier de 2021 : When Cloud Storage Meets RDMA.
Avoir un pool de stockage par routeur ressemble à l’expérience de Facebook qui était plafonné par la taille maximale d’un cluster HDFS. Facebook s’était retrouvé avec une constellation de milliers de pool de stockage par datacenter, mal balancé, avec des rééquilibrages très pénibles. Voir le papier Facebook’s Tectonic Filesystem: Efficiency from Exascale.
Je suppose que l’expérience a dû être similaire chez Alibaba.
Luna + RDMA
Le papier Deploying User-space TCP at Cloud Scale with Luna (2023)
Luna promet 3.5 fois le débit, réduction de 50% des latences par rapport au TCP du noyau Linux.
Le RDMA n’est pas utilisable pour du multi AZ, et conserver une compatibilité avec TCP est quand même bien pratique.
Les offres existantes de TCP en user space sont prometteuses (IX, mTCP, VPP) mais ont des soucis de conception : * utilisation d’un thread pour le réseau, un autre pour l’application qui engendre un surcout de communication * absence de zero-copy * accès exclusif à la carte réseau
Partant de ce constat, Luna utilise une boucle évènementielle par thread pour entrelacer la gestion du réseau et l’application, et du zero copy.
La carte réseau est partagée avec le noyau via SR-IOV, et, plus raffinée, de la bifurcation de flot (de DPDK) pour choisir pour une IP et un port qui va répondre. LUNA laisse le kernel gérait la couche Ethernet et les adresses ARP, se contentant d’aller les lire via netlink.
Gérer une pile réseau en espace utilisateur nécessite (indirectement) des processeurs gérant les hugepages (de plus de 2Mo je présume) et une partie de leur flotte ne le gérait pas (en 2017), donc utiliser du classique TCP permettait une compatibilité et un déploiement progressif.
Solar
From Luna to Solar: The Evolutions of the Compute-to-Storage Networks in Alibaba Cloud
Dont on peut trouver le PDF ici
Après 5 ans de Luna, Alibaba s’est remis sur la planche à dessin pour concevoir l’itération suivante. Ils ont aussi très vraisemblablement étudié le papier de AWS sur SRD.
En corrigeant les problèmes de réseaux avec Luna, Alibaba a pu découvrir les limites de leurs abstractions de stockage réseau, ainsi que l’importance de la rapidité pour reprendre un incident réseau (quelques millisecondes).
Solar est un protocole UDP conçu pour les besoins de stockage. Il est utilisé conjointement avec Luna, qui a un usage plus large.
L’idée de base est simple et élégante : un bloc disque est contenu dans un bloc réseau. Bloc de 4ko, comme ce qu’utilise le SSD, et donc du jumbo frame pour le réseau. Aucune conversion ou assemblage, on a tout ce qu’il faut pour du zero copy. L’arrivée des paquets n’est pas tenue d’être ordonnée (et donc de maintenir une connexion), ce qui facilite l’utilisation du multipath tant vanté par SRD.
L’utilisateur voit un disque NVMe, qui est géré par l’agent de stockage, qui sait sur quels serveurs écrire, effectuer la réplication, puis prévenir le client que le quorum est atteint.
L’agent est dans la carte d’offloading (l’équivalent du Nitro d’AWS), et il va récupérer quelques informations depuis l’hôte (QOS, chemin), pour le reste il se débrouille, il se comporte comme un disque NVMe, en PCIe, avec donc du DMA. Les cartes ALI-DPU sont des FPGA (avec l’idée de passer a de l’ASIC à un moment), mais ces cartes sont très sensibles au bit-flip (le phénomène que corrige ECC pour la RAM), et donc les calculs de CRC sont validés par le CPU (avec une astuce mathématique pour valider des lots, pas un par un).
Une partie du FPGA étant squatté par l’offloading du vswitch (le routage réseau des VMs), Solar a fait le choix du minimalisme. Choix payant, parce qu’il est possible d’envisager d’implémenter l’agent avec P4, un DSL pour le réseau, et donc d’utiliser un DPU du marché.
Histoire de pinailler, techniquement, Solar ne fait plus de RDMA, même s’il fait du DMA de chaque côté du tuyau (et du zerocopy).
QUIC
QUIC, la couche basse de HTTP/3, est un protocole équivalent à TCP, mais plus adapté à Internet et spécifiquement les réseaux mobiles. Basé sur UDP, il est supporté par les routeurs de plus ou moins mauvaise foi qui forment l’Internet.
W3tech, Mozilla et Cloudflare sont d’accord pour estimer que près de 30% du Web se fait en HTTP/3 (plus qu’en HTTP/1), et Facebook annonçaient 75% en 2020, pour ses services.
Tous les gros acteurs proposent leur implémentation :
- mvfst pour Facebook
- MsQuic pour Microsoft
- XQUIC pour Alibaba (avec tengine son fork de Nginx pour HTTP/3)
- QUICHE (celui en C++) de Google, utilisé par Envoy
- QUICHE (celui en Rust) de Cloudflare. (un patch pour Nginx existe)
- s2n-quic de AWS
HAproxy a sa propre implémentation (cherchez les quic_*.c dans les sources). OpenSSL n’implémente pas encore les routines requises par QUIC, mais il y a un fork pour ça : quictls. Golang a bien sûr son implémentation native, quic-go dont bénéficient Traefik et Caddy.
Tout ça est super, QUIC est le chalengeur officiel de TCP, mais, comme le rappel cUrl, QUIC et HTTP/3, est conçu pour Internet, et pas pour les datacenter. L’établissement rapide des connexions n’a pas un grand intérêt sur des réseaux à faible latence, et les algos de gestion de congestion sont maintenant disponibles pour TCP. cURL a aussi constaté que HTTP/3 était limité par le CPU, chose que l’on ne voit pas quand on est limité par le réseau.
1RMA
Google a constaté que le RDMA avait des performances fort sympathiques (latence, débit, contournement du CPU…), mais qu’il n’a jamais été conçu pour le multitenant. Ajoutons à ça les reproches favoris de Google : gestions des congestions naïves, flasher un firmware (pour corriger ou tuner) c’est relou.
Google décrit donc 1RMA, pour “one way RMA”. Leur idée est de ne pas avoir de discussions (une connexion, quoi), mais des messages initiés d’un bout ou l’autre du tuyau.
Leur concept est de virer toute la magie de la carte, qu’elle se contente de délester uniquement des éléments bien spécifiés (et qui n’évolueront pas) : DMA, réseau, chiffrage et signature.
Ce qui donne leur liste en 5 points :
1 - Pas de connexion. C’est à l’applicatif de séquencer s’il en a besoin, pas au protocole. La plupart des messages seront indépendants. Avec un engagement de latence faible, il est possible d’enchainer des questions/réponses, plutôt que d’utiliser des trains de paquets comme le fait TCP.
2 - Petits paquets. 4ko, comme pour un disque dur. L’idée est donc d’envoyer 3,125 millions de paquets par seconde, sur une carte 100G. Avec un découpage fin, on peut garantir des latences, gérer de la qualité de service, pour obtenir un bon débit, il suffira d’user de violence.
3 - Contrôle de congestion logiciel. Ce n’est pas au switch de bricoler. La carte va fournir des mesures fines pour connaitre le temps de trajet sur le réseau, hors des fils d’attente, ce qui permet d’estimer la saturation. Ce système permet de partager le trafic avec des échanges non 1RMA, et de gérer des ralentissements en 25µs.
4 - Allocation des ressources définies par le logiciel. Avec des petits paquets et en imposant des délais (timeout) très courts, il est possible de gérer le débit au maximum, de garantir des latences faibles et une gestion contenue des incidents. En maitrisant le flot de paquets, il est possible d’appliquer des priorités métiers, sans bouchons.
5 - Sécurité par défaut. Tous les échanges sont chiffrés et signés par la carte, les petits paquets permettent de gérer la rotation de clés sans passer par le classique “erreur, la clé a changé, recommences”.
Dans leurs tests, le 1RMA consomme 1/2 cœur et utilise à plein une carte 100G.
Tous les détails et graphiques sont dans leur papier de 2020 : 1RMA: Re-envisioning Remote Memory Access for Multi-tenant Datacenters
Swift
Google dans son article de 2020 Swift: Delay is Simple and Effective for Congestion Control in the Datacenter décret son algo de gestion de congestion Swift, successeur de Timely (le papier de 2015 TIMELY: RTT-based Congestion Control for the Datacenter).
En préambule, il rappelle que pour désagréger le stockage, il faut des latences de 100µs pour du disque Flash, et 10µs pour du NVMe (et 10ms pour un seek sur un disque à plateaux).
L’article met un peu de temps à l’avouer, Swift est utilisé pour du 1RMA sur du Pony express, dans Snap. Ce n’est qu’un détail, l’algorithme reprend ce qui se fait avec TCP.
Comme DCTCP leur a fait des grumeaux en millisecondes, ils en disent pis que pendre.
Le concept, simple, est d’adapter le débit aux délais de la connexion. “Pas plus haut que le bord” comme on dit.
L’algo est basé sur AIMD “ajout additif, retrait multiplicatif” en traduction charabia, “croissance linéaire, décroissance exponentielle” en meilleur français. L’un des attraits de cet algo est que si chacun des flots calcule son débit avec, on aboutit à une stabilité de l’ensemble.
Swift ne veut pas dépendre du switch, ni pour les informations (rejet de paquets ou message ECN), ni pour des obligations de paramétrages (seuil ECN), en se gardant la possibilité d’un déploiement progressif (remplacement progressif de switch 10G par des 100G).
Swift considère que les délais de commutations des switch sur une route sont fixes, et dépendent du nombre de sauts. Swift, en connaissant la cible, connait la route, le nombre de switch à parcourir, et donc le délai.
Pour connaitre le délai de carte à carte, Swift va utiliser l’horodatage de la carte (après la queue Tx depuis la source, avant la queue Rx sur la cible), puis le temps de traitement. Les informations nécessaires seront transmises dans un entête du ACK (qui part sans attente, lui). Pour rappel, l’article parle de 1RMA comme protocole, qui est un protocole avec des messages à “sens unique” : un message envoyé, un ACK en retour (ou un timeout).
Swift prévoit des connexions sans états, mais conserve une notion de flot, le débit entre la source et la cible, pour calculer une “fenêtre de congestion”, et utiliser la plus petite des deux (entre la source et la cible).
Swift va collaborer avec le QOS d’autres protocoles classiques, et n’a pas besoin d’exclusivité sur la connexion (ou la carte réseau).
Les usages de Swift sont divers, ils peuvent être limités par :
- le débit (disques distants)
- la latence (base clé/valeur)
- les IOPS (système de fichiers distants)
Conclusion
Les gains en performance du réseau (et du stockage) sont en complet décalage avec les gains en performance des CPUs, obligés par la fin de Moore à multiplier ses cœurs.
Brancher des cartes 100G au cul de vos serveurs ne va pas suffire. Pour profiter des performances monstrueuses du matériel moderne, il faut délester le CPU, et mettre le doigt dans l’explosion cambrienne des offres d’offloading en choisissant une abstraction pérenne (DPDK, P4, SPDK…) pour ne pas se verrouiller avec un constructeur.
Le DMA et le zero-copy ont le vent en poupe.
Le noyau Linux (et ses interruptions) n’est pas à l’aise pour gérer efficacement ce nouveau palier de performance matérielle, mais il avance vers la communication non bloquante (avec les ring), et propose des points d’entrée pour mixer espace noyau et espace utilisateur de manière efficace. La virtualisation va dans le même sens, et permet d’exposer des API classiques (dans les machines virtuelles) alors que l’hôte utilise des API modernistes.
L’article prétend traiter du tcpless, parce que le nom est porteur.
Mais avant de s’attaquer aux protocoles alternatifs, la première étape est d’utiliser l’offloading fourni par la carte réseau, puis les outils réseaux en espace utilisateur. DPDK for the win.
Il n’y a pas de nouveaux protocoles réseau libres pour les datacenters (RoCE peut-être?) mais sortir de TCP parait être l’étape indispensable pour la désagrégation.
Passer d’une pile IP en espace noyau, avec les API POSIX a une pile IP en espace utilisateur avec une API éxotique doit être justifié par un vrai gain. Passer par virtio a au moins le mérite d’être transparent pour l’application.
Tester les gestionnaires de congestions modernes (dctcp, bbr v3) et voir ce que ça change au niveau des latences et des pertes de paquets a le bon gout d’être bien moins intrusif.
Écrire son petit protocole réseau à soi est une tache dantesque, sans compter qu’ensuite il faut le maintenir et gérer les potentiels (inévitables ?) incidents. Puis patcher Ceph.
J’aurais peut-être dû nommer l’article “l’ère du post-CPU”.