L’algorithme de contrôle de congestion (CCA) TCP (transmission Control Protocol) régit la quantité de données à envoyer entre les clients et les serveurs afin d’optimiser l’utilisation de la bande passante disponible et d’éviter la congestion. Depuis sa création, d’autres ACC ont été développés depuis sa création, tels que la bande passante de goulot d’étranglement, le temps de propagation aller-retour (TCP BBR), et CUBIQUE. Bien que TCP BBR et CUBIC visent à éviter les embouteillages, comprendre leur efficacité a été une mission permanente pour nos équipes d’ingénierie et de recherche.
TCP BBR vise à atteindre un débit plus élevé en utilisant le retard de paquet comme indicateur au lieu de la perte de paquet. Cependant, notre recherche précédente a rapporté que BBR fonctionne mal dans tous les cas. Plus précisément, notre évaluation a conclu qu’il n’y avait que peu ou pas d’avantages dans le débit pour les petits fichiers (<100 Ko). De plus, nous avons observé que la performance BBR pour les flux à faible temps aller-retour (RTT) et faible retransmission était pire que CUBIQUE. Enfin, les avantages de BBR n’ont été observés que pour le trafic orienté client, tandis que les connexions back-office (faible RTT et retransmissions négligeables) fonctionnaient mieux avec CUBIC.
Edgecast, aujourd’hui Edgio, est un CDN multi-tenant mondial qui fournit du trafic Web à de nombreux clients importants (VOD et live) de streaming vidéo. Étant donné que les réglages de contrôle de congestion utilisant BBR pour un client peuvent nuire aux performances d’un autre client, et qu’une activation globale peut entraîner une dégradation des performances dans certains scénarios, nous avons mis en place un mécanisme pour détecter les cas où BBR fournit des performances améliorées et peut l’activer dynamiquement pour tous les clients CDN. Le résultat est une nouvelle fonctionnalité de réglage dynamique du contrôle de congestion que nous avons mise à la disposition de tous nos clients.
Aperçus de la méthodologie
L’entrée la plus importante d’un système aussi dynamique est peut-être les données qui le propulsent. Notre mécanisme de réglage dynamique de contrôle de congestion se trouve au-dessus de notre collecte de données de socket à grande échelle, qui exporte les données de performance de socket TCP (xTCP) de tous les caches de périphérie. Plus précisément, il extrait les informations de la structure tcp_INFO du noyau Linux via NetLink et les diffuse via Kafka dans un cluster ClickHouse. Avoir ces données de performances de socket à grande échelle nous permet de surveiller les performances des connexions à nos serveurs de cache avec une granularité très élevée. XTCP s’est avéré être un outil puissant pour de nombreuses optimisations CDN. Par exemple, nous avons récemment modifié notre fenêtre de congestion initiale IPv6 et surveillé les gains de performances à l’aide de xTCP.
XTCP est similaire au travail effectué par l’outil tcp-info de Google Measurement Lab (M-Lab) avec des différences significatives provenant des optimisations nécessaires pour gérer le grand nombre de sockets vus par nos caches périphériques (par rapport aux serveurs M-Lab) et la capacité d’exporter les données au format protobuf. Restez à l’écoute, nous prévoyons d’ouvrir xTCP source bientôt.
Dans la figure suivante, nous montrons la vue d’ensemble de notre système. Les données xTCP sont collectées à grande échelle à partir de tous nos caches périphériques diffusés dans Kafka. Les données xTCP sont ensuite collectées dans un cluster ClickHouse, qui alimente nos analyses de données réseau, y compris le contrôleur BBR, qui détecte les préfixes sous-performants à chaque pop de périphérie.
Figure 1. Présentation de la collecte de données à l’aide d’un push de configuration xTCP et BBR.
Bien que nous souhaitions maintenir la nature dynamique de notre flux de travail, nous devons également sélectionner des préfixes constamment sous-performants à chaque point de présence (POP) de bord pour éviter les basculements entre CUBIQUES et BBR sur de courtes durées. Et, comme indiqué précédemment, nous activons BBR de manière sélective pour les requêtes dont la taille du fichier est supérieure à 100 Ko. Un flux CUBIQUE affiné est plus performant pour les petits fichiers.
Le contrôleur BBR utilise deux mesures pour évaluer l’intégrité de chaque préfixe client observé :
- Cycle de service : combien de temps durait un préfixe (/24 ou /56) dans le groupe de performance du 20e centile inférieur?
- Taux de lambeau : à quelle fréquence le préfixe apparaît-il et disparaît-il du groupe de performance du 20e percentile inférieur, c’est-à-dire, changement d’état?
L’algorithme détecte ensuite systématiquement les préfixes moins performants au cours des dernières heures. Cette détection s’exécute toutes les 5 minutes. Bien que le nombre total de préfixes sélectionnés par pop de bord puisse être de quelques centaines, nous avons observé que les performances des préfixes restent relativement constantes. Les mêmes préfixes sont régulièrement sélectionnés, et les nouveaux ajouts à chaque tour (comme le montre la figure suivante de la pop de Chicago) sont très peu nombreux.
Figure 2. Le nombre de nouveaux préfixes sélectionnés par tour de génération de config est faible.
Le cas échéant, de nouveaux préfixes sont sélectionnés pour activer BBR, et une configuration est générée, passée par une étape de validation et poussée vers nos caches périphériques globalement.
Gains de performances
Nous sommes heureux d’annoncer que l’activation de BBR à travers notre périphérie dans le monde entier a montré des améliorations considérables des performances. Une métrique clé que nous suivons à partir des données de socket xTCP est le taux de livraison rapporté dans TCP_INFO. Étant donné que nous activons BBR de manière dynamique pour les préfixes les plus sous-performants, nous nous attendons à une amélioration de notre taux de livraison en percentile inférieur (pire des cas).
La figure suivante montre l’amélioration du taux de livraison des 5e et 10e centiles à notre pop de Los Angeles dès que le changement BBR a été activé.
Figure 3. Des améliorations ont été observées dans les taux d’accouchement des 5e et 10e percentiles suite à un changement de la RBBB.
De même, dans la figure suivante, nous montrons une amélioration considérable (~2x) du taux de livraison en centiles inférieur pour un grand fournisseur de services Internet résidentiel aux États-Unis dès que nous avons activé BBR dynamiquement dans tous nos POP nord-américains.
Figure 4. Des améliorations ont été observées pour un grand FAI résidentiel après activation dynamique de BBR.
Le taux de livraison extrait de TCP-INFO fournit une bonne estimation des performances vues par le client. Cependant, l’indicateur de performance le plus précis est le débit vu dans les journaux d’accès HTTP pour la connexion client, c’est-à-dire, le goodput.
Nous mesurons le goodput à partir d’un serveur de cache périphérique. Comme le montre la figure suivante, le changement a entraîné une augmentation du goodput. Dans l’ensemble, le goodput du 10e percentile a augmenté de 12 %.
Figure 5. Le goodput du 10e centile a augmenté de 12 %.
Un merci spécial à l’équipe de développement BBR de Google pour leur travail incroyable sur BBRv1 et leurs efforts continus sur BBRv2. Nous attendons avec impatience BBRv2 et continuerons à apporter des changements pertinents à notre plateforme sous peu. Félicitations à Sergio Ruiz, Joseph Korkames, Joe Lahoud, Juan Bran, Daniel Lockhart, Ben Lovett, Colin Rasor, Mohnish Lad, Muhammad Bashir, Zach Jones et Dave Andrews chez Edgecast pour avoir soutenu ce changement pendant le développement, les tests et le déploiement. L’équipe d’ingénieurs Edgio tient à remercier tout particulièrement Dave Seddon pour sa contribution au développement de l’outil xTCP qui a permis une grande partie de l’analyse.
Grâce au réglage dynamique du contrôle de la congestion, les clients Edgio bénéficient désormais automatiquement d’améliorations de performances pour leurs clients sous-performants et améliorent leurs performances financières, ce qui se traduit par une diffusion Web plus rapide et une réduction des rebuffers pour le streaming vidéo.
