Contexte

Nous étions récemment chez l’un de nos clients qui vient juste d’installer une appliance APS dans son data Center.

Son infrastructure était plutôt simple :

• tous leurs serveurs de production étaient dans un data center,

• Les utilisateurs étaient localisés soit au siège social (où se trouve le data center) soit sur l’un de leurs sites distants (environ une centaine). Ces sites étaient tous connectés au siège social par un réseau MPLS.
• Ils font partie d’un grand groupe, dont le data center est connecté au même nuage MPLS, qui fournit l’accès à plusieurs services centraux comme le DNS, la messagerie électronique (Lotus Notes) et une passerelle internet sécurisée.

Illustration 1 : Topologie  réseau simplifiée

Rappels

Retransmission de paquets

Les paquets sont renvoyés après avoir été soit perdus soit endommagés.

La retransmission de paquets est identifiée grâce à leur séquence TCP, à leur numéro de séquence et aux valeurs du checksum. Seul les paquets ayant une charge utile non-nulle sont vérifiés.

Délai de retransmission

Intervalle de temps entre un paquet et la dernière retransmission

RD signifie «Retransmission Delay » soit retard dû à la retransmission. RD est défini comme étant le temps entre un paquet et sa dernière retransmission.

Illustration 2 : Calcul du délai de retransmission

Taux de retransmission

Ratio des paquets retransmis sur nombre total de paquets

RR signifie «Retransmission Rate » soit Taux de retransmission. RR est défini comme un ratio des paquets retransmis sur le nombre de paquets dans une conversation.

Illustration 2 : Calcul du retard du à la retransmission

Ce que nous avons observé

Le responsable réseau de notre client nous faisait part de la plainte d’un de ses utilisateurs finaux, situé sur un site distant. Il se plaignait d’être victime de lenteur d’accès à une application située sur le data center. En regardant le graphique de la performance de l’application, nous avons observé une somme significative de Retransmission Delay (du serveur vers le client) et aucun autre changement à part une légère augmentation du DTT (temps de transfert des données) pour l’application en question.

Illustration 3: Exemple de graphique de performance d'application

Nous avons élargi notre champ d’investigation en regardant dans le graphique de la performance du réseau et en nous attachant à toutes les applications (pour les clients situés sur des sites distants et les serveurs du datacenter) : nous avons pu observer que les temps de Retransmission Delay étaient hauts quel que soit l’application utilisée. Mais aussi que le «Retransmission Delay » (RD) était impacté principalement dans la direction du serveur vers le client.

Illustration 4 : Exemple de graphique de performance réseau

Nous avons fait l’hypothèse qu’il devrait y avoir des congestions entre le data center et le site distant dans la direction suivante : Data center → site distant. En conséquence, nous avons regardé le graphique APS relatif à la bande passante pour étudier le trafic entre le data center et le site distant.

Nous avons fait l’hypothèse qu’il devrait y avoir des congestionsentre le data center et le site distant dans la direction suivante : Data center → site distant. En conséquence, nous avons regardé le graphique APS relatif à la bande passante pour étudier le trafic entre le data center et le site distant. Nous avons observé un pic de trafic (principalement dû à Windows SUS) qui atteignait 1.2 Mbps; ce qui nous a permis de comprendre que notre client avait un dysfonctionnement dans la mise en œuvre de sa priorisation de flux.

Notre client a trouvé cette valeur de 1.2 Mbps intéressante bien que, pour lui, ce ne soit pas au premier coup d’œil, quelque chose qui lui permette de déterminer si cela était bien une congestion. Car en effet, la bande passante disponible sur le site distant était de 2 Mbps (et le maximum de bande passante disponible sur le data center était de 80 Mbps et seulement une très faible quantité de cette bande passante était utilisée).

Nous avons donc décidé de nous pencher sur le graphique SNMP fourni pour le routeur du site distant par son opérateur telecom. Ce graphique de bande passante, nous a permis de voir que le trafic entrant de 2Mbps sur 30 minutes, était constant.

Conclusion sur le sens des retransmissions

Les retransmissions sont significatives et vous devriez examiner les retransmissions pour déterminer :

• si elles sont intermittentes ou continues
• quel est le périmètre à observer (de quelle (s) zone (s) client pour tous les serveurs ou pour un seul).

Nous avons appris que certains paquets n’atteignent pas les autres hôtes ou que les acquittements ne retournent pas vers l’émetteur.

Dans un sens, la direction des retransmissions (serveur → client ou client → serveur) peut être peu significative, car la congestion provoque des retransmissions dans les deux sens (par exemple, une congestion d’un serveur vers un client pourrait générer quelques retransmissions d’un serveur vers un client – les paquets envoyés par le serveur ne reçoivent pas assez rapidement l’acquittement et le serveur les retransmet – et du client vers le serveur – car même si les paquets venant du client vers le serveur arrivent assez rapidement, l’acquittement des paquets du serveur vers le client souffre d’une congestion et le client retransmet les paquets originaux). Vous devriez garder en mémoire que l’équilibre des retransmissions entre un client→serveur et serveur→client dépend aussi de l’équilibre du trafic entreces deux directions.

Conclusion relative à l’impact du «retransmission delay» sur le ressenti utilisateur

Dans les deux sens, le «Retransmission Delay» est un bon indicateur de la dégradation du réseau sur la qualité du ressenti utilisateur.

Dans un sens, le «Retransmission Delay» est guidé par la quantité de données envoyées dans cette direction. Cette valeur correspond au temps additionnel pour qu’un utilisateur puisse obtenir ses données.

La retransmission a une seconde conséquence sur le temps requis pour recevoir les données : quand il y a une retransmission, la machine réinitialise ses fenêtres TCP et la taille du buffer à sa taille minimum par défaut. Cela signifie qu’à chaque fois qu’il y a une retransmission, le débit revient à un niveau très bas puis augmente progressivement. Si la retransmission est fréquente alors le débit revient toujours au niveau minimum et n’atteint jamais le niveau optimal. Ceci provoque alors un temps de transfert des données plus important, car le débit pour transférer une réponse applicative reste très lent. Ce phénomène est-ce que nous appelons communément le TCP Slow-Start (voirhttp://en.wikipedia.org/wiki/Slow-start)