E T U D E E X P É R I M E N TA L E D U S Y S T È M E
T D C N
11
P R É S E N TAT I O N D E L A P L AT E - F O R M E D E T E S T S L’étude théorique précédente a mis en évidence de multiples intérêts à mettre en oeuvre notre système. Cependant, l’ensemble des résultats obtenus repose sur une modélisation théorique. Lors de l’établissement du modèle, nous avons dû poser des hypothèses et effectuer des simplifications. Dans le cadre de la validation du modèle, nous avons réalisé une maquette afin de vérifier la pertinence des hypothèses prises. D’autre part son second objectif est d’apporter des informations sur la qualité de service qui n’a pas été modélisée.
11.1 la plate-forme de tests
Générateurs de connexions TCP/ UDP Client A Client B Système de Métrologie/Asservissement Régulateurs d'accès Client C Régulateurs d'accès
Figure 31:Schéma du testbed
L’objectif de la plate-forme est de retrouver l’ensemble minimal des composants permettant la mise en oeuvre du système TDCN. L’envi-ronnement d’un WAN est émulé afin de retrouver les comportements TDCN identique à celui que l’on aurait dans le cadre d’un déploiement de la technologie. On retrouvera également les générateurs nécessaires
76 présentation de la plate-forme de tests
à l’établissement des flux représentatifs des agrégats réels. Enfin la maquette reposera également sur la mise en place d’un système de métrologie le plus complet possible.
Afin d’observer le système en phase de congestion, la maquette se compose de trois routeurs : un point de congestion est alors créé sur le routeur central afin de simuler une saturation de coeur de réseau. Afin de réaliser cette congestion, nous effectuons une limitation du débit d’émission sur l’interface de sortie du routeur de coeur (limite à 80Mb/s).
11.2 création de l’environnement de tests 11.2.1 le générateur d’agrégats
Figure 32:Générateur de session NetworkTester
Le système TDCN est conçu pour être déployé dans un réseau de transport mutualisé. Afin de retrouver les comportements de flux clients et plus particulièrement les propriétés d’élasticité des flux, nous utilisons un générateur industriel de sessions TCP.
L’équipement utilisé est un générateur NetworkTester de la société Agilent. Celui-ci permet d’émuler des applications basées entre autre sur TCP. Nous avons plus particulièrement utilisé ses capacités à émuler des sessions clients/serveurs FTP. Notre but était uniquement de profiter des capacités TCP et de contrôler le nombre de connexions TCP simultanées. Ce nombre de session étant l’un des principaux paramètres influençant le partage de la bande passante, nous pouvons ainsi étudier le comportement du système TDCN dans différentes conditions de régimes.
11.3 implémentation du système tdcn 77
11.2.2 L’émulateur WAN
L’environnement d’un réseau transport mutualisé est bien différent de celui retrouvé dans un laboratoire. Afin de reproduire les effets de cet environnement, nous utilisons un émulateur. Celui-ci a pour principal objectif de recréer une latence dans le réseau afin que les comportements des sessions TCP soient plus représentatifs de la réalité. Nous avons donc utilisé un serveur Windows dédié disposant du programme NetDisturb edité par Omnicor afin de réhausser la latence du réseau. Nos tests ont été effectués avec un délai réseau de 20ms. 11.3 implémentation du système tdcn
11.3.1 Les routeurs
Figure 33:Routeur7450ESS1
La réalisation de notre maquette a été effectuée avec des routeurs de coeurs Alcatel-Lucent. Le choix s’est porté sur l’utilisation de routeurs industriel dont nous connaissions parfaitement le dimensionnement de la capacité de commutation ainsi que celle de ses différentes cartes porteuses. Ces routeurs disposent également d’une stack MPLS com-plète incluant la gestion des VPN. Ils possèdent également la capacité pour les ports d’accès au VPN de gérer près de16000 files d’attentes différentes et autant de QoS d’accès. Ce qui le rend particulièrement intéressant pour notre système qui prévoit l’utilisation de régulateur dédié à chaque tunnel.
78 présentation de la plate-forme de tests 11.3.2 Description de l’architecture VPN PPVPN PO R T SD P PPVPN D e Mu x D e Mu x SD P SAP PO R T SAP
Police d'accés Police d'accés
Figure 34:Architecture Générique d’un VPN
Dans le cadre de leur utilisation normale, les routeurs cloisonnent leur clients dans des services VPN différents. Chaque service VPN (fig.
34) de ces routeurs est composé de plusieurs éléments :
– Service Access Point (SAP) :Entité rattachée à un port ou à un
VLAN d’accès. On peut lui appliquer une politique particulière de qualité de service.
– Service Distribution Point (SDP) :Entrée du tunnel MPLS . Il a
pour charge d’émettre les paquets dans le réseau. Il peut posséder des règles de filtrage spécifique en fonction de la nature des flux.
– Demux : Il récupère les paquets des tunnels MPLS. Traite les
informations MPLS et les retourne dans le service PPVPN en correspondance.
– Sap-ingress policy : Police d’accès des SAP. Réserve un espace
mémoire pour le SAP. Gère la colorie par le biais d’un TRTCM [17]. Le même mécanisme existe également en sortie de SAP (Sap-egress policy).
Notre Système TDCN utilisera cette architecture, un service TDCN sera un VPN point à point disposant de polices d’accès spécifiques.
11.3 implémentation du système tdcn 79
11.3.3 L’emulateur TDCN
Etant donné que les routeurs ne supportent pas nativement notre nouveau système expérimental, nous avons été contraint d’externaliser sur un serveur Linux les briques nécessaires à la mise en oeuvre de notre système TDCN. Trois composants sont ajoutés :
– Des contrôleurs de congestion dans les routeurs de coeur chargés de détecter une éventuelle congestion.
– Un protocole de signalisation des congestions.
– Des régulateurs d’accès dynamiques prenant en compte les infor-mations transmises par le protocole de signalisation.
Pour ce faire, nous avons utilisé des automates logiciels qui inter-rogent et contrôlent les routeurs sur un réseau de management dédié. Ceux-ci récupèrent les informations et modifient le comportement du routeur par le biais du protocole SNMP. Ce fonctionnement entraîne toutefois une moins grande réactivité. Nous verrons par la suite quelle peut être l’impact de cette méthode sur les résultats.
Les contrôleurs de congestion
Le contrôleur de congestion est situé au niveau de chaque port de coeur de réseau. Il contrôle en permanence l’état des buffeurs. Il retransmet ensuite l’information de cet état toutes les secondes au protocole de transport d’information.
En théorie, il faut contrôler l’état des buffeurs Egress de l’interface qui se rempliront dans le cadre de la congestion de la liaison mais également les buffeurs Ingress des interfaces qui eux se rempliront lorsqu’une congestion du coeur de commutation apparaît. Dans la pratique, la capacité de commutation maximum de nos routeurs n’est pas sous dimensionnée, et cette congestion ne peut pas apparaître.
Implémentation des DAR
Afin de réaliser les DARs, nous avons utilisé des TRTCMs [17] inclus au niveau des Sap Ingress policy des routeurs. Nous avons ensuite piloté via le protocole SNMP la valeur du PIR de celui-ci. Ainsi, le CLA de notre système correspond à la valeur courante du PIR du TRTCM. Le LLA est lui représenté par le CIR du régulateur.
En théorie, ces TRTCM devraient être appliquées au niveau de policy appliqués sur les SDP. Cependant, cette configuration n’est pas faisable matériellement d’où sa mise en oeuvre sur le SAP. Cette modification n’entraîne aucune conséquence dans le cadre d’un VPN point à point.
80 présentation de la plate-forme de tests
Par contre, elle empêcherait l’utilisation de VPN multipoints. Dans le cadre de l’industrialisation du procédé, il conviendrait de disposer les mécanismes sur le SDP.
Le protocole de transport d’information
L’ajout ou la modification d’un protocole au niveau des routeurs implique nécessairement un recodage de celui-ci. Aussi nous avons choisi d’émuler le comportement du protocole. Nous avons co-localisé les programmes des contrôleurs de congestion et des DARs sur le serveur GNU/Linux avec une transmission d’informations par le biais de variables partagées. Pour autant, les divers codes sont désynchroni-sés tout comme ils le seraient si leurs codes étaient inclus dans leurs routeurs respectifs.
11.3.4 Défaut de l’externalisation du code
11.4 métrologie de la plate-forme de tests 81
Du fait de l’utilisation d’un OS non temps réel et également à cause des délais sur le réseau de management, les DAR n’agissent pas toutes les secondes précisément. La figure35montrent un exemple de variation de délai entre2passes de l’algorithme. Ces courbes devraient en théorie être des droites constantes à1seconde. Cette variation serait largement atténuée si le code était inclu directement dans les routeurs. 11.4 métrologie de la plate-forme de tests
11.4.1 Métrique du routeur
Le routeur dispose pour chacun des ports des informations sui-vantes : compteurs d’octets, de paquets et de drops. Ces compteurs sont rafraîchis toutes les secondes. Mais, il est également possible de connaître l’état des buffeurs des ports d’accès et de coeurs (fig. 36) pour chaque file d’attente.
Port de coeur de réseau
Etat du buffeur egress de la classe de service BE
82 présentation de la plate-forme de tests
Afin de suivre l’évolution de ces informations, des automates d’inter-rogations ont été réalisés pour nous permettre de mesurer l’évolution de ces valeurs. Contrairement aux autres compteurs, l’interrogation de l’état des buffers prend entre400 et600ms et donne une information sur un état instantané.
La figure37est un exemple d’évolution d’un buffeur suite à l’appa-rition d’une congestion de coeur.
Figure 37:Evolution d’un buffeur egress sur un port en coeur d’un routeur dispo-sant d’une liaison congestionnée
11.4.2 Le générateur de débit
Afin de mesurer les performances des systèmes mis en place, nous avons utilisé un générateur de trafic N2X de la marque Agilent. Cet équipement génère des paquets IP auxquels il ajoute un timestamps d’horloge dans la payload. A l’aide d’un second port, il récupère ces paquets et peut ainsi mesurer la latence, la gigue, le taux de pertes, les désordonnancements, le tout avec une précision de7picosecondes.
11.4 métrologie de la plate-forme de tests 83
12
T E S T B E D D U S Y S T È M E T D C N
Le chapitre précédent nous a permis d’exposer le fonctionnement de la plate-forme de test mettant en oeuvre l’approche TDCN. Dans ce chapitre nous allons utiliser cette plate-forme pour valider la mo-délisation effectuée et mesurer les performances réseaux du nouveau système.
12.1 comparaison entre les résultats de la maquette et de la modélisation
Courbes théoriques Courbes pratiques
Figure 39:Comparaison entre les résultats sur la maquette et dans la modélisation
L’établissement de la modélisation des chapitres précédents a été réalisée sur la base des principes théoriques issue des mécanismes mis en oeuvre. La complexité des flux réels et les simplifications que
86 testbed du système tdcn
nous avons dû opérer pour établir le modèle, nous amènent à vérifier l’adéquation entre notre approche théorique et une mise en oeuvre pratique.
Pour ce faire, nous avons étudié l’évolution des CLA des régula-teurs du système TDCN dans le cadre de notre plate-forme de test ; puis nous allons comparer ces résultats face à l’estimation de cette évolution via la modélisation. Dans une première approche, nous ne nous focaliserons pas sur les débits réels présents dans chaque VPN mais uniquement sur l’évolution des régulateurs. Nous positionnerons simplement suffisamment de connexions TCP en concurrence pour initier une congestion.
La figure 39 compare les résultats théoriques et pratiques dans le cadre de deux systèmes paramétrés différemment. On constate sur le graphique que les résultats de la modélisation, bien que plus lissés que ceux mesurés en pratique, donnent une bonne estimation de l’évolution réelle des CLA.
Ce lissage s’explique facilement par le fait que la modélisation considère à tort une action simultanée de tous les régulateurs. L’effet de la désynchronisation se traduit par une variation plus importante des CLA. Par contre, le délai d’équilibrage est légèrement surévalué dans le cadre de la modélisation.
12.2 étude des flux
12.2.1 Fonctionnement en régime établi
Nous avons précédemment validé le bon comportement des régu-lateurs. Nous allons maintenant nous attacher à vérifier l’évolution des flux réels inclus dans ces tunnels. Nous utiliserons pour ce faire le système de métrologie défini dans le chapitre précédent pour étudier l’évolution des débits clients.
L’exemple présenté dans la figure40a été réalisé sur la base de trois tunnels TDCN dans lesquels chaque client utilise des connexions TCP simultanées. Dans l’exemple retenu, le premier client a été configuré pour exécuter 30connexions TCP simultanées. Les deux autres clients ont été configurés pour exécuter chacun cinq connexions TCP.
Dans une première étape, Nous avons mesuré l’utilisation de la bande passante pour chaque client dans un réseau classique Best-effort sans mis en place de notre système. Dans un second temps, nous avons réitéré les mêmes mesures avec notre réseau TDCN.
12.2 étude des flux 87 Client LLA: 8Mb/s and 30 TCP connections Client LLA: 16Mb/s and 5 TCP connections Client LLA: 8Mb/s and 5 TCP connections
Best-effort Network TDCN Network
Figure 40:Evolution du trafic client dans un réseau BE et TDCN
On peut remarquer que dans le réseau classique le partage est effectué au prorata du nombre de connexions TCP. De nombreuses études donnent aussi le même type de résultat [24], et décrivent les mécanismes de partage du réseau. Ils soulignent en particulier la dépendance entre la notion de partage et la quantité de connexions TCP.
Cette situation est particulièrement gênante pour un opérateur, puisque des clients disposant de contrats identiques ne pourront pas revendiquer la même bande passante. Un client dit "non-citoyen" pour-rait dans certains cas de figure être tenté d’augmenter virtuellement son nombre de connexions TCP afin de récupérer plus de bande pas-sante au détriment des autres clients.
Le système TDCN a justement été conçu pour empêcher la nature des flux d’influer sur le partage de la bande passante. La figure40met bien en évidence cette nouvelle indépendance aux flux. En outre, la bande passante est partagée proportionnellement au paramétrage des LLA des régulateurs. La figure 41montre que tous les clients ont des taux de LLA à CLA identiques, ce qui signifie que la bande passante supplémentaire a été équitablement répartie entre les différents clients, indépendamment du nombre de connexions TCP.
Dans la pratique, les flux clients sont contraints individuellement par les limitations données par les régulateurs DAR. Il n’existe alors aucune possibilité pour les clients de se substituer à cette limite.
88 testbed du système tdcn
Client LLA:8Mb/s TCP : 30 connexions
Client LLA: 8Mb/s TCP : 5 connexions
Client LLA: 16Mb/s TCP : 5 connexions
Figure 41:Evolution du rapport LLA/CLA des régulateurs dans le réseau TDCN
12.2.2 Etude en phase d’équilibrage
Nous avons vu précédemment par le biais de la modélisation que notre système possède une phase transitoire au niveau des régulateurs. Dans cette partie, nous focaliserons notre attention sur l’évolution des trafics clients durant cette période. Afin de contrôler l’évolution lors de cette phase, nous allons initier une congestion dans le coeur de réseau en établissant simultanément les trafics clients. La configuration mise en oeuvre est reprise du test effectué dans le chapitre précédent. Au cours de l’essai, nous avons étudié le débit utilisé pour chaque client (figure 42). Dans le même temps, l’évolution des valeurs CLA a été enregistrée pour chaque régulateur. (Figure43).
A l’initialisation de la congestion, nous observons que tous les trafics se partagent la bande passante de la liaison. Ce partage de bande passante est similaire à celui qui aurait eu lieu dans un réseau classique best-effort(voir figure40).
Par la suite les régulateurs vont agir face à cette congestion en durcissant leur politique d’accès. Le trafic, précédemment le plus favorisé par le partage best-effort, sera le premier impacté et devra réduire son utilisation de la bande passante. Dans le même temps, la bande passante libérée sera réallouée entre les autres clients qui n’avaient pas atteint leurs limites.
12.2 étude des flux 89
Client with 30 TCP connections and LLA: 8Mb/s
Client with 5 TCP connections and LLA: 16Mb/s
Client with 5 TCP connections and LLA: 8Mb/s
Figure 42:Evolution du trafic client en phase transitoire
Regulator with LLA: 16Mb/s
Regulator with LLA: 8Mb/s Regulator with LLA: 8Mb/s
90 testbed du système tdcn
On constate également que les flux TCP subissant le durcissement de politique des DAR ne rompent pas leurs connexions et suivent la pente donnée par le régulateur. Ce comportement est rendu possible car l’échelle de temps de la variation des régulateurs est significativement supérieure à celle des connexions TCP (facteur 100).
12.3 étude des performances globales 12.3.1 Evaluation des performances par client
Les résultats précédents ont mis en évidence la capacité de notre sys-tème à fournir une équité contractuelle lors d’une période de conges-tion après une phase transitoire. Dans cette partie nous allons étudier les performances qui découlent de ce fonctionnement dans un cas extrême ou la garantie contractuelle est inversement proportionnelle au nombre de connexions des flux clients.
L’expérimentation suivante se compose de sept tunnels TDCN mis en concurrence, chaque client disposant d’un nombre différent de connexions TCP. Chaque connexion TCP effectue le téléchargement d’un fichier de 5 Mo, une fois la connexion terminée une nouvelle connexion est rétablie (18fois pour chaque connexion).
Nous mesurons le temps pour finaliser l’ensemble des téléchar-gements pour chaque client et nous calculons ainsi le débit moyen obtenu en pratique par client. Nous effectuons l’expérience dans le cadre d’un réseau classique BE puis dans le cadre de notre proposition d’architecture.
Les résultats obtenus sont synthétisés dans le tableau1. Ce test dure quelques minutes. Afin d’étudier l’évolution à plus long terme de la performance, un deuxième test a été réalisé, fondé sur le même paramétrage excepté pour le nombre de téléchargements qu’on réitère 200fois. L’expérience dure alors plus d’une heure.
Nous pouvons observer dans le tableau1, que tous les clients ne sont pas en mesure de respecter le contrat minimum LLA. Ce phénomène s’explique par le fait que pendant la phase de transition, le partage de la bande-passante est effectué au pro-rata des connexions TCP. Il s’agit donc d’un partage diamétralement opposé à celui souhaité dans ce cas particulier. Toutefois, même dans ce cas exagérément négatif, les résultats sont bien meilleurs que pour le réseau Best-effort (le client dispose d’un débit trois fois supérieur à celui qu’il aurait eu en Best-effort).
12.3 étude des performances globales 91
Table 1: Performance par client pour18téléchargements successifs
Customers LLA Concurrent
TCP connec-tions Duration TDCN Average TDCN rate Average BE rate 1 14Mb/s 1 101s 7,1Mb/s 2,4Mb/s 2 12Mb/s 2 132s 10,9Mb/s 4,7Mb/s 3 10Mb/s 3 170s 12,7Mb/s 7,1Mb/s 4 8Mb/s 4 210s 13,7Mb/s 9,4Mb/s 5 6Mb/s 5 250s 14,4Mb/s 11,8Mb/s 6 4Mb/s 6 280s 15,4Mb/s 14,2Mb/s 7 2Mb/s 7 345s 14,6Mb/s 16,5Mb/s
Table 2: Performance par client pour200téléchargements successifs
Customers LLA Concurrent
TCP connec-tions Duration TDCN Average TDCN rate Average BE rate 1 14Mb/s 1 555s 14,4Mb/s 2,4Mb/s 2 12Mb/s 2 1025s 15,6Mb/s 4,8Mb/s 3 10Mb/s 3 1485s 16,2Mb/s 7,2Mb/s 4 8Mb/s 4 2005s 16,0Mb/s 9,4Mb/s 5 6Mb/s 5 2480s 16,1Mb/s 12,1Mb/s 6 4Mb/s 6 3185s 15,1Mb/s 14,5Mb/s 7 2Mb/s 7 3485s 16,1Mb/s 16,9Mb/s On peut remarquer également que, même sans tenir compte des contraintes liée au LLA, six des sept clients ont un débit moyen su-périeur à celui qu’ils auraient obtenu dans un réseau Best Effort. Ce
92 testbed du système tdcn
phénomène s’explique par le fait qu’une fois le téléchargement d’un