Home Articles techniques Évaluation BBR sur un grand CDN
Applications

About The Author

Outline

Bottleneck Bandwidth and Round-Trip propagation Time (BBR) est un algorithme de contrôle de congestion TCP qui a attiré l’attention du marché en raison de sa capacité à fournir un débit plus élevé, comme l’ont signalé de nombreux fournisseurs de contenu. Dans cet article, nous évaluons BBR (version 1) dans le contexte des charges de travail du réseau de diffusion de contenu (CDN) de Verizon Media, aujourd’hui Edgio, qui fournit des volumes importants (plusieurs Tbps) de mises à jour logicielles et de streaming vidéo, et quantifions les avantages et l’impact sur le trafic. Nous espérons qu’une telle évaluation dans un grand CDN aidera d’autres fournisseurs de contenu à choisir le protocole de contrôle de congestion adapté à leur trafic.

Contexte

De nombreux fournisseurs de contenu et chercheurs universitaires ont constaté que BBR fournit un débit supérieur à d’autres protocoles comme TCP-Cubic. Contrairement aux algorithmes de contrôle de congestion basés sur les pertes, tels que l’omniprésent TCP-Cubic, BBR a un paradigme de fonctionnement différent : il met à jour en permanence la quantité de données pouvant être en vol en fonction du RTT minimum que la session a vu jusqu’à présent pour éviter le bufferbloat. Pour plus d’informations sur le fonctionnement de BBR, consultez la publication originale de Google ici.

Mesures et analyse

Afin de comprendre le potentiel de BBR dans notre CDN, nous avons évalué BBR à plusieurs étapes, en mesurant l’impact sur les flux TCP à partir de quelques points de présence (POP). Les POP représentent une concentration de serveurs de mise en cache situés dans les grandes zones métropolitaines. Au départ, nous avons effectué un test BBR à petite échelle lors d’un POP et nous avons également effectué un test POP complet, avec tous les flux vers les clients exécutant BBR. Pour identifier les avantages que les clients pourraient ressentir, nous avons mesuré le débit de nos journaux de serveur Web de proxy internes pendant le test, ainsi que l’analyse au niveau socket.

Métriques à évaluer

Notre CDN multi-tenant voit une grande variété de trafic client. De nombreux clients ont beaucoup de petits objets, tandis que d’autres ont des objets de plusieurs gigaoctets beaucoup plus grands. Par conséquent, il est crucial d’identifier les indicateurs de réussite qui capturent les gains de performances réels sur différents modèles de trafic. En particulier, pour cette évaluation, nous avons identifié le débit et les temps d’exécution du flux TCP comme paramètres de réussite. Dans la figure 1, nous montrons une carte thermique des tailles d’objets courantes demandées au CDN en fonction du temps nécessaire pour les servir. Le dégradé de couleurs indique le nombre de demandes dans chaque catégorie. Il s’agit de nombres représentatifs d’un petit ensemble de serveurs, suffisants pour capturer le comportement commun uniquement.

Figure 1. Carte thermique montrant les tailles d’objet courantes.

La carte thermique nous permet de comprendre les différents modèles de demande. En général, l’augmentation du débit est le meilleur indicateur du gain de performances. Cependant, le débit en tant que mesure peut être très bruyant, en particulier dans les cas où la taille de l’objet est petite (moins de quelques Mo). Par conséquent, sur la base d’une évaluation séparée des tailles qui fournissent l’évaluation la plus fiable du débit, nous utilisons uniquement une taille d’objet supérieure à 3 Mo pour les évaluations de débit. Pour les objets de moins de 3 Mo, le suivi des temps d’exécution du flux est une meilleure mesure.

Comme première étape de notre évaluation, nous avons activé BBR sur quelques serveurs lors d’un POP à Los Angeles et surveillé le débit et les temps d’exécution des flux pour tous les flux TCP. Les résultats suivants examinent quelques études de cas spécifiques aux fournisseurs de services Internet.

Un grand fournisseur de services sans fil

La figure 2 montre la différence une fois le BBR activé.

Figure 2. Impact sur le débit pour les clients d’un grand fournisseur de services sans fil lorsque BBR était activé (test) par rapport aux flux cubiques (contrôle). Gauche : mesures de débit sur deux jours. La ligne bleue verticale indique quand le BBR a été activé. Ici, nous voyons une amélioration globale d’environ 6-8% avec BBR. Droite : un CDF du débit du 5e percentile. Les flux BBR montrent une amélioration significative.

Pour ce fournisseur sans fil, dès que nous avons activé BBR, en moyenne, nous avons constaté une amélioration du débit de 6 à 8 %. Nous avons également constaté des temps d’exécution de flux TCP plus faibles dans l’ensemble. Cette constatation est en accord avec d’autres rapports de Spotify, Dropbox et YouTube, où un gain de débit évident est observé dans les réseaux sans fil où la perte de paquets est courante, mais qui ne sont pas nécessairement un indicateur de congestion.

Un grand fournisseur de services filaires

Ensuite, nous avons examiné le rendement d’un grand fournisseur de services filaires. Ici aussi, nous avons vu à la fois le débit (pour les objets volumineux) et le temps d’exécution du flux (illustré à la figure 3). Améliorations utilisant BBR.

Figure 3. Temps moyen nécessaire pour terminer un flux pour un grand fournisseur de services filaires. Les flux BBR (test) montrent moins de gigue et prennent moins de temps pour terminer le transfert de données. Les avantages sont plus percutants pour les objets plus grands. Cependant, nous voyons une gigue similaire pour les grandes tailles de fichiers pour Cubic et BBR.

Les gains rapportés de ces tests montrent des résultats très prometteurs pour le trafic côté client.

Puisque ces gains sont sur une vue agrégée, nous avons décidé de creuser un peu plus loin pour vérifier si tous les flux TCP au POP ont vu l’avantage d’utiliser BBR ; ou si certains flux TCP ont souffert, et lesquels?

À la périphérie du CDN, nous effectuons quatre types de sessions TCP différents :

  • Pop-to-client (voir ci-dessus)
  • Pop-to-pop (entre les centres de données)
  • Communication intra-POP (entre les caches d’un même POP)
  • Pop-to-Origin (pop vers le centre de données d’origine client)

Pour cette étude, nous avons considéré les flux POP-to-client, POP-POP et intra-POP, car le volume bord-à-origine n’est pas aussi élevé que les trois autres.

Trafic pop-to-pop et intra-pop

Il est important d’évaluer également l’impact sur ces flux TCP, car dans de nombreux cas, ces flux bloquent la diffusion client, par exemple pour le contenu dynamique.

Pour le débit de trafic pop-to-pop et intra-pop, nous avons constaté une importante régression des performances. La figure 4 illustre l’impact sur le trafic intra-POP et pop-to-POP au cours de la même période :

Figure 4. Impact sur le débit du trafic intra-POP et Pop-to-POP lorsque BBR était activé (test) par rapport aux flux cubiques (contrôle). Mesures de débit sur deux jours. La ligne bleue verticale indique quand le BBR a été activé. Le débit a diminué d’environ moitié avec BBR.

De telles différences de performances évidentes entre les flux vers les utilisateurs finaux et entre les centres de données n’ont pas été signalées dans les conclusions précédentes. Nous devons évaluer pourquoi ces flux TCP particuliers ont souffert ; s’il s’agit d’un artefact de matériel ou de configurations sur notre CDN ; et si oui, quels réglages devraient être modifiés.

D’après une enquête plus approfondie utilisant les journaux d’accès au serveur Web et des évaluations à partir des données de socket côté serveur, il est apparu qu’en présence de flux RTT élevés et faibles, les flux TCP qui ont des RTT très faibles souffraient de l’utilisation de BBR. Nous avons également évalué les cas où moins de 0,5 Ko de données ont été transférés et constaté que dans la plupart des cas, BBR fonctionnait de manière similaire à Cubic.

Sur la base de ces résultats, nous avons conclu que pour nos modèles de trafic, il est préférable d’utiliser Cubic pour les communications intra-POP et pop-to-POP où les TRT et les pertes sont faibles. Pour le trafic côté client, il vaut la peine d’utiliser BBR.

Test POP complet

Pour évaluer les avantages de BBR en termes de performances à grande échelle, nous avons effectué un test POP complet à un point POP de Rio de Janeiro pour tout le trafic client de notre réseau à ce point POP. Ce POP a fait une étude de cas intéressante puisque les contraintes de localisation et de peering dans la région entraînent des TRT médianes plus élevées que dans les autres régions.

Figure 5. Amélioration du débit en utilisant BBR pour le client, CAR cela montre des retransmissions élevées (ASN1).

Nous avons déployé le changement dans l’algorithme de contrôle de congestion et surveillé les performances. Un CDF de débit observé en utilisant BBR vs Cubic pour les deux principaux AS (Autonomous Systems) à Rio est montré. Comme le montre la figure 5, une AS, dans l’ensemble, a vu les avantages du BBR tandis qu’une autre ne l’a pas fait.

Pour étudier le raisonnement derrière cela, nous avons cherché d’autres métriques TCP collectées pendant le test à l’aide de l’utilitaire ss. On distingue nettement le débit de retransmission entre ces deux ASE. Même pour les AS avec des RTT plus élevés, BBR ne fonctionne bien que pour les cas qui ont un nombre élevé de retransmissions, en d’autres termes, pour les AS avec moins de perte Cubic n’a aucune raison de reculer et fonctionne mieux que BBR. Il est cependant important de noter que de nombreux paramètres de TCP Cubic ont été soigneusement ajustés sur notre CDN.

Ensuite, nous avons examiné si toutes les connexions de l’ASN1 montrées dans la figure 5, montraient une amélioration du débit. La figure 6 est un tracé du temps pris (plus faible implique un meilleur débit) par les connexions BBR et Cubic pour différentes tailles d’objet. Ici, nous voyons que BBR a seulement commencé à montrer des avantages notables pour les objets plus grands, de l’ordre de Mo. Nous avons vu une instance anormale utilisant BBR, mais nous n’avons pas pu l’attribuer à un problème particulier lié au protocole de contrôle de congestion.

Figure 6. Pour les ASE qui affichent des améliorations, l’avantage de BBR est visible pour les flux de longue durée avec des fichiers volumineux.

Pourquoi cela se produit-il ?

Ces résultats ont deux dimensions : cubique vs BBR et BBR vs BBR.

Cubique vs BBR

BBR est très réactif aux tailles de tampon et au RTT lorsqu’il estime la bande passante du goulot d’étranglement. Dans le cas de tampons volumineux, où les boîtes intermédiaires peuvent constituer une file d’attente, le RTT estimé de BBR augmente. Puisqu’il n’y a pas de perte de paquets, Cubic ne recule pas dans de tels cas, en d’autres termes, le trafic de style pop-to-pop, et donc Cubic atteint un débit plus élevé. Dans le cas de petits tampons, tels que les clients sans fil, le tampon se remplit rapidement et entraîne une perte – ainsi, les flux Cubic reviennent et les flux BBR fonctionnent mieux.

BBR vs BBR

Dans ce scénario, aucun flux ne diminue en cas de perte. Cependant, lorsque deux flux avec des RTT différents se disputent une part de bande passante, le flux qui a un RTT plus élevé a également un RTT minimum plus grand et donc un produit de retard de bande passante plus élevé. Ainsi, ce flux augmente ses données en vol à un rythme beaucoup plus rapide que le flux qui a un RTT plus faible. Cela conduit à la réallocation de la largeur de bande aux flux dans l’ordre décroissant des RTT et les flux avec des RTT plus élevés remplissent les tampons plus rapidement que les flux avec de petits RTT.

Reproduction des résultats dans un laboratoire

Pour mieux comprendre les interactions entre les flux, nous avons créé un environnement de banc d’essai dans des machines virtuelles qui capturent le comportement observé en production. Nous avons identifié des façons de simuler différentes classes de trafic sur un serveur périphérique comme suit :

Le délai du trafic client a été défini sur ~50 ms avec des pertes allant de 0,001 à 0,1 et un goulot d’étranglement de bande passante de 50 Mbit/s. De même, pour pop-to-pop seulement la perte et le délai ont été définis à ~15 ms et 0,0001 à 0,01. Pour le trafic intra- POP, nous laissons les machines virtuelles dépasser la capacité disponible. Enfin, des simulations ont été exécutées en utilisant différentes tailles d’objets pour capturer la nature multi-tenant de notre trafic. Nous exécutons les trois schémas de trafic en parallèle avec une arrivée exponentielle des flux pour capturer une distribution d’arrivée de flux de type poisson. La figure 7 illustre la configuration du banc d’essai.

Le but de ce test était de reproduire les problèmes que nous voyons dans le test de production, en particulier la baisse de débit pour les petits flux RTT pour le trafic intra-POP et pop-to-POP.

Figure 7. Configuration du laboratoire à l’aide des utilitaires KVM, iperf, netem et tc.

En utilisant cette configuration, nous avons exécuté la simulation des centaines de fois avec un trafic de fond simulé, à la fois cubique et BBR, et mesuré le temps nécessaire pour terminer les flux. L’objectif du trafic en arrière-plan est de simuler un environnement de production. De nombreuses études existantes se sont concentrées sur l’exécution de quelques flux de Cubic et BBR et l’évaluation de leurs comportements. Bien que dans ces cas, il soit utile de comprendre le comportement par flux, il représente mal les complexités d’un CDN à volume élevé et important. Nous avons utilisé le temps d’exécution du flux côté client comme indicateur fiable car pour les fichiers de petite taille, le débit peut être bruyant.

Figure 8. Temps pris par les flux iperf. Gauche : flux client. Droite : flux pop-to-pop. Taille de l’objet : 3MB. BBR s’est mieux comporté que Cubic pour les flux client simulés.

Nous avons vu le motif réapparaître dans notre banc d’essai aussi bien. Dans la figure 8, nous montrons un CDF du temps pris par les flux BBR et Cubic iperf dans deux scénarios : le trafic client et le trafic pop-to-pop pour les fichiers de 3 Mo (taille moyenne). Les flux BBR ne parviennent pas à rattraper Cubic dans une configuration à bande passante élevée et à faible perte. Le trafic client (faible bande passante) a connu une amélioration, c’est-à-dire que le temps pris par les flux BBR a été moindre. Cependant, l’amélioration pour les petits fichiers est marginale. Reproduire ces comportements dans l’environnement de test nous donne l’assurance qu’ils sont le résultat de l’interaction entre différents types de flux. Par conséquent, tout déploiement de BBR sur le CDN doit être conscient de l’impact plus large qu’il peut avoir sur une combinaison de types de flux.

Conclusion

À partir de notre évaluation, nous avons observé que les flux BBR ne fonctionnent pas bien dans tous les scénarios. Plus précisément, le trafic au sein d’un datacenter/point de présence (POP) et le trafic entre les datacenters (POP-to-POP) ont souffert lors de l’utilisation de BBR. Dans certains cas extrêmes, le débit est réduit de moitié. Cependant, nous avons constaté une amélioration de 6 à 8 % du débit du trafic Pop-to-client.

Dans ce billet, nous avons décrit l’évaluation de BBR (version 1) dans le contexte de notre CDN. Nous avons commencé par un petit test de quelques serveurs dans un seul POP et évalué différentes variables qui nous intéressent en tant que grand fournisseur de contenu. Lors d’un test POP complet à grande échelle, nous avons remarqué que BBR aiderait le plus dans les cas où les retransmissions sont élevées et nous suggérons qu’il vaut la peine d’utiliser BBR pour les fichiers volumineux.

Où allons-nous à partir d’ici ?

Si nous activons BBR au niveau du système (tous les flux), nous risquons de voir le trafic intra-POP et pop-to-POP subir des baisses de débit.

Cependant, BBR a montré son potentiel et fonctionne bien pour le trafic côté client. Cela nous motive à activer BBR de manière sélective pour les clients, en commençant potentiellement par les fournisseurs de services sans fil. De plus, ces chemins ont des tampons peu profonds et une perte sans fil, une situation idéale pour BBR pour fonctionner mieux que les autres flux cubiques.

Nous espérons que ce plan apportera une certaine clarté sur l’utilisation du BBR chez les grands fournisseurs de contenu et ses implications sur les différents types de trafic qui peuvent partager des goulets d’étranglement. La version alpha de BBRv2 est maintenant disponible, ce qui devrait résoudre certains de ces problèmes. Nous prévoyons de continuer à évaluer les nouvelles versions de BBR et d’utiliser un contrôleur de transport intelligent qui sélectionne le bon contrôle de congestion pour le bon type de flux. Nous partagerons plus de détails à ce sujet à l’avenir.

Grâce à la contribution de différentes équipes à travers l’organisation qui a rendu cette analyse possible!