Lors de l’exploitation d’un vaste réseau mondial, il est essentiel de garantir une bonne connectivité et des performances optimales entre les systèmes qui communiquent sur Internet public pour garantir une expérience utilisateur positive. Compte tenu de la nature complexe et du meilleur effort de l’Internet, même les liaisons les plus bien approvisionnées sur les fournisseurs les plus fiables ont parfois des problèmes.
Il existe un certain nombre de stratégies pour surveiller de telles liaisons, y compris la mesure active , qui génère du trafic spécifiquement pour la mesure, et la mesure passive , qui surveille le trafic existant. Dans cet article, nous décrivons une approche passive qui utilise notre système d’échantillonnage de socket xTCP pour surveiller passivement de nombreux liens dont dépend notre réseau.
Pour tirer le meilleur parti des données de xTCP, nous avons développé une approche de traitement de ces données qui répond à certains des défis associés à la surveillance Internet. En particulier, nous introduisons un concept que nous appelons le ratio de retransmission , qui fournit une mesure relative de la gravité des retransmissions observées entre des sites de réseau de distribution de contenu (CDN). Nous démontrons que le taux de retransmission au-dessus de certains niveaux correspond à des dégradations du débit, impactant directement les performances perçues par l’utilisateur, ce qui en fait une excellente base pour l’automatisation du réseau qui nous permet de contourner les dégradations des performances du réseau.
Arrière-plan
Un flux de travail courant dans le CDN implique qu’un point de présence (POP) contacte un autre pour un élément de contenu, par exemple, pour récupérer un élément de contenu à mettre en cache. Souvent, ces interactions sont effectuées en réponse directe à une requête client, ce qui signifie que la requête en aval peut attendre la fin de ce transfert. Généralement, les requêtes elles-mêmes peuvent être assez petites, de l’ordre de quelques kilo-octets. Les réponses peuvent être de taille très variable, allant de kilo-octets à plusieurs méga-octets.
Fig 1 : le flux de requêtes envoie de petites requêtes (ordre Ko) et reçoit des réponses potentiellement importantes (potentiellement mégaoctets).
Afin de surveiller la santé des connexions entre les points de présence, nous sommes en mesure d’utiliser notre outil de surveillance des sockets, xTCP, pour échantillonner l’état actuel de toutes les sockets ouvertes sur nos serveurs périphériques. Bien que cela offre une visibilité critique dans nos sockets orientés client, ces données de socket nous donnent également une vue des données entre les POP.
Cependant, mesurer ces données n’est pas sans quelques défis. Tout d’abord, xTCP fournit un échantillon ponctuel de différentes connexions. Cela signifie que nous pourrions attraper de nombreuses connexions dans de nombreux points différents de la transmission. Par conséquent, toute évaluation que nous ferons devra tenir compte de la distribution plus large des comportements, plutôt que de valeurs individuelles.
Ensuite, nous devons nous assurer que nous surveillons la bonne direction. Alors que le pop qui a généré la requête (pop A dans le diagramme ci-dessus) et le pop qui a reçu la requête et doit y répondre (pop B ci-dessus) ont des informations de socket, leurs charges de travail asymétriques signifient que nous nous attendons à voir un comportement différent : la majorité des paquets envoyés par le client seront des paquets de contrôle (la requête initiale, les paquets d’accusé de réception ultérieurs), tandis que la majorité des paquets envoyés par le serveur seront des paquets de données, qui sont plus susceptibles de contenir des volumes significatifs.
En conséquence, en cas de congestion ou d’autres problèmes le long du chemin, les paquets transportant des données, et occupant donc plus d’espace de file d’attente, sont plus susceptibles de subir des pertes de paquets et de subir des retransmissions, par exemple à la suite de pertes de file d’attente sur un routeur occupé. Pour démontrer cela, nous considérons la distribution des débits de retransmission de paquets (calculés comme le rapport du nombre total de paquets retransmis divisé par le nombre total de segments de données envoyés, moins les retransmissions) vus dans les flux de requête et de réponse entre une paire de POP pendant une période de 10 minutes.
Fig 2 : le trafic de réponse rencontre plus de retransmissions, probablement en raison de leur taille plus importante.
Ici, nous voyons que les sockets de requête client ne subissent presque aucune retransmission pendant cette période de temps. En revanche, les réponses montrent près de 85% des sockets ayant des retransmissions non nulles, cependant, on note que le taux de retransmission est bien inférieur à 1% pour la grande majorité des connexions. Sans surprise, nous observons un comportement similaire sur presque chaque paire de POP avec des retransmissions non nulles pendant la période de test. Nous nous concentrons donc sur les flux de réponse chargés de données. Puisque nous sommes concernés par le service des demandes aux POP demandeurs originaux, nous les appelons flux « entrants ».
Notre dernier défi vient de certaines complexités générales autour des retransmissions, et de la difficulté de les utiliser comme signal de dégradation des performances. En effet, les retransmissions peuvent se produire régulièrement sans indiquer un problème particulier, car elles reflètent simplement l’état de l’expéditeur et le nombre de fois qu’un paquet a été renvoyé. Ceux-ci peuvent finalement être le résultat d’un comportement de protocole complexe en plus de la perte (par exemple, sondage de perte de queue ). Ajoutant à la complexité, nous observons que de nombreuses sockets n’observent jamais les retransmissions. Cela signifie que les résumés naïfs (par exemple, en prenant la médiane) peuvent donner lieu à des résumés très prudents du taux de retransmission, et les résumés biaisés (par exemple, 95e ou 99e percentile) peuvent largement refléter des comportements qui ne sont pas nuisibles à la population en général.
Rapport de retransmission
Afin de simplifier les impacts de ces défis, nous considérons une métrique composite que nous appelons le ratio de retransmission. Inspirée par le ratio HD de Meta , qui vise à quantifier la fraction de clients capables de diffuser de la vidéo HD, cette mesure tente de décrire la fraction de sockets qui connaissent un niveau de retransmission malsain. Étant donné que des retransmissions non nulles sont parfois attendues, nous définissons le taux de retransmission comme suit :
De manière critique, cette valeur est particulièrement facile à calculer avec les données mises à disposition via xTCP. Dans notre expérience opérationnelle, nous avons constaté que les valeurs du taux de retransmission sont généralement faibles sur les liaisons saines, tout en évitant les défis presque toujours nuls présents dans les mesures de taux de retransmission bruts.
Nous avons également constaté que la mesure était sensible, générant souvent des alertes avant les autres systèmes de surveillance des performances. Cela le rend particulièrement utile lors du diagnostic rapide des dégradations de réseau, qui commencent souvent par de petits problèmes qui finissent par se répercuter sur des problèmes plus importants.
Validation de l’audit
Afin de démontrer que le taux de retransmission est directement corrélé aux performances applicatives, nous démontrons son efficacité en considérant deux mesures. Tout d’abord, nous montrons que pendant les périodes de taux de retransmission élevé, l’application cliente (le demandeur) connaît un débit plus faible que pendant les périodes de taux de retransmission faible ou nul. Deuxièmement, nous montrons que le taux de retransmission élevé correspond souvent à des dégradations dans d’autres signaux de réseau, en particulier, les sondes ICMP entre POP.
Pour explorer les impacts sur les performances applicatives, nous nous tournons vers des mesures prises explicitement à partir de la couche applicative. En particulier, nous considérons les débits mesurés au point de vente du client, car ils représentent le taux de livraison fonctionnel atteint dans le processus d’envoi des données. Afin de comprendre l’impact des événements de retransmission, nous avons mené l’étude suivante sur une paire de POP au cours d’une semaine, au cours de laquelle un problème important avec le fournisseur est survenu.
Premièrement, nous considérons toutes les périodes au cours desquelles un événement de retransmission s’est produit. Nous définissons un événement de retransmission comme toute période de temps au cours de laquelle le rapport de retransmission entre une paire de POP se situe dans une certaine plage pendant au moins dix minutes consécutives. Bien que nous notons que cela exclut les événements de courte durée, cela fournit un aperçu du comportement des événements plus longs. Pour chaque événement de retransmission, nous collectons ensuite les valeurs de débit correspondantes au cours de l’événement. À titre de contrôle, nous collectons des données pour la même durée que l’événement mais trois heures avant. Cela nous donne deux ensembles de mesures de débit : les événements « pendant » de retransmission et « normal », pris pendant les périodes de non retransmission. Nous normalisons ensuite les mesures « pendant » par le débit médian atteint entre les POP en temps normal. Pour nos seuils, nous considérons quatre fourchettes : supérieure à 0 mais inférieure à 25 %, supérieure à 25 mais inférieure à 50 %, supérieure à 50 mais inférieure à 75 %, et enfin supérieure à 75 %.
Figure 3 : débit relatif par rapport aux périodes de non-retransmission, observé lors de chaque événement de retransmission.
La figure ci-dessus montre la distribution des débits relatifs observés pendant la période de mesure. Premièrement, nous constatons que même dans la plage la plus basse, 60 % des transactions ont atteint un débit inférieur à la médiane. Lorsque nous considérons des rapports de retransmission plus élevés, le débit continue de chuter, un rapport de retransmission plus élevé correspondant à un débit plus faible, et le pire des cas résultant en une diminution médiane relative de plus d’un ordre de grandeur. Ces mesures montrent clairement que le taux de retransmission capture avec succès la mauvaise performance des flux impactés.
Ensuite, nous examinons comment ces événements sont corrélés avec nos mesures ICMP actives entre les POP. Ici, nous considérons le comportement de certains de nos systèmes de surveillance active, qui effectuent des sondages ICMP réguliers entre les POP, pour mesurer toute perte ou changement dans les schémas de retard. Pour cette analyse, nous utilisons à nouveau les événements extraits de notre comparaison de débit. Cette fois, cependant, nous examinons la perte mesurée ICMP pour des périodes de temps de chaque seuil, où normal dans ce cas observé aucune perte. Nous notons que les limites de notre sondage ICMP entraînent une granularité de perte de 2 % pour ces mesures particulières.
Fig 4 : perte ICMP observée pendant chaque période de temps. Un taux de retransmission plus élevé correspond à une perte plus importante.
Ici, nous constatons que les seuils inférieurs montrent rarement une perte, 90% des mesures n’en détectant aucune. En revanche, au seuil de .75, 80 % des mesures ont observé une perte et une perte médiane relativement élevée de 4 %. De manière critique, nous notons que les niveaux où le taux de retransmission correspondait à des impacts de débit significatifs (par exemple 0,25) entraînent peu de perte dans les métriques ICMP. Ces résultats réitèrent l’importance de mesurer la performance des chemins au-delà des simples sondes ICMP, et mettent en évidence la capacité du taux de retransmission à offrir une vue nuancée de la performance des flux réels sur Internet.
Conclusions et au-delà
Dans cet article, nous avons démontré la valeur du rapport de retransmission, une métrique récapitulative pratique qui peut être facilement calculée avec les données disponibles à partir des données du socket xTCP aussi. Nous avons également montré qu’il fournit des informations claires sur les cas où les performances applicatives sont affectées et où des interventions réseau sont nécessaires.
Le rapport de retransmission est devenu un élément clé de notre processus de surveillance, fournissant une vision claire des performances du système, sans avoir à traiter des journaux d’application plus volumineux et plus encombrants ou à compter sur des sondes ICMP qui ne parviennent pas à capturer certains impacts.
Nos travaux en cours explorent comment la métrique peut être rendue aussi sensible que possible pour fournir une alerte précoce aux dégradations, tout en fournissant une entrée appropriée à des systèmes d’automatisation plus complexes.
Un grand merci aux équipes architecture et Network Reliability Engineering pour leur soutien dans ce travail !
Pour les chercheurs intéressés à en savoir plus sur Edgio Labs & Advanced Projects, ou intéressés à explorer des travaux collaboratifs sur l’un des sujets décrits ci-dessus, veuillez contacter l’équipe à research@edg.io.
