Home Articles techniques Comment utiliser RTT Metrics pour améliorer les performances de streaming
Applications

Comment utiliser RTT Metrics pour améliorer les performances de streaming

About The Author

Outline

La qualité du streaming vidéo dépend de millions de choses qui se passent correctement, comme la gestion d’une charge de travail fluctuante constante ou la gestion de « foules flash » lorsque de nombreux spectateurs entrent dans un flux en même temps. C’est pourquoi fournir un flux vidéo fiable et de haute qualité dans le cadre d’un service payant – où les téléspectateurs attendent une expérience semblable à celle de la télévision – nécessite des outils et des mesures pour articuler finement les défis de performance afin que vous puissiez savoir où et comment résoudre les problèmes.

Les CDN sont une solution indispensable pour le streaming vidéo car ils offrent une évolutivité à faible latence à la demande dans le monde entier. En plus des optimisations qui améliorent la manière, le CDN équilibre la croissance chaotique de l’audience qui peut accompagner un flux en direct, fournir d’excellentes performances à l’utilisateur final nécessite une couche supplémentaire de visibilité, de métriques, d’outils et d’automatisation.

Dans cet article, nous passerons en revue des exemples d’optimisations de performance récentes que nous avons faites pour un grand service de streaming vMVPD nord-américain, notamment:

  • Mesures que nous utilisons pour améliorer/résoudre les problèmes de performances
  • Comment définir les performances et comment les mesurer
  • Optimisations continues que nous prenons pour améliorer les performances vidéo

Numéros de systèmes autonomes : la complexité derrière le rideau

Le Web moderne est construit autour de plusieurs couches interconnectées de réseaux appelés ASN (Autonomous System Numbers), chacun composé de grands groupes d’adresses IP couplés à des CDN (content Delivery Networks) qui réduisent la congestion en rendant le contenu disponible à la périphérie. Essentiellement, comme indiqué ci-dessous, Internet est constitué d’un réseau de réseaux, chacun ayant son modèle d’affaires et ses priorités uniques.

Source : Research Gate

Associée à la complexité inhérente des ASN qui interagissent les uns avec les autres, leur portée et leur échelle sont à elles seules. L’outil vizAS tente de visualiser les interconnexions entre les nombreux ASN pays par pays. Par exemple, rien qu’aux États-Unis, il existe 16 979 ASN et 24 905 relations de peering sur les réseaux. À l’échelle mondiale, il existe plus de 90 000 ASN.

https://stats.apnic.net/vizas/index.html

De notre point de vue en tant que fournisseur de CDN, la complexité de la connexion à des milliers d’ASN est aggravée par la nécessité de répondre aux exigences de performance, au profil d’utilisation, au type de trafic et à de nombreux autres facteurs de chaque client. Par exemple, un service comme Twitter aura un profil d’utilisation ou une empreinte bien différente de celle d’une société de jeux qui propose une mise à jour majeure. De même, un diffuseur diffusant en continu un événement sportif en direct a un profil différent d’un service de diffusion en continu à la demande. Même deux services de streaming en direct ont probablement des profils différents, chacun nécessitant une optimisation des performances sur mesure.

En coulisses, nous disposons d’un grand nombre de paramètres de configuration que nous pouvons ajuster et régler pour aider les clients à atteindre leurs objectifs et exigences de performance. Pour certains, la performance peut être ce qu’ils attendaient (ou mieux) du départ, et nous n’avons pas besoin de changer quoi que ce soit. D’autres peuvent avoir des objectifs spécifiques, tels que le TTFB (Time To First Byte) plus rapide, une mesure importante pour les services de streaming, qui doivent être abordés.

Compte tenu de la complexité et de la taille d’Internet, il est impossible d’apporter des améliorations de performance utiles et cohérentes par le biais d’approches « Whack-a-mole » ou Scattershot. Les gains réels proviennent de la collecte complète de données et de l’analyse intensive des données pour identifier la cause profonde d’un problème ou obtenir de manière proactive un aperçu des changements de configuration du réseau qui profiteront le plus au client.

Fournir des informations RTT avec Stargazer

L’une des mesures les plus importantes pour déterminer la latence du réseau et l’intégrité globale des performances est le RTT (aller-retour). Ceci est défini comme la durée, mesurée en millisecondes, qu’il faut à un paquet pour voyager de la source à la destination et une réponse pour être renvoyée à la source. Il peut être utilisé pour diagnostiquer et améliorer les performances du réseau sur plusieurs vecteurs, y compris la congestion, les problèmes matériels, les mauvaises configurations et les problèmes de routage.

Compte tenu de l’importance de cette mesure, nous avons construit un système interne appelé Stargazer que nous utilisons pour agréger les données RTT provenant de diverses sources, y compris nos capteurs, les données que nous importons de clients et les tiers qui surveillent également les informations RTT. Stargazer surveille les temps de réponse sortants allant au client. D’autres sources de données peuvent inclure des tables BGP (Border Gateway Protocol) des routeurs, le mappage des routeurs à des emplacements géographiques, les journaux RTT pour les connexions des clients et les informations sur le volume de trafic. En outre, le système peut effectuer des sondes actives telles que des traceroutes et des pings si nécessaire.

Derrière l’activité de monitoring, Stargazer, en conjonction avec d’autres outils que nous avons développés, nous permet d’interroger toutes les données que nous avons collectées et d’effectuer des analyses approfondies qui ouvrent la voie à des améliorations continues. Nos administrateurs réseau peuvent utiliser ces informations pour isoler les problèmes et identifier les routes ou les configurations réseau afin d’optimiser les performances en fonction des objectifs et des exigences spécifiques des clients. Et, comme nous le verrons plus loin, il est également utile pour comprendre l’effet des nouvelles technologies, telles que le protocole BBR (Bottleneck Bandwidth and Round-trip propagation time), sur les performances.

Optimisation d’un serveur d’origine

Pour mieux comprendre comment l’optimisation des performances fonctionne dans la pratique, examinons un exemple impliquant un client de streaming vidéo en direct récemment ajouté qui avait besoin d’optimiser pour une architecture multi-CDN. Dans une architecture client CDN traditionnelle, le client fait une requête à l’un de nos POP, et le cache POP se remplit à partir de l’origine, comme indiqué ci-dessous.

Cependant, ce client a choisi de tirer parti d’une architecture multi-CDN pour augmenter la redondance et la résilience et potentiellement augmenter les performances. Ceci est activé par notre architecture Origin Shield illustrée à la figure 4. Origin Shield offre plus de contrôle sur la façon dont le trafic des différents clients peut être acheminé pour obtenir les meilleures performances.

Contrairement à une relation CDN traditionnelle, tout le trafic, y compris celui desservi par le deuxième CDN, retourne vers l’un de nos POP (AGA) situé à Atlanta pour le remplissage du cache. Le POP AGA sert alors d’origine, ou plus précisément, ce que l’on appelle le bouclier d’origine, soulageant le fardeau considérable du serveur d’origine du client. Le POP AGA a été choisi comme emplacement de bouclier d’origine en raison de son taux de cache-hit et de ses performances plus élevés que le deuxième CDN. Une préoccupation majeure, cependant, était l’optimisation des performances entre les deux CDN.

La première étape du processus a consisté à étudier l’optimisation des routes empruntées par le deuxième CDN vers AGA, avec celui-ci agissant comme bouclier d’origine. Un problème immédiatement apparent était la mauvaise performance entre les CDN et un nombre élevé de délais de connexion ayant un impact sur TTFB. Pour creuser les problèmes de performance, nous avons utilisé Stargazer pour envoyer un traceroute depuis AGA vers la destination prévue et capturer les ASN utilisés pour chaque saut.

Comme indiqué dans le résumé ci-dessous, un traceroute a été envoyé depuis AGA vers une adresse IP au niveau du deuxième CDN, simulant le chemin du client.

Nous avons remarqué que plusieurs sauts se trouvaient dans l’ASN 7018, ce qui n’était pas l’itinéraire préféré car il impliquait plus de sauts et avait plus de congestion. En utilisant Stargazer, nous avons rapidement confirmé le problème et apporté les modifications appropriées au réseau. Comme le montre le résumé traceroute ci-dessous, après avoir effectué le changement de réseau, nous avons diminué le nombre de sauts et amélioré RTT en basculant vers ASN 7922, ce qui a également résolu le problème des délais TTFB.

Dans un autre exemple, nous avons utilisé l’outil Stargazer pour déterminer le meilleur chemin de bouclier d’origine vers le serveur d’origine d’un client situé sur la côte est. Pour réduire efficacement la charge sur l’origine d’un client et améliorer les performances de livraison, le pop de bouclier d’origine doit être proche de l’origine. Parfois, ce n’est pas nécessairement le pop physique le plus proche qui fonctionne le mieux. C’est une combinaison du moins d’ASN, du moins de congestion et de temps de RTT faibles. Comme vous pouvez le voir dans le tableau avant et après ci-dessous, un traceroute Stargazer a montré que le passage du pop NYA (New York) au pop DCC (Washington, D.C.) a réduit le nombre de sauts à trois, ce qui a entraîné une amélioration globale des performances RTT.

Analyse approfondie avec Sweeper Fish

Avec plus de 7 000 interconnexions et plus de 300 pop sur notre CDN à travers le monde, il y a beaucoup de travail d’optimisation en cours. Pour éviter de faire tourner nos roues sur des tâches qui ne font peut-être pas beaucoup de différence, nous avions besoin d’un moyen efficace de prioriser les actions entreprises par nos équipes opérationnelles. Ce besoin a conduit au développement d’un outil compagnon pour Stargazer appelé Sweeper Fish qui marque les endroits où les problèmes existent et nous permet de les faire monter en flèche de manière hiérarchisée.

Sweeper Fish est également utile pour déterminer si une route est encombrée et si elle est susceptible de causer des problèmes. Revenant à l’exemple multi-CDN, nous avons utilisé Sweeper Fish pour découvrir quelles routes étaient congestionnées. Pour ce faire, Sweeper Fish a mesuré le delta entre le 25e et le 75e percentile pour les données RUM (Real User Measurement) pour tous les clients sur tous les chemins vers le POP AGA, en se concentrant sur le chemin du deuxième CDN vers nous, ASN7922. L’écart-type pour tout le trafic sur cet ASN est indiqué ci-dessous.

Nous avons également confirmé que la configuration précédente via ASN7018 n’était pas la solution. L’analyse de Sweeper Fish a montré que l’IQR (intervalle interquartile) a atteint un pic de 20-60 à millisecondes (voir la figure 9) en raison de la congestion sur cette route. L’IQR, également appelé middle spread ou middle 50%, fournit un moyen utile d’analyser une route et de signaler rapidement les problèmes. Plus l’IQR est bas, mieux c’est.

En revanche, le pop AGA était constamment entre 10-22 millisecondes sur la route que nous avons finalement utilisée, ASN7922, comme indiqué ci-dessous. En comparant différents ASN, Sweeper Fish nous permet de choisir la meilleure route, la moins encombrée et/ou d’identifier les problèmes à résoudre.

Réglage TCP

La congestion entraîne également l’abandon et la retransmission des paquets. Cela se produit lorsque les chemins entre les POPS sont distants et que l’algorithme TCP n’est pas optimisé. Puisque AGA était à l’origine de notre exemple, il était possible que des POP éloignés qui ont atteint AGA aient ce problème. Bien que répartis sur de nombreux pop, les journaux CDN agrégés ci-dessous nous ont permis d’identifier les zones problématiques indiquées par les cases.

Figure 11. Les journaux de serveur agrégés identifient rapidement les zones problématiques où les paquets sont abandonnés et retransmis.

Évaluation du BBR

Bottleneck Bandwidth and Round-trip propagation Time (BBR) est un algorithme alternatif de contrôle de congestion TCP développé par Google qui a commencé à gagner du terrain. Il diffère des algorithmes de contrôle de congestion basés sur les pertes, tels que l’omniprésent TCP-Cubic, et introduit 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 gonflement de la mémoire tampon.

Notre analyse a révélé que BBR est utile pour améliorer les performances de RTT, mais qu’il n’est pas une solution universelle. Il y a des moments où vous voulez l’utiliser et d’autres moments où vous ne le faites pas Stargazer nous aide à déterminer quand nous voulons l’utiliser en suivant le profil cohérent des RTT vers les destinations au fil des périodes. Cela nous permet de déterminer les meilleurs endroits pour appliquer le BBR pour aider à réduire les retransmissions et améliorer le contrôle du débit.

Sur la base de l’analyse présentée dans les graphiques ci-dessous, nous avons conclu que le passage au BBR améliorerait légèrement les performances du POP AGA vers le deuxième CDN et l’origine du client. Le premier ensemble de graphiques montre que le passage de TCP-Cubic à TCP BBR a entraîné une diminution des retransmissions, tandis que le second ensemble de graphiques indique que le passage à BBR a entraîné une légère augmentation du débit moyen.

Figure 12. Dans cet exemple, le passage de TCP-Cubic à TCP BBR a entraîné une diminution des retransmissions

Figure 13. Dans cet exemple, le passage à BBR pour le contrôle de flux à partir de TCP-Cubic pour le POP AGA a réduit les retransmissions et légèrement amélioré le débit moyen.

Conclusion

Internet est vaste et complexe – il s’agit essentiellement d’un réseau de réseaux. Pour Edgecast, aujourd’hui Edgio, l’optimisation des performances pour les cas d’utilisation des clients serait presque impossible sans analyses approfondies pour mieux comprendre les zones problématiques et tester les modifications de configuration possibles. Afin d’améliorer les performances de nos clients, nous avons développé un ensemble robuste d’outils pour surveiller continuellement les RTT afin que nous puissions apporter rapidement et efficacement des améliorations sur l’ensemble de notre réseau. Pour un service de streaming vidéo en direct, nous avons trouvé des moyens d’optimiser les performances pour leurs besoins uniques tout en évaluant l’utilisation de BBR pour leur application. Le résultat a été une solution de streaming haute performance exploitant deux CDN. Et nous n’en avons pas encore fini. Alors que la congestion du réseau continue d’augmenter, nous ne cesserons jamais d’optimiser notre réseau pour nous assurer que nos clients et leurs clients bénéficient de la meilleure expérience en ligne possible.