Home Articles techniques Amélioration des performances du réseau grâce au réglage dynamique du contrôle de la congestion
Applications

Amélioration des performances du réseau grâce au réglage dynamique du contrôle de la congestion

About The Author

Outline

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 CCA 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 CUBIC. Bien que TCP BBR et CUBIC visent à éviter la congestion, 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 délai de paquets comme indicateur au lieu de la perte de paquets. Cependant, nos recherches précédentes ont rapporté que le 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 en termes de débit pour les petits fichiers (<100 Ko). De plus, nous avons observé que la performance BBR pour les écoulements avec un faible temps aller-retour (RTT) et de faibles retransmissions était pire que CUBIC. Enfin, les avantages du BBR n’ont été observés que pour le trafic orienté client, tandis que les connexions back-office (faible RTT et retransmissions négligeables) ont été meilleures avec CUBIC.

Edgecast, maintenant Edgio, est un CDN multi-tenant mondial qui fournit du trafic Web à de nombreux grands clients de streaming vidéo (VOD et live). É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 de la congestion que nous avons mise à la disposition de tous nos clients.

Aperçu de la méthodologie

L’apport le plus important à un tel système dynamique est peut-être les données qui le alimentent. Notre mécanisme de réglage dynamique du contrôle de la congestion se trouve au-dessus de notre collection de données de socket à grande échelle, qui exporte les données de performance de socket TCP (xTCP) de tous les caches périphériques. Plus précisément, il extrait des informations de la structure tcp_info du noyau Linux via NetLink et les transmet via Kafka dans un cluster ClickHouse. Disposer de 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 performances des gains à 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 possibilité 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 une 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 notre analyse des 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 périphérique (POP) pour éviter de basculer entre CUBIC 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 de fichier est supérieure à 100 Ko. Un débit CUBIQUE affiné est plus performant pour les petits fichiers.

Le contrôleur BBR utilise deux métriques pour évaluer l’intégrité de chaque préfixe client observé :

  • Cycle d’utilisation : combien de temps a duré un préfixe (/24 ou /56) dans le groupe de performance du 20e centile inférieur ?
  • Taux de flap : à 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 les moins performants au cours des dernières heures. Cette détection s’effectue toutes les 5 minutes. Bien que le nombre total de préfixes sélectionnés par pop d’arête puisse être de l’ordre de 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 configuration 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 à notre périphérie dans le monde entier a permis d’améliorer considérablement les performances. Une métrique clé que nous suivons à partir des données de socket xTCP est le taux de livraison rapporté dans TCP_INFO. Puisque nous activons BBR de manière dynamique pour les préfixes les plus sous-performants, nous nous attendons à ce que notre taux de livraison en percentile inférieur (pire cas) s’améliore.

La figure suivante montre l’amélioration du taux de livraison des 5e et 10e percentiles à 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 à la suite du changement du BBR.

De même, dans la figure suivante, nous montrons une amélioration considérable (~2x) du taux de livraison en percentile inférieur pour un grand FAI résidentiel aux États-Unis dès que nous avons activé de façon dynamique le BBR 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 du 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 observé dans les journaux d’accès HTTP pour la connexion client, c’est-à-dire goodput.

Nous mesurons le bon rendement d’un serveur de cache périphérique. Comme le montre la figure ci-dessous, cette modification a entraîné une augmentation du produit. Dans l’ensemble, le bon produit du 10e percentile a augmenté de 12 %.

Figure 5. Le goodput du 10e percentile a augmenté de 12 %.

Un grand merci à l’équipe de développement BBR de Google pour leur travail incroyable sur BBRv1 et leurs efforts continus sur BBRv2. Nous attendons avec impatience la BBRv2 et continuerons d’apporter des changements pertinents à notre plate-forme 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 d’Edgecast pour avoir soutenu ce changement pendant le développement, les tests et le déploiement. L’équipe d’ingénierie d’Edgio tient à remercier Dave Seddon pour sa contribution au développement de l’outil xTCP qui a alimenté une grande partie de l’analyse.

Grâce au réglage dynamique du contrôle de la congestion, les clients Edgio obtiennent désormais automatiquement des améliorations de performances pour leurs clients sous-performants et améliorent leurs performances de résultat net, ce qui se traduit par une diffusion Web plus rapide et une réduction des buffers pour le streaming vidéo.