La bande passante du goulot d’étranglement et le temps de propagation aller-retour (BBR) sont des algorithmes de contrôle de congestion TCP qui ont suscité une attention considérable du marché en raison de sa capacité à fournir un débit plus élevé, comme l’indiquent de nombreux fournisseurs de contenu. Dans cet article, nous évaluons BBR (version 1) dans le contexte des charges de travail CDN (Content Delivery Network) de Verizon Media, aujourd’hui Edgio, qui fournissent des volumes importants (plusieurs Tbps) de mises à jour logicielles et de streaming vidéo, et quantifient les avantages et l’impact sur le trafic. Nous espérons qu’une telle évaluation auprès d’un grand CDN aidera d’autres fournisseurs de contenu à choisir le protocole de contrôle de congestion adapté à leur trafic.
Arrière-plan
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 le TCP-Cubic omniprésent, 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 la prolifération de tampon. Pour plus d’informations sur le fonctionnement de BBR, jetez un oeil à la publication originale de Google ici.
Mesures et analyses
Afin de comprendre le potentiel de BBR au sein de 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 de grandes zones métropolitaines. Initialement, nous avons effectué un test BBR à petite échelle à un POP et 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 retirer, nous avons mesuré le débit de nos journaux de serveur Web proxy internes pendant le test, ainsi que l’analyse au niveau des sockets.
Métriques à évaluer
Notre CDN multi-tenant reçoit 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 des 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’achèvement 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 Vs temps pris pour les servir. Le dégradé de couleurs indique le nombre de demandes dans chaque catégorie. Ce sont des nombres représentatifs d’un petit ensemble de serveurs, suffisants pour capturer le comportement commun uniquement.
Figure 1. Carte thermique montrant les tailles d’objets courantes.
La carte thermique nous donne une compréhension des 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 la taille d’objet supérieure à 3 Mo pour les évaluations du débit. Pour les objets de taille inférieure à 3 Mo, le suivi des temps d’achèvement des flux est une meilleure mesure.
Dans la première étape de notre évaluation, nous avons activé BBR sur quelques serveurs à un point de vente à Los Angeles et surveillé le débit et les temps d’achèvement des flux pour tous les flux TCP. Les résultats suivants examinent quelques études de cas spécifiques à un fournisseur de services Internet.
Un grand fournisseur de services sans fil
La figure 2 montre la différence une fois BBR activé.
Figure 2. Impact sur le débit pour les clients d’un grand fournisseur de services sans fil lorsque BBR a été activé (test) par rapport aux flux cubiques (contrôle). Gauche : mesures de débit sur deux jours. La ligne bleue verticale indique quand 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 de services 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 observé des temps d’achèvement 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 net de débit est observé dans les réseaux sans fil où la perte de paquets est courante, mais ce n’est pas nécessairement un indicateur de congestion.
Un grand fournisseur de services filaires
Ensuite, nous avons examiné les performances d’un grand fournisseur de services filaires. Ici aussi, nous avons vu des améliorations à la fois de débit (pour les objets volumineux) et de temps d’achèvement de flux (illustré à la figure 3.) en utilisant BBR.
Figure 3. Temps moyen nécessaire pour effectuer un flux pour un grand fournisseur de services filaires. Les flux BBR (test) affichent moins de gigue et prennent moins de temps pour terminer le transfert des données. Les avantages sont plus percutants pour les objets plus grands. Cependant, nous observons une gigue similaire pour les fichiers de grande taille pour Cubic et BBR.
Les gains rapportés lors 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 différents de sessions TCP :
- Pop-to-Client (comme illustré ci-dessus)
- Pop-to-pop (entre centres de données)
- Communication intra-pop (entre les caches d’un même pop)
- Pop-to-Origin (pop vers centre de données d’origine client)
Pour cette étude, nous avons pris en compte les flux POP-to-Client, POP-POP et intra-POP puisque le volume du bord à l’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 sont des bloqueurs pour la livraison client, comme pour le contenu dynamique.
Pour le débit de trafic pop-to-pop et intra-pop, nous avons observé une forte 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 pour le trafic intra-pop et pop-to-pop lorsque BBR a été activé (test) par rapport aux flux cubiques (contrôle). Mesures de débit sur deux jours. La ligne bleue verticale indique quand BBR a été activé. Le débit a diminué de moitié environ 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 résultats précédents. 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 des recherches plus poussées utilisant des journaux d’accès au serveur Web et des évaluations à partir de 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 avons constaté que, dans la plupart des cas, BBR fonctionnait de la même manière que 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 est utile d’utiliser BBR.
Test POP complet
Pour évaluer les avantages de performance de BBR à grande échelle, nous avons effectué un test POP complet dans un POP de Rio de Janeiro pour tout le trafic client de notre réseau sur ce POP. Ce POP a constitué une étude de cas intéressante puisque les contraintes de localisation et de peering dans la région entraînent des TTR médians plus élevés pour les clients que dans les autres régions.
Figure 5. Amélioration du débit à l’aide de 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 la congestion et surveillé les performances. Un CDF de débit observé en utilisant BBR vs Cubic pour les deux premiers ASE (Autonomous Systems) à Rio est montré. Comme le montre la figure 5, un AS, dans l’ensemble, a vu les avantages de BBR tandis qu’un 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. Une distinction claire est observée dans le débit de retransmission entre ces deux AS. 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 revenir en arrière et fonctionne mieux que BBR. Il est cependant important de noter que de nombreux paramètres de TCP Cubic ont été soigneusement réglés sur notre CDN.
Ensuite, nous avons cherché à savoir si toutes les connexions de l’ASN1 montrées à 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 commencé à montrer seulement des avantages notables pour les objets plus grands, de l’ordre de MB. Nous avons vu une instance anormale utilisant BBR, mais nous ne pouvions pas l’attribuer à un problème particulier lié au protocole de contrôle de congestion.
Figure 6. Pour les EA qui montrent des améliorations, l’avantage de BBR est visible pour les flux à long terme avec des fichiers volumineux.
Pourquoi cela se produit-il ?
Il y a deux dimensions à ces résultats – Cubic vs BBR et BBR vs BBR.
Cubique vs BBR
BBR est très réactif aux tailles de tampon et RTT lorsqu’il estime la bande passante de goulot d’étranglement. Dans le cas de grands tampons, où les middlebox 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 par conséquent 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 – les flux Cubic reviennent et les flux BBR fonctionnent mieux.
BBR vs BBR
Dans ce scénario, aucun flux ne recule en cas de perte. Cependant, lorsque deux flux avec des RTT différents sont en concurrence pour une part de bande passante, le flux qui a un RTT plus élevé a également un RTT minimum plus grand et donc un produit bande-retard plus élevé. Ainsi, ce flux augmente ses données en vol à un débit beaucoup plus rapide que le flux qui a un RTT plus faible. Cela conduit à la réallocation de bande passante 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 des RTT plus petits.
Reproduction des résultats dans un laboratoire
Pour approfondir la compréhension des interactions entre les flux, nous avons créé un environnement de banc d’essai dans les machines virtuelles qui capture le comportement que nous avons observé en production. Nous avons identifié les moyens de simuler différentes classes de trafic sur un serveur périphérique comme suit :
Le délai de trafic client a été défini à ~50 ms avec des pertes allant de 0,001 à 0,1 et une bande passante de goulot d’étranglement de 50 Mbit/s. De même, pour pop-to-pop, seuls la perte et le retard ont été fixés à ~15 ms et de 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-locataire de notre trafic. Nous exécutons les trois modèles de trafic en parallèle avec une arrivée exponentielle de 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 en 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 type production. De nombreuses études existantes se sont concentrées sur l’exécution de quelques flux de cubique 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 de grand volume. Nous avons utilisé le temps d’achèvement du flux côté client comme indicateur fiable car pour les fichiers de petite taille, le débit peut être bruyant.
Figure 8. Le temps pris par les flux iperf. Gauche : flux client. Droite : flux pop-to-pop. Taille de l’objet : 3 Mo. BBR a obtenu de meilleurs résultats que Cubic pour les flux client simulés.
Nous avons vu le modèle réapparaître dans notre banc d’essai aussi bien. Dans la figure 8, nous montrons un CDF du temps pris par BBR et les flux iperf cubiques 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 à faible perte et à bande passante élevée. 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. La reproduction de ces comportements dans l’environnement de test nous donne la certitude 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 un mélange 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 centre de données/point de présence (POP) et le trafic entre les centres de données (POP-à-POP) souffraient 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 même pop et avons évalué différentes variables qui nous intéressent en tant que grand fournisseur de contenu. Dans un test POP complet à grande échelle, nous avons remarqué que BBR aiderait le plus dans les cas où les retransmissions sont élevées et 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 diminutions de débit.
Cependant, BBR a montré du 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 apporte une certaine clarté sur l’utilisation de 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.
Merci à la contribution de différentes équipes à travers l’organisation qui ont rendu cette analyse possible!
