Oui, la QoS des WAN MPLS est utile…

Fr-C18-prioritaire_sur_circulation_inverse

Pourquoi payer plus cher son réseau d’entreprise ? Pour la qualité bien sûr ! Encore faut-il le prouver… En termes de Qualité de Service réseau, tout le monde comprend bien les SLA (Service Level Agreement) de disponibilité (99,98% du temps par ex.), de Garantie de Temps de Rétablissement (en moins de 4h par exemple), de débit garantit (2 Mbit/s 100% du temps, zéro contention dans le backbone typiquement), mais pour la priorisation des applications, il est beaucoup plus délicat de se figurer ce que cela apporte.

La QoS « Applicative » priorise quoi ?

D’abord, on priorise quoi ? C’est quoi « Applicative » ? En fait, il ne s’agit d’application que du point de vue des couches OSI 3 et 4, c’est à dire les adresses IP (client ou serveur) et les ports (TCP/UDP). C’est en fait tout ce que comprend un routeur ordinaire dans lequel on va définir des ACL IP source/destination et Port source/destination. Point. Il n’y a pas encore de Deep Packet Inspection dans les offres de base des MPLS (les opérateurs ajoutent des boitiers spécialisés si vous voulez de la QoS plus avancée).

La QoS Applicative MPLS est une priorisation de Bande Passante

Ensuite, sur quoi cette QoS va-t-elle agir ? Et bien, ça peut dépendre des opérateurs mais en gros, il y a 2 catégorie de QoS MPLS : 1. La QoS Voix et Video (RT-Vo et RT-Vi) garantit la Bande Passante (largeur du tuyau) ET la latence (longueur du tuyau en millisecondes), voire la Gigue (fluctuation de latence en millisecondes), car VoIP et Visio sont sensibles à ces 3 facteurs. 2.  La QoS Data garantit uniquement la bande passante dans 3 ou 4 Classes, c’est à dire des files d’attente pour les paquets de données. Mais cette garantie a aussi un effet sur la latence et c’est le point délicat.

La QoS MPLS est une solution « de crise »

Oui, et pour 2 raisons : 1. Elle n’est en fait active que lorsqu’on congestionne 100% de la bande passante ! Or 100% de charge dans un réseau, c’est une congestion, c’est à dire une crise dans le réseau… 2. Elle gère sa bande passante dans chaque Classe par des pertes de paquets excédentaires dans chacune des files d’attente. Et ça, jeter des paquets, dans le monde des réseaux, c’est très mal ! C’est une crise. Cela signifie que cette QoS n’anticipe rien, elle réagit, au mieux, quand il est déjà trop tard. Vous allez donc penser que ce n’est pas terrible comme fonctionnalité pour ce qu’on la paye… Peut-être, mais au moins, elle la gère la crise, et c’est déjà une très bonne chose. Démonstration.

La QoS MPLS gère les grosses et petites crises… et c’est bien !

La crise peut être longue, par exemple un flux récréatif (qui à dit Youtube ?) peut saturer l’accès. Ou extrêmement courte, par exemple avec des micros « bursts » qui « tapent » le max de bande passante, créant des micros congestions avec des micros pertes. Ce second cas est quasi invisible, fréquent, aléatoire, et peu avoir des conséquences sur la qualité et la performance perçues par les utilisateurs de certaines applications : Citrix, Microsoft TSE très classiquement. C’est là que la QoS MPLS gère la crise efficacement dans tous les cas avec 2 bénéfices : 1. elle écoule les files avec plus ou moins de bande passante et donc certaines applications s’en tirent mieux 2. en conséquence, elle jette des paquets des applications plus ou moins nombreux en fonction de ces files Le problème, c’est que quand les files sont pleines, on attend ! Et même lorsqu’on est « prioritaire », à 100% de capacité, on attend un peu quand même. L’avantage tout de même d’une file qui s’écoule plus vite que les autres, c’est qu’en bonus, la latence du réseau est moindre (les paquets attendent moins en somme). Et ça c’est très bon pour des tas d’applications interactives comme Citrix, TSE et le web moderne (Ajax & co). Voici un petit cas réel, mesuré sur un environnement SI fortement publié en TSE. Une erreur de configuration réseau à fait « sauter » la QoS MPLS, laissant tout en « Classe AF11 » non prioritaire. Les utilisateurs se plaignaient des performances régulièrement. L’erreur a été détectée grâce à un instrument de métrologie et de mesure de performance réseau. Et rapidement corrigé par l’opérateur. Les 3 Classes de Service Data AF31, AF21, AF11/12 sont réapparues pour prioriser les applications dont MS-TSE. DSCP TSE Ainsi lorsque l’on observe la latence du réseau (NRT – Network Round-trip Time), uniquement pour TSE, on constate qu’elle est en moyenne divisée par 2 ! puisque TSE emprunte désormais une file prioritaire à chaque fois qu’il y a une micro congestion quelque part dans l’ensemble du réseau. NRT TSE La latence réseau et le point clé en Citrix et MS-TSE pour que les utilisateurs perçoivent un usage fluide de l’application publiée. Cette QoS a donc un effet très sensible sur la performance utilisateur alors même que Citrix ou TSE ne sont pas très gourmands en bande passante. Alors oui, la QoS MPLS, c’est bien. C’est beaucoup mieux que rien… (qui a dit IPSec ?) Est-ce qu’on peut faire mieux ? Etre plus pro-actif pour éviter d’arriver à la « crise » ? Bien sûr ! Pour cela, il faut des solutions plus spécialisées en QoS que des routeurs WAN, et un peu de conseil d’experts sur le sujet… Pour ça, vous être au bon endroit : prenons contact !