MtoM Mag - Le journal de l'MtoM.
- accueil .
- newsletter .
Flux RSS . - soumissions .
- publicité .
- contacts
Flux RSS .
La qualité de service du réseau est l’un des éléments les plus importants pour obtenir la satisfaction client pour la clientèle « entreprises » d’un opérateur réseau. En général, la garantie du niveau de service, ou SLA (pour Service Level Agreements) des services Ethernet fournis à ce type de clientèle (concernant l’utilisation de services tels que la vidéo conférence, YouTube, Facebook ou les applications en ligne) sont basés sur des attributs des couches 2 et 3. Dans ce contexte, les paramètres pertinents sont la bande passante, la latence, la gigue et les pertes de paquets, pour lesquelles les opérateurs réseau et les fournisseurs de service (FAI) vérifient actuellement leurs réseaux en appliquant des tests de type IETF RFC 2544 ou ITU-T Y.1564.
Cependant, certains utilisateurs se plaignent de débits insatisfaisants, malgré les bons résultats indiqués par ces tests de performances. Ce scénario peut être le fruit de plusieurs autres facteurs, comme des éléments du réseau non optimisés ou mal configurés pour la connexion TCP (Transmission Control Protocol).
Le débit est l’un des paramètres essentiels en termes de performances pour un service Ethernet, et est défini comme la bande passante maximale atteignable sans aucune perte de trame.
Quand deux appareils du réseau veulent échanger des informations, une série de protocoles est requise pour permettre aux applications de communiquer avec succès. La quasi-totalité des connexions utilisent le protocole TCP orienté connexion pour les communications sur la couche d’application entre deux extrémités du réseau. Par conséquent, pour obtenir la bande passante effectivement disponible pour l’utilisateur final, le FAI doit adapter les tests de débits aux exigences de la couche TCP.
La figure 1 illustre le modèle de référence Internet (basé sur le modèle DoD du Department of Defence). Elle illustre l’écart existant entre les méthodes de test RFC2544/Y.1564 et les attentes du client par rapport à l’expérience utilisateur, au niveau de la couche d’application. Le seul moyen de résoudre ce problème pour le FAI est de vérifier les performances de la couche TCP. Autrement, les plaintes des clients seront inévitables, accompagnées des appels au support technique et des interventions sur site allant de pair, sans compter la perte de clientèle ou les fluctuations dans le nombre d’abonnés. Outre l’impact négatif sur la satisfaction et la fidélité du client, les coûts d’exploitation peuvent également augmenter.
Par ailleurs, les processus de gestion de la qualité de service (QoS, Quality of Service) sur les couches 2 et 3 peuvent affecter le débit TCP à cause de la nature impulsionnelle des signaux de l’application TCP (émis par salves), et l’utilisation de systèmes d’ordonnancement du trafic peut générer des pertes de trames.
Le protocole TCP (Transmission Control Protocol, soit « protocole de contrôle de transmission ») est une connexion de bout en bout en mode Full duplex qui permet la transmission d’informations dans les deux directions simultanément. Chaque connexion TCP peut être identifiée à l’aide de deux paramètres, fournis par une paire structurée, constituée d’une adresse IP et d’un port. Ainsi, une connexion TCP est déterminée par :
L’adresse IP de la source
Le port de la source
L’adresse IP de destination
Le port de destination
Une connexion TCP est établie grâce à un mécanisme communément appelé three ways handshake, prenant la forme de l’émission des drapeaux SYN/SYN-ACK/ACK, pour se terminer par FIN, ACK. Si un client veut établir une connexion, un signal SYNC est envoyé au serveur, qui répond avec un drapeau SYN-ACK suivi du l’accusé de réception ACK du client.
Pour des raisons de sécurité, un pare-feu « dynamique » conserve en général une trace des états des connexions du réseau. Ainsi, c’est uniquement après l’accusé de réception ACK du client que la connexion peut être authentifiée et identifiée comme bidirectionnelle et considérée comme « établie » par le pare-feu.
En conséquence, il est essentiel pour l’équipement de mesure de baser une connexion TCP sur un protocole dynamique, puisque seuls les paquets correspondants à une connexion active connue seront autorisés par le pare-feu. Tous les autres seront rejetés, avec pour conséquence que la connexion ne sera pas établie.
La libération de la connexion se passe de manière similaire. Au lieu du drapeau SYN, un drapeau FIN est utilisé pour indiquer qu’’il n’y aura plus de données envoyées par l’émetteur. La réception est confirmée avec un drapeau ACK suivi d’un FIN (ou ACK-FIN abrégé en un seul paquet).
La procédure de test spécifiée dans le RFC 6349 se décompose en trois étapes :
Déterminer le Path MTU (Maximum Transmission Unit) pour s’assurer que l’appareil sous test est correctement configuré et éviter toute fragmentation.
Mesures du RTT minimum (temps de propagation aller-retour, Round-Trip Time) et de la bande passante offerte sur le chemin du réseau point à point. Les résultats permettent d’estimer la taille de la fenêtre de réception TCP RWND et celle du tampon d’envoi, utilisées pour les étapes suivantes du test.
Test de débit de la connexion TCP.
Le protocole TCP est orienté connexion et utilise une fenêtre de congestion TCP du côté « émission ». Pour informer le côté émission du nombre d’octets que le récepteur peut accepter pour une période de temps donnée, une fenêtre de réception TCP est utilisée. Les tailles des tampons d’émission et de réception des ports (ou sockets), nécessaires pour atteindre le débit TCP maximum, sont déterminées par le produit délai-bande passante (BDP, Bandwidth*Delay Product). Afin de ne pas limiter les performances TCP, l’instrument de mesure TCP doit posséder la capacité de fixer le tampon d’envoi et la fenêtre de réception du port à des valeurs plus élevées que le BDP. À partir du taux d’affaiblissement sur le chemin du réseau, du démarrage lent (Slow Start) et de l’algorithme d’évitement de congestion (figure 3), la TCP CWND (fenêtre de congestion) peut être calculée.
Le tampon d’envoi du socket doit être ajusté selon la même valeur à chaque extrémité du réseau, afin d’obtenir des résultats optimums. Enfin, le débit TCP peut être calculé. En général, les opérateurs réseau testent leurs réseaux suivant les documents de référence RFC2544 et/ou Y.1564 pour vérifier les SLA (Service Level Agreement). Or, compte tenu des facteurs exposés ci-dessus, les performances de la connexion TCP ne peuvent être vérifiées ainsi avec précision. Seul un test du débit TCP basé sur le référentiel RFC6349 peut permettre aux utilisateurs finaux de configurer leurs réseaux en émulant les éléments du réseau de l’utilisateur final.
Une fois que le MTU a été découvert et que le temps de propagation aller-retour (RTT) a été testé, la taille de fenêtre optimisée est testée en vérifiant le débit TCP à différentes étapes et en affichant les résultats, tel que sur la figure5.
Figure 5 – Balayage de fenêtres (gauche) et Débit TCP (droite) à différentes étapes.
Le débit TCP idéal calculé et le débit TCP testé sont affichés avec des informations telles que les octets retransmis, le délai de propagation, etc. Des graphiques représentant le débit TCP/temps et d’autres paramètres peuvent être indiqués, ce qui aide les utilisateurs à identifier les problèmes éventuels d’un simple coup d’œil. Il est possible de mener des tests bidirectionnels afin d’afficher les performances du débit TCP sur des réseaux asymétriques, ce qui permet d’émuler de manière plus réaliste des réseaux réels.
Les FAI doivent également faire face au problème de l’allocation des serveurs et réseaux avec les performances atteignables maximales. Comme ces services se trouvent souvent sur des connexions TCP, un outil logiciel de test de débit TCP est utilisé.
iPerf est un outil de test réseau couramment utilisé avec une fonctionnalité client et serveur. Cependant, celui-ci dépend des performances du terminal de l’utilisateur final, qui ont également une influence sur sa reproductibilité. Les instruments de test modernes comme les testeurs de terrain portables MT1000A/MT1100A de Anritsu utilisent des tests de débit TCP fondés sur le matériel associés à un serveur iPerf connecté pour une meilleure fiabilité et une excellente précision (figure 6).
Comme expliqué dans cet article, même si les tests des couches 2/3 peuvent être passés avec succès, la méthode de test choisie peut conduire un client à se plaindre des mauvaises performances d’une application (navigation, envoi de fichiers, etc.) à cause des lenteurs du réseau. On peut voir sur la figure 7 un aperçu de plusieurs scénarios de test en fonction de différents problèmes rencontrés par le réseau.
Enfin, il convient de souligner que les méthodes de test utilisées sur les couches 2/3 et pour le test de débit TCP doivent être considérées comme complémentaires. Pour une évaluation complète, il est recommandé d’utiliser toutes les méthodes de test disponibles.
Pour résumer, la mise en œuvre de la méthode de test du RFC 6349 devrait permettre de réaliser une procédure de mesure automatisée exhaustive, de telle sorte que même les techniciens débutants puissent effectuer une mesure et générer un rapport détaillé en quelques minutes à peine. Ces tests peuvent être réalisés à l’aide d’instruments de mesures comme les MT1000A/MT1100A de Anritsu, qui permettent d’effectuer les tests de débit TCP en plus des tests RFC 2544 et Y.1564, pour une analyse détaillée des performances du réseau. Ces tests permettent d’améliorer la qualité des réseaux complexes.
