Lors de l’exploitation d’un vaste réseau mondial, il est essentiel d’assurer une bonne connectivité et de bonnes performances entre les systèmes qui communiquent sur l’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 mieux 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 nombreuses liaisons 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 taux de retransmission, qui fournit une mesure relative de la gravité des retransmissions observées entre les 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.
Contexte
Un flux de travail commun dans le CDN, implique un point de présence (POP) atteignant 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 demande du client, ce qui signifie que la demande 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 des requêtes de petite taille (ordre KB) 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 poser 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 faisons devra tenir compte de la distribution plus large des comportements, plutôt que de valeurs uniques.
Ensuite, nous devons nous assurer que nous suivons la bonne direction. Bien que le POP qui a généré la demande (POP A dans le diagramme ci-dessus) et le POP qui a reçu la demande et doit y répondre (POP B ci-dessus) aient des informations sur les sockets, 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 de données.
Par conséquent, 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 rencontrer 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 taux de retransmission de paquets (calculée comme le rapport du total des paquets retransmis divisé par le nombre total de segments de données envoyés, moins les retransmissions) vu 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 plus grande taille.
Ici, nous voyons que les sockets de requête client n’éprouvent presque aucune retransmission pendant cette période. En revanche, les réponses montrent que près de 85% des sockets ont 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 toutes les paires de POPS 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 autre comportement complexe de protocole en plus de la perte (par exemple, le sondage de perte de queue). Ajoutant à la complexité, nous observons que de nombreuses sockets n’observent jamais de retransmissions. Cela signifie que les résumés naïfs (par exemple, en prenant la médiane) peuvent entraîner des résumés très conservateurs du taux de retransmission, et les résumés biaisés (par exemple, 95e ou 99e percentile) peuvent en grande partie capturer un comportement qui n’est pas nocif pour la population en général.
Taux de retransmission
Afin d’aider à 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 s’efforce de décrire la fraction de sockets qui connaissent un niveau malsain de retransmissions. Puisque des retransmissions différentes de zéro sont parfois attendues, nous définissons le rapport de retransmission comme suit :
De manière critique, cette valeur est particulièrement facile à calculer avec des données rendues disponibles via xTCP. Dans notre expérience opérationnelle, nous avons constaté que les valeurs du taux de retransmission sont généralement faibles sur des liaisons saines, tout en évitant les défis presque toujours nuls présents dans les mesures de taux de retransmission brutes.
Nous avons également constaté que la mesure était sensible, générant souvent des alertes avant d’autres systèmes de surveillance des performances. Cela le rend particulièrement utile lors du diagnostic rapide des dégradations du réseau, qui commencent souvent par de petits problèmes qui finissent par se transformer en problèmes plus importants.
Validation de la mesure
Afin de démontrer que le taux de retransmission est directement corrélé aux performances de l’application, 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 qu’un taux de retransmission élevé correspond souvent à des dégradations dans d’autres signaux de réseau, en particulier, les sondes ICMP entre POPS.
Pour explorer les impacts sur les performances applicatives, nous nous tournons vers des mesures prises explicitement à partir de la couche applicative. Nous considérons en particulier 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 de 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 de fournisseur s’est produit.
Tout d’abord, 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 dans 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 notions que cela exclut les événements de courte durée, il 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 pendant l’événement. En tant que contrôle, nous recueillons 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 : le « pendant » les événements de retransmission et le « normal », pris pendant les périodes de non retransmission. Nous normalisons ensuite les mesures « pendant » par le débit médian réalisé entre les POP en temps normal. Pour nos seuils, nous considérons quatre fourchettes : supérieur à 0 mais inférieur à 25 %, supérieur à 25 mais inférieur à 50 %, supérieur à 50 mais inférieur à 75 %, et enfin supérieur à 75 %.
Figure 3 : le 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 fourchette la plus basse, 60 % des transactions ont atteint un débit inférieur à la médiane. Si l’on considère des rapports de retransmission plus élevés, le débit continue de chuter, avec un rapport de retransmission plus élevé correspondant à un débit plus faible, et le pire des cas entraînant 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 les mauvaises performances des flux impactés.
Ensuite, nous allons voir 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 surveillants actifs, qui effectuent des sondages ICMP réguliers entre les POP, pour mesurer toute perte ou changement dans les modèles de retard. Pour cette analyse, nous utilisons à nouveau les événements extraits de notre comparaison de débit. Cette fois, cependant, nous regardons la perte mesurée ICMP pour les périodes de temps de chaque seuil, où normal dans ce cas n’a observé aucune perte. Nous notons que les limitations de notre sondage ICMP entraînent une granularité de perte de 2 % pour ces mesures particulières.
Figure 4 : perte ICMP observée pendant chaque période de temps. Un taux de retransmission plus élevé correspond à une perte plus importante.
Ici, nous voyons que les seuils inférieurs montrent rarement une perte, avec 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 des niveaux où le rapport de retransmission correspond à des impacts significatifs de débit (par exemple 0,25) entraînent une faible 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 soulignent la capacité du ratio 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 ratio de retransmission, une métrique sommaire pratique qui peut être facilement calculée avec les données disponibles à partir des données de socket xTCP. Nous avons également montré qu’il fournit un aperçu clair des cas dans lesquels les performances applicatives sont affectées et où des interventions réseau sont nécessaires.
Le taux de retransmission est devenu un élément clé de notre processus de surveillance, fournissant un aperçu clair des performances du système, sans avoir besoin de traiter des journaux d’applications plus volumineux et plus encombrants ou de s’appuyer sur des sondes ICMP qui ne parviennent pas à capturer certains impacts.
Nos travaux en cours explorent comment rendre la mesure aussi sensible que possible pour fournir un avertissement précoce des dégradations, tout en fournissant une entrée appropriée pour des systèmes d’automatisation plus complexes.
Un grand merci aux équipes Architecture et Ingénierie de fiabilité réseau 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.
