Une Architecture de Différentiation de Service dans l’Internet : Théorie et Mesures

Universit Pierre et Marie CurieLaboratoire LIP6

Institut National des TlcommunicationsDpartement RST

Rapport de Stage

Une Architecture de Diffrentiation de Service dans lInternet :Thorie et Mesures

Prsent par :Abed-Ellatif SAMHAT

Encadr par :Dr.Tijani CHAHED

Pr. Grard HEBUTERNE

DEA rseauxMultimdia et QoS

Septembre 2001

Table des matires

TABLE DES MATIERES

CHAPITRE 1 INTRODUCTION........................................................................................................... 1

1. LE MODLE INTSERV................................................................................................................................ 12. LE MODLE DIFFSERV .............................................................................................................................. 1

CHAPITRE 2 LE MODLE DIFFSERV ................................................................................................ 3

1. CARACTRISTIQUES DU MODLE DIFFSERV............................................................................................... 32. FONCTIONNEMENT DU MODLE DIFFSERV ............................................................................................... 33. ROUTEUR DENTRE (EDGE ROUTER)......................................................................................................... 5

3.1 Classification..................................................................................................................................... 53.2 Vrification........................................................................................................................................ 53.3 Actions ............................................................................................................................................. 63.4 Rgulation du trafic.......................................................................................................................... 6

3.4.1 Leaky Bucket .............................................................................................................................. 73.4.2 Token Bucket.............................................................................................................................. 7

4. ROUTEUR DU COEUR DU RSEAU (CORE ROUTER)..................................................................................... 74.1 Comportements Standardiss.......................................................................................................... 8

4.1.1 Acheminement Expdi ( EF Expedited Forwarding)............................................................ 84.1.2 Acheminement Assur (Assured Forwarding)........................................................................ 8

4.2 Mcanismes de diffrentiation........................................................................................................ 94.2.1 Les ordonnanceurs.................................................................................................................... 9

4.2.1.1 First In First Out (FIFO) ...................................................................................................... 94.2.1.2 Round Robin et Weighted Round Robin (WRR)............................................................. 104.2.1.3 Weighted Fair Queuing (WFQ)........................................................................................ 104.2.1.4 Priority Queuing (PQ)....................................................................................................... 104.2.1.5 Class Based Queuing (CBQ) ............................................................................................. 11

4.2.2 Gestion des files dattente ....................................................................................................... 124.2.2.1 Random Early Detection (RED) ....................................................................................... 124.2.2.2 Weighted Random Early Detection (WRED) .................................................................. 13

5. CONCLUSION.......................................................................................................................................... 13

CHAPITRE3 IMPLMENTATION DE DIFFSERV: TESTS ET MESURES ...................................... 14

1. PLATE-FORME DIFFSERV ........................................................................................................................ 142. LOGICIELS POUR DIFFSERV ..................................................................................................................... 15

2.1 Les disciplines de services supportes par ALTQ....................................................................... 152.2 Le fonctionnement de ALTQ ......................................................................................................... 172.3 Les gestionnaires de files dattentes ............................................................................................. 18

3. LOGICIELS DE GNRATION DU TRAFIC ET DE MESURE ........................................................................... 193.1 Gnration de trafic........................................................................................................................ 19

3.1.1 Netperf...................................................................................................................................... 193.1.2 Iperf .......................................................................................................................................... 19

3.2 Logiciels de mesures et dobservation........................................................................................ 194. IMPLMENTATION DE LA DIFFRENTIATION DE SERVICES ...................................................................... 19

4.1 Actions ledge ............................................................................................................................. 204.1.1 Marquage du trafic .................................................................................................................. 204.1.2 Implmentation dun Token Bucket ....................................................................................... 20

Table des matires

4.1.3 Rgulation du trafic UDP........................................................................................................ 204.1.4 Rgulation du trafic TCP......................................................................................................... 21

4.2 Actions dans le Core....................................................................................................................... 224.2.1 FIFO First In First Out ............................................................................................................. 224.2.2 CBQ Class Based Queueing .................................................................................................. 24

4.2.2.1 CBQ non Work Conserving............................................................................................. 244.2.2.2 CBQ Work Conserving ..................................................................................................... 30

4.2.3 PQ (Priority Queueing) ........................................................................................................... 325. CONCLUSIONS ........................................................................................................................................ 36

CHAPITRE 4 AGRGATION DES FLOTS ........................................................................................ 38

1. DFINITION DE LAGRGATION .............................................................................................................. 382. PROBLMATIQUE .................................................................................................................................... 383. MODLE ET ANALYSE ............................................................................................................................. 38

3.1 Courbes de services, Approche dterministe ............................................................................... 393.2. Courbes de services, Approche stochastique............................................................................... 403.3 Approche stochastique , modle Markovien ................................................................................ 413.4 Discussion ....................................................................................................................................... 42

4. ETUDE EXPRIMENTALE.......................................................................................................................... 424.1 Tests et Rsultats ............................................................................................................................ 43

5. CONCLUSION.......................................................................................................................................... 45

CHAPITRE 5 OFFRE DE SERVICE EF................................................................................................ 46

1. INTRODUCTION ...................................................................................................................................... 462. DFINITION DU EF PHB......................................................................................................................... 46

2.1 Description intuitive de EF ........................................................................................................... 462.2 Dfinition formelle de EF PHB (PSRG) ........................................................................................ 47

3. PSRG ET LES COURBES DE SERVICES........................................................................................................ 484. DISCIPLINE DE SERVICE POUR EF............................................................................................................ 49

4.1 Priority Queueing PQ.................................................................................................................... 494.2 Weighted Round Robin (WRR) ..................................................................................................... 51

5. IMPLMENTATION DU SERVICE EF.......................................................................................................... 515.1 Implmentation de EF par PQ ..................................................................................................... 525.2 implmentation de EF par CBQ................................................................................................... 535.3 Rsultats des tests........................................................................................................................... 54

6. CONCLUSION.......................................................................................................................................... 55

CHAPITRE 6 CONCLUSIONS ET PERSPECTIVES.......................................................................... 57

RFRENCES ............................................................................................................................................. 59

Chapitre 1 : Introduction 1

Chapitre 1 Introduction

LInternet existant est fond sur le principe du Best Effort. Le modle Best Effort assure laconnectivit sans aucune garantie de la qualit de service (QoS). Quand la mmoire dun routeurest sature, les paquets arrivant sont rejets. Les mcanismes de retransmission de TCP recouvrentces pertes, garantissant un transfert sans faute de bout en bout. Bien que le comportement de TCPrpond aux besoins dapplications traditionnellement majoritaires dans le rseau comme telnet ouftp, il est peu adapt pour la transmission des flux avec des contraintes temporelle (applications devisioconfrence ou de Voix sur IP (VoIP)). La discipline de service FIFO nest plus suffisante poursatisfaire les contraintes requises par les diffrentes applications. Les congestions allongent lesdlais, gnrent de la gigue et provoquent la perte des paquets.

Pour rpondre ces demandes damlioration de la QoS dans lInternet, lIETF cra en 1994plusieurs groupes de travail destins dfinir une architecture Intgration de Services. Dans unetelle architecture il est possible de garantir le taux de perte et le dlai dacheminement observs parun flux individuel, tout en contrlant la distribution de ressources entre les flux.

1. Le Modle IntServ

Le modle IntServ, issu des travaux de standardisation, dfinit deux nouveaux services: Garanti(GS) et charge Contrl (CL), mieux adapts aux nouveaux besoins des utilisateurs et desapplications. La philosophie de ce modle repose sur la rservation de ressources sur tous lesrouteurs traverss et pour chaque flot. Pour effectuer cette rservation par flot, le protocole designalisation RSVP (ReSerVation Protocol) a t dvelopp. RSVP tablit et maintient un tatlogiciel entre les n uds constituants le chemin emprunt par les paquets. Par opposition larservation d'un circuit statique (par exemple l'tablissement d'un circuit virtuel), cet tat logicielest caractris par des messages priodiques de rafrachissement envoys le long du chemin pourmaintenir l'tat de rservation.

Au niveau technique, la rservation de ressources par flot prsente des difficultsdimplmentation et des limitations de dploiement. Le dploiement grande chelle de RSVP seheurte la difficult de grer un grand nombre dutilisateurs (scalability). Plus il y a dutilisateursde IntServ/RSVP, plus il y a dtats crer et maintenir pour des destinations diffrentes chaquefois. Le rafrachissement des rservations gnre lui seul une quantit de trafic substantielle. Lecot introduit par la gestion des tats et lordonnancement par flot peut entraner une rductionconsidrable de leur performance.

2. Le Modle DiffServ

Du fait que la signalisation de IntServ opre au niveau de chaque flot, le modle nest passcalable , donc le groupe de travail DiffServ qui a t cr en 1997, bnficie des travaux de IntServet tente de dpasser les difficults rencontres dans le modle intserv. Le modle DiffServ [1]introduit la notion de lagrgation des flots en quelques classes offrant des services spcifiques paragrgat (per Aggregate). Dans ce modle il ny a pas de rservation de ressources travers lesn uds, tel que ATM ou IntServ, mais un traitement diffrenci, appel PHB ( Per Hop Behavior)qui est bas sur la priorit par classe pour rpondre la QoS demande. Autre que le best effort,deux services sont dfinis: Expdi (Expedited Forwarding) et assurs (Assured Forwarding).

Chapitre 1 : Introduction 2

La mise en uvre de la QoS par classes de services ncessite limplmentation dans lesrouteurs des mcanismes capable de rendre compte de la priorit, et assurant le contrled'admission. L'architecture gnrique pour un domaine DiffServ fait la distinction entre le systmequi constitue le c ur du rseau (core) ou routeurs internes du domaine, et les systmes ralisantl'accs aux rseaux terminaux (edge) ou routeurs de frontire du domaine. Les fonctionsprincipales des routeurs constituant le core consistent acheminer les paquets aussi vite quepossible selon la priorit de la classe du paquet, cette priorit est traduite par l'tiquette du champDS (DiffServ) de l'en-tte IP. Une autre fonction est de construire et changer les informations deroutage avec ses voisins. Les routeurs d'accs se chargent des fonctions de conditionnement, decontrle d'intgrit et d'admission des paquets dans le rseau.

Le but de ce travail est de proposer une architecture de diffrentiation de services dans lecontexte des applications multimdia qui ncessitent une QoS, tant au niveau thorique qu'auniveau de sa mise en uvre sur un testbed DiffServ. Nous nous focalisons plus particulirementsur les deux fonctionnalits essentielle de DiffServ, savoir lagrgation des flots conditionns l'edge et la prioritisation de ces agrgats dans le core. D'abord, lagrgation. Celle-ci sentendsouvent en termes dterministes o les diffrents paramtres de Tspec (Traffic Specification) sontgrossirement additionns sans ncessairement tenir en compte le comportement rel des flux, quipeut tre assez variable, lintrieur de lagrgat. Cette notion est donc trs diffrente de la notionde multiplexage que lon connat dans lATM. Le multiplexage exploite les caractristiquesstatistiques des sources et tire sa force du gain statistique que cela permet. Lagrgation sentendsouvent en termes dterministes o les diffrents paramtres de Tspec (Traffic Specification) sontgrossirement additionns sans ncessairement tenir en compte le comportement rel des flux, quipeut tre assez variable, lintrieur de lagrgat. Une tude stochastique versus dterministepermettra de mieux comprendre lagrgation, par rapport au multiplexage, et surtout de mesurerson impact sur les micro-flux en terme de profil de trafic (dbit et burst size). Le deuxime pointabord dans ce travail est la notion de prioritisation. Dans DiffServ, la priorit permet untraitement relatif des agrgats afin de rpondre la problmatique de scalability rencontre dansla rservation par flot. Cette notion est diffrente de la notion de rservation de ressources commedans IntServ ou ATM: le routeur core DiffServ prioritise les paquets appartenants aux diffrentsagrgats les uns par rapport aux autres en fonction de leur niveau de priorit; la priorit d'unpaquet dtermine sa probabilit d'limination en cas de congestion. Il s'agit donc d'tudier lesdiffrents mcanismes susceptibles d'assurer cette priorit par opposition la plus traditionnellerservation de ressources.

Ce rapport est organis de la faon suivante : Nous dcrivons dans le deuxime chapitre lesmodules de bases qui peuvent servir la construction de larchitecture DiffServ, ainsi que lesalgorithmes dordonnancements et de gestion des files dattente. Dans le chapitre trois, nousmontrons l'implmentation de la priorit par des algorithmes dcrits en deuxime chapitre et lamise en pratique dautres modules (conditionnement, etc), l'aide de l'outil d'implmentationALTQ (Alternative Queueing). Dans le chapitre quatre, nous tudions lagrgation des flots ledge dun domaine DiffServ par des approches thoriques et des exprimentations . Noustraitons dans le chapitre cinq l'offre de service EF (Expedited Forwarding) mise en uvre parl'architecture propose. Pour terminer, le chapitre six prsente une conclusion et des perspectivesde ce travail.

Chapitre 2 : Le modle DiffServ 3

Chapitre 2 Le modle DiffServ

Le modle DiffServ, en cours de standardisation lIETF, propose une capacit

de diffrentiation de services base sur des mcanismes simples et scalables.

Ce chapitre est une description des caractristiques de ce modle, des services

qui en drivent, ainsi que les mcanismes qui peuvent servir la mise en uvre

de DiffServ.

1. Caractristiques du modle DiffServ

Pour comprendre les dcisions qui ont t prises par le groupe de travail, il faut se rappeler desmotivations qui ont men la cration du modle DiffServ; A savoir, lincapacit de larchitectureIntServ, couple la signalisation RSVP, se voir dploye grande chelle et le besoin danslInternet des mcanismes damlioration de la QoS. Si les problmes que les modles DiffServ etIntServ cherchent rsoudre sont les mmes comme le traitement prvisible des flux multimdia etun meilleur contrle dans la distribution de la bande passante, le modle DiffServ sattaque cescontraintes d'une manire plus rsistante. Dans ce modle, la simplicit d'implmentation permet cette nouvelle architecture de se voir dploye progressivement dans certaines rgions del'Internet.

Une des faiblesses du modle IntServ est sa non-rsistance au facteur dchelle (scalability).Dans ce modle, tous les quipements du rseau doivent garder un tat par flux rserv. Il suffitquun n ud dans la route nimplmente pas les fonctionnalits IntServ pour que la QoS ne puisseplus tre strictement garantie. Dans larchitecture DiffServ, la priorit est donne au regroupementdes flux dont les besoins sont similaires (agrgat) et la dfinition des traitements ncessaires dansles routeurs pour que l'agrgat soit trait correctement.

Pour assurer la robustesse du modle DiffServ, la cration d'tats et la classification par flot sontdeux fonctionnalits rserves aux routeurs dentre au rseau. Dans ces quipements, le nombrede flots traiter est considrablement rduit et un bon dimensionnement doit suffire pour assurerque la capacit ne sera pas dpasse. Dans le reste des routeurs des oprations trs simplesassurent le traitement diffrenti.

Du point de vue conomique, labsence de rservation de ressources permet aux oprateursdoffrir de nouveaux services tout en gardant un systme de tarification simple. Au niveau de lamise en uvre, la priorit a t donne l'utilisation des mcanismes dordonnancement (CBQ,WFQ.. ) et de gestion active de file dattente ( RED, WRED..). De nombreuses expriences ont djt menes pour dterminer leurs capacits et leurs limites. En plus, le standard dfinissantlarchitecture est assez ouvert pour accueillir des nouveaux algorithmes pouvant servir ladfinition de nouveaux services.

2. Fonctionnement du modle DiffServ

Dans le modle DiffServ, il nexiste pas de signalisation dans le c ur du rseau: seule unetiquette dans len-tte, le champ DSCP (DiffServ Code Point), est utilise pour assurer letraitement diffrenti. Cette capacit permet aux routeurs de garder un mode de fonctionnementrelativement simple qui naffecte pas considrablement leur capacit dacheminement. La


complexit est reporte sur les routeurs de frontire, se trouvant lentre ou la sortie dundomaine [1]. Ces quipements sont chargs de dterminer la valeur de ltiquette de chaque paqueten fonction dun contrat du service demand et des mcanismes de contrle de trafic. Le DSCPoccupe les six bits de poids fort du champ DS (DiffServ) de len-tte IP. La figure (2.1) montrelemplacement de ce champ. En IPv4, il se substitue lancien champ ToS; en IPv6, il se situe laplace du champ Traffic Class.

Version IHL DS Longueur TotaleIdentification Flags Offset du FragmentTemps de Vie Protocole Checksum en-tteAdresse SourceAdresse DestinationOptions ... Padding

Figure 2.1 : En-tte dun paquet IP.

Il est plus facile de comprendre lutilit des divers outils qui forment le modle si, avantdentrer dans les dtails de larchitecture, un exemple de fonctionnement est prsent.

La Figure (2.2) montre une configuration de rseau trs simple. Un site metteur, souhaitantque ses flux bnficient, dun traitement diffrenti dans le rseau, tablit un contrat de serviceavec son fournisseur. Ce contrat, appel SLA (Service Level Agreement), contient la nature dutrafic que lmetteur peut produire pour chaque service demand. Dun ct, le fournisseur deservice sengage fournir la qualit demande par le client. De son ct, le client est conscient deslimitations imposes par le contrat.

Figure 2.2 : Architecture DiffServ.

Le client peut effectuer un pr-marquage de ses flux avant de les transmettre au fournisseur.Signaler une prfrence en termes de classe de service ou indiquer limportance relative despaquets sont deux raisons qui justifient cette action. La priorit des paquets peut varier au seindun flux. Par contre, les principes de DiffServ exigent que tous les paquets dun mme fluxappartiennent une mme classe de service afin dviter le dsquencement.

Le fournisseur connat les spcifications techniques du contrat tabli avec chacun de sesclients. Quand le trafic produit par lutilisateur arrive au routeur dentre du fournisseur, les fluxsont identifis et leur comportement est vrifi en fonction du contrat respectif. En cas de non-conformit, une action corrective est prise. Pour certains services, seuls les paquets conformes aucontrat peuvent entrer dans le rseau. Pour dautres services, tous les paquets sont accepts, maisle routeur dentre modifie la priorit du paquet en fonction du niveau de conformit. En quittant


le routeur dentre, les paquets du site metteur contiennent tous une tiquette, refltant la classede service souhaite et le niveau de conformit du flux par rapport au contrat.

Les routeurs de cur du rseau ne modifient pas les tiquettes, ils se contentent de les utiliserpour choisir la file dattente o le paquet est insr. Pour cet exemple, la file dattente reprsente laclasse de service. Les ressources des routeurs sont distribues entre les files en fonction des servicesquils supportent. Dans chaque file dattente, un algorithme de rejet slectif est utilis pourliminer en premier les paquets de basse priorit en cas de congestion.

Cet exemple entre un site et un fournisseur daccs peut sappliquer galement deuxoprateurs. En gnral, les paquets doivent traverser plusieurs domaines administratifs avantdatteindre leur destination; un accord est donc ncessaire entre domaines. Les capacits desrouteurs de sortie constituent une autre particularit de linterconnexion entre deux domaines. Unrouteur de sortie est le dernier routeur travers par un paquet avant de quitter un domaine. Cesrouteurs peuvent tre chargs de traiter lagrgat des flux quittant le domaine pour rendre le traficconforme au contrat existant avec le prochain domaine

3. Routeur dentre (edge router)

La structure dun routeur dentre peut tre dcompose en modules comme le prsente lafigure (2.3) . Toute la complexit de larchitecture est concentre dans ce type dquipements. Ilsdoivent effectuer une classification qui peut aller jusquau niveau du flot. Une fois le flux identifi,il est ncessaire de vrifier la conformit au contrat en utilisant un mcanisme adapt au servicedemand. Ensuite une action est prise pour pnaliser les paquets non conformes et la valeur duDSCP est actualise en fonction du conditionnement subi. Dans tous ces modules, des mesurespeuvent tre faites selon lobjectif. Ds que les flots ayant la mme valeur DSCP se rencontrent,on dit quils sont agrgs. Donc lagrgation des flots se fait dabord dans un routeur dentre.

Figure 2.3 : Modules dun routeur dentre.

3.1 Classification

Pour que les diffrents flux produits par les utilisateurs puissent tre traits dune manirediffrentie, le routeur dentre doit tout dabord effectuer une classification des paquets. Dans lemodle DiffServ, cette opration est trs similaire celle dfinie pour larchitecture IntServ . Elle sebase toujours sur des champs de len-tte, mais le nombre des champs utilis pour lidentificationpeut varier en fonction du contrat. Dans le modle DiffServ, la classification peut aller jusquauniveau des microflux.

3.2 Vrification

Un vrificateur est charg de dterminer le niveau de conformit pour chaque paquet du fluxarrivant dans le routeur. Cette valeur dpend du comportement instantan du flux et des

Classification VrificationTB, TCM ..

Actionmark,drop, .

Mesure


caractristiques du contrat. Le nombre de niveaux varie en fonction du conditionnement requis parle service:

- Pour des services bas dlai, il est ncessaire que seuls les paquets conformes au contrat soientaccepts dans le rseau. Dans ce cas, une vrification deux niveaux est suffisante: conforme ounon-conforme, IN ou OUT.- Pour des services profitant de la capacit dlimination slective dans le c ur du rseau, unnombre suprieur deux augmente la granularit de la diffrentiation. Dans la dfinition duComportement Assur, 3 niveaux de priorit ont t dfinis: vert, orange et rouge.

3.3 Actions

Laction corrective prendre pour les paquets non conformes dun flux varie en fonction duservice. Trois types de pnalisation peuvent tre identifis: limination, mise en forme etmarquage.

Llimination est sans doute laction la plus svre, mais ncessaire au bon fonctionnement decertains services. Pour un flux dont les paquets non conformes sont limins lentre, il peut tresouhaitable de contrler le dbit dmission. Des flux interactifs contenant des contraintestemporelles fortes pourraient tirer profit de ce type daction.

La mise en forme consiste retarder, si ncessaire, lacheminement dun flux pour le rendreconforme. Cest une action trs coteuse en termes des ressources pour le routeur dentre, quidevra garder dans un tampon tous les paquets retards jusqu ce quils deviennent conformes.

Le marquage par simple considration est la mise du code ou tiquette convenable dans lechamp DSCP. Avant dentrer dans le rseau, le champ DSCP de tous les paquets qui traversent lerouteur dentre est mis jour. La valeur de cette tiquette est le rsultat des oprations deconditionnement. Le DSCP qui forme ltiquette DiffServ ne doit pas tre modifi par les routeursdu coeur du rseau. Les routeurs de frontire peuvent quant eux, modifier cette valeur lors desnouveaux conditionnements ou dun problme de smantique entre deux domaines voisins.On entend encore par marquage, laction qui attribue une prcdence ou priorit aux paquets enfonction du rsultat de la vrification. Cette action introduit un deuxime niveau de diffrentiation,puisque les paquets sont achemins en fonction de leur classe de service et de leur priorit. Lesfonctions de vrification et de marquage sont parfois indivisibles. Elles forment le noyau desservices bass sur le Comportement Assur o le traitement que le rseau accorde un flux dpend la distribution des priorits ses paquets.

Aprs avoir pass par ces modules, les flots marqus par le mme DSCP se trouvent dans lemme agrgat et rentrent vers le core .

3.4 Rgulation du trafic

La vrification du trafic et les actions faites dans un routeur dentre sont des techniques decontrle et de rgulation du trafic permettent de contrler le volume de trafic entrant dans lerseau ainsi qu'avec le dbit avec lequel il est transmis. Donc trois critres importants sont retenirpour la spcification du taux avec lequel un flot est autoris envoyer des paquets l'intrieurd'un rseau :Le dbit moyen, le dbit crte et la taille maximum de la rafale( burst size) : elle limitele nombre de paquets qui peuvent tre transmis dans un intervalle de temps trs court.

Limplmentation de la rgulation du trafic se fait par un LB (Leaky Bucket) ou par un TB (TokenBucket).


3.4.1 Leaky Bucket

Le trafic entrant dans la file (le seau) est rgul pour sortir dbit constant sur le rseau. Lataille du seau et le dbit en sortie sont configurables par l'utilisateur. La taille tant dterminante ence qui concerne les pertes de paquets (lorsque le seau est plein le trafic entrant peut tre jet).Leleaky bucket est compos d'un compteur c, d'un seuil t et d'un taux de vidage, le leaky rate : r.Chaque fois qu'un paquet arrive dans le seau, le compteur est incrment et ce mme compteur estdcrment par le leaky rate. Si un paquet arrive au moment ou c=t ; alors celui-ci est jet.

3.4.2 Token Bucket

Le trafic ne traverse pas directement le seau mais il est transmis sur la base de jetons prsentsdans le seau. Un jeton correspond un nombre de bits donne, le taux d'arrive des jetonscorrespond au dbit moyen r ou j et la profondeur du seau la taille de la rafale b ou s (voirFigure (2.4)) .

Ce mcanisme permet un trafic en rafale d'tre transmis tant qu'il y a des jetons dans la filed'attente, ceux-ci ayant pu tre accumuls en situation de rseau peu charg.

Figure 2.4 : Token Bucket.

4. Routeur du cur du rseau (core router)

A la suite des traitements effectus dans le routeur d'entre, les paquets sont injects dans lerseau la base des agrgats. Les oprations propres aux routeurs du c ur du rseau sontrelativement simples, mais celles-ci vont dterminer les performances du rseau, en termes depertes et de dlai, observs par les sites terminaux . Lun des objectifs du groupe DiffServ est destandardiser le traitement des paquets dans ces routeurs en fonction du champ DS. Tous lespaquets portant une mme valeur dans ce champ doivent tre traits de la mme manire ( mmeagrgat ou classe ).

Le traitement diffrenti dans le c ur dun rseau DiffServ implique deux axes: les classes deservice et la notion de priorits. La Figure (2.5) montre larchitecture logique dun routeur capabledoffrir ces deux niveaux de diffrentiation. Il est compos dun classificateur, de plusieurs filesdattente, dun mcanisme dordonnancement et dun algorithme de gestion de file dattente pourchaque file.

Figure 2.5 : Architecture dun routeur diffrentiation de service

Trafic entrant Trafic rgul

Dbit de jetons r Taille du seau b

Classificateur

Ordonnanceur

Gestion des files dattentes


Le classificateur que lon trouve dans ce type de routeurs ralise une classification beaucoupmoins coteuse que ceux qui se trouvent lentre du domaine. Dans ce cas, les paquets sontdiffrentis uniquement en fonction de ltiquette quils portent, cest--dire, de la valeur du champDS attribue par le routeur dentre. Une partie de cette tiquette sert identifier la file dattentesur laquelle le paquet doit tre insr, pendant quune autre partie de celle-ci peut tre utilise parlalgorithme de gestion de file dattente pour amliorer la discrimination en cas de congestion.Chacune des files dattente dans les routeurs reprsente une classe de service. Leurs proprits, entermes de bande passante ou de retard moyen observ, dpendent du mcanismedordonnancement(CBQ, WFQ)

A lintrieur de chaque file, un mcanisme de gestion doit dcider la manire dont les paquetsseront limins en cas de congestion. Par exemple, pour une classe de service bas dlai, qui nedevraient jamais observer des pertes (thoriquement), la traditionnelle mthode FIFO (first in, firstout) peut tre utilise. Par contre, pour les files correspondant aux classes AF, le standard demandela mise en uvre dune mthode capable de discriminer les paquets en fonction de leurprcdence. Des mthodes comme WRED ou RIO peuvent tre utilises pour assurer cette fonction( voir section 4.2.2 ).

4.1 Comportements Standardiss

Autre que le Best-effort deux types de comportements ou PHBs ont t standardiss:Acheminement Expdi ( EF Expedited Forwarding) et Acheminement Assur ( AF AssuredForwarding). Il faut remarquer que, pour chaque PHB standardis, les valeurs de DSCP proposesne sont que des recommandations. A lintrieur dun domaine ladministrateur est libre de choisirles valeurs qui facilitent la mise en uvre du modle. Ceci demande pourtant, limplantation desmcanismes de re-marquage lentre du domaine pour faire la correspondance entre les DSCPslocaux et leurs quivalences dans les domaines voisins.

4.1.1 Acheminement Expdi ( EF Expedited Forwarding)

LAcheminement Expdi, [2], [3], a t conu comme tant le composant dun service bienspcifique: le service Premium. Le service Premium ou circuit virtuel est destin aux applicationsdemandant un dlai, une perte et une gigue trs faibles tel que le ncessitent des applicationstemps rel comme la tlphonie sur IP. Il part du principe que le dlai introduit par le rseau est d lattente des paquets dans les files des routeurs.

Il faut donc garantir que la taille de ces files soit presque nulle. Pour ceci il est ncessaire demettre en uvre des mcanismes qui assurent que, tout moment, le dbit dentre soit infrieur la capacit de sortie. Le DSCP recommand pour EF est: 101110 . Le chapitre cinq dtaille ceservice .

4.1.2 Acheminement Assur (Assured Forwarding)

LAcheminement Assur [1] est le PHB le plus gnral qui existe. Il est compos de plusieursclasses de service au sein desquelles un deuxime niveau de diffrentiation est introduit: lesprcdences. La notion de prcdence existait dj dans la smantique du champ ToS (mais la miseen correspondance des prcdences du ToS avec les Slecteurs de Classe DiffServ, bien que valable,ne suit pas le mme principe). La prcdence dun paquet reflte sa priorit, cest--dire, ledommage que peut entraner sa perte. Au sein dun routeur cette information peut tre utilisepour amliorer considrablement la fonction de rejet de paquets en cas de congestion. Suivant lemme principe, la prcdence attribue aux paquets dun flux peut tre rgie par un contrat deservice. Plus le pourcentage des paquets marqus prioritaires sera important, moins le flux subirade pertes.


Le groupe de travail DiffServ dfinit 4 classes comportant 3 niveaux de prcdence chacune.LAcheminement Assur est donc compos par un groupe de 12 PHBs interdpendants. Ceci veutdire que limplmentation dun de ces PHBs est inutile sans limplmentation des autres. Aprs delongues discussions, il a t dcid quaucune relation dordre de priorit ne devrait exister entreles classes. Ladministrateur rseau est responsable du partage des ressources entre les classes enfonction de ses besoins. Par contre, il est ncessaire que tous les paquets dun mme microfluxappartiennent la mme classe pour viter le desquencement des paquets.

En ce qui concerne la prcdence, dans une mme classe, les paquets de prcdence X soientrejets avec une probabilit suprieure celle donne aux paquets de prcdence Y, si X < Y. LesPHBs qui forment le comportement AF sont identifis par AF ij , o i dnote la classe (1 4) et jdnote la prcdence (1 3). Le Tableau (2.1) prsente les codes DSCP proposs pour reprsenterles PHBs AF.

PHBs AF ij classe 1 classe 2 classe 3 classe 4

prcdence 1 001 010 010 010 011 010 100 010

prcdence 2 001 100 010 100 011 100 100 100

prcdence 3 001 110 010 110 011 110 100 110

Tableau 2.1 : les DSCP proposs pour les PHBs AF.

4.2 Mcanismes de diffrentiation

Dans lInternet Best-effort, les routeurs ne diffrencient pas entre les paquets du trafic : unrouteur de base est compos de processus asynchrones ayant pour fonction dassembler lespaquets reus (file d'attente en entre), puis contrler l'intgrit du paquet (calcul duchecksum) et dterminer l'interface de destination, enfin transmettre les paquets (filesd'attente en sortie). Les paquets passent dans les files suivant le discipline de service FIFO.

L'architecture DiffServ fait la distinction entre le systme global haut dbit qui constitue lec ur du rseau (core ), et les systmes ralisant l'accs aux rseaux terminaux (edge). Lesrouteurs d'accs se chargent des fonctions de contrle d'intgrit et d'admission des paquetsdans le rseau ( mcanismes de rgulation, test de conformit ) . Les fonctions principalesdes routeurs constituant le core, consistent construire, changer les informations de routageavec ses voisins et acheminer les paquets aussi vite que possible, ce qui ncessite une gestionsophistique des files dattente en sortie . On peut parler des mcanismes dordonnancement(scheduler ) , de gestion des files dattentes .

4.2.1 Les ordonnanceurs

4.2.1.1 First In First Out (FIFO)

C'est la mthode standard de gestion de trafic entre une interface d'entre et une interface desortie. Les paquets sont placs dans la file de sortie dans l'ordre dans lequel ils sont reus.C'est aussi la discipline la plus rapide du point de vue de la vitesse de transmission despaquets, tant donn qu'elle n'effectue aucun traitement sur ceux-ci. Dans un environnementrseau avec une forte capacit, cette technique est efficace, le dlai de mise en file d'attente despaquets tant alors insignifiant par rapport au temps de transmission de bout en bout, car onpeut considrer que les files restent presque toujours vides. En revanche, en situation derafales, la file d'attente dborde et les paquets suivants sont rejets. Une source agressiveoccupe plus.


4.2.1.2 Round Robin et Weighted Round Robin (WRR)

Lobjectif de la technique service tour de rle (Round Robin) est dassurer une rpartitionquitable de la bande passante entre les flux. La Figure (2.6) montre lide : les paquets sont trispar classes dans des files, ensuite, un tourniquet alterne les paquets servir parmi les filesprsentes. Dans sa forme la plus simple, avec trois classes de paquets, on obtiendrait le traficsuivant : paquet de classe 1 transmis, suivi d'une classe 2, puis d'une classe 3, suivi d'une classe 1 ..,donc un paquet la fois chaque tour. Lallocation de la bande passante est en apparencestrictement gale pour chaque file, mais cette technique ne prend pas en compte la taille despaquets (taille variable dans le monde IP). Les paquets de grande taille prennent plus de temps deservice.

Figure 2.6 : Ordonnanceur tour de rle ( Round Robin).

Pour garantir un partage vritablement quitable, une variante de round robin, dite Bit par BitRound Robin (BBRR), propose le traitement des files bit par bit tour de rle. Cette techniquepartage galement la bande, mais en pratique on opre au niveau paquet. Pour cela,lordonnanceur fait sortir les paquets des files dattentes avec une frquence gale celle dont ilsauraient bnfici si les files avaient t servies bit par bit.

4.2.1.3 Weighted Fair Queuing (WFQ)

Le partage quitable pondr est une mulation du round robin bit bit, bas sur lalgorithme GPS(Generalized Processor Sharing) [17] : chaque file dattente est servie avec un poids qui reprsenteune fraction garantie de la bande passante. Ce poids peut se traduire par un nombre de paquetsmis par tour de service ou, par une frquence et un schma de service particulier.L'implmentation de la politique de caractrisation du flux est dpendante du constructeur: ellepeut par exemple utiliser les bits IP Precedence dans le champ TOS de l'en-tte du paquet pourtrier les paquets.

Ce mcanisme de tri est dpendant du constructeur car le champs IP Precedence peut avoir desinterprtations diffrentes et donc tout dpend de ce qu'entend le constructeur dans le termeweight. En revanche, ce systme de mise en file d'attente par flot peut nous amener rencontrercertains problmes de scalability. Driv de WFQ, SFQ (Stochastic Fairness Queueing) [18] est unesolution au problme de scalability de WFQ, cette solution limite le nombre de file d'attente enagrgeant les flots grce un processus alatoire ou bien des critres bien dfinies.

4.2.1.4 Priority Queuing (PQ)

C'est la forme primitive de la diffrenciation de service. En effet, sous ce type d'ordonnancement,les paquets arrivant sur le lien de sortie sont classifis en une, deux, voire plusieurs classes sur lafile de sortie. La classe d'un paquet dpend alors d'un marquage explicite se trouvant dans l'en-ttemme de celui-ci. Par exemple, en prenant en compte le champs TOS d'IPv4, ou alors en prenant en

3

Ordonnanceur

Clas

classificateur

1

2


compte les autres donnes prsentent nativement dans l'en-tte comme l'adresse source -destination, le port source - destination, ou un autre critre.

Figure 2.7 : Priority Queueing.

Comme le montre la figure (2.7) pour deux classes, chaque classe a sa propre file d'attente. Leserveur choisira d'abord un paquet se trouvant dans la file d'attente haute priorit, si celle-ci estnon vide avant ceux se trouvant dans la file basse priorit.

La granularit de classification se basant sur l'en-tte mme du paquet est assez flexible. Enrevanche, ce systme implique une dgradation des performances. Il peut y avoir un problmelorsque le trafic haute priorit est trs important ; il peut y avoir rejet des paquets du trafic normal cause de la taille de la file d'attente basse priorit.

L'autre problme qui est soulev par PQ est que le temps d'attente dans les buffers restantindtermin, on ne peut pas calculer la gigue du rseau de bout en bout. En effet, il n'est passimple, au niveau du temps de mise en attente dans les files, de dterminer au bout de combien detemps un paquet de priorit basse va tre servi, ce service ne pouvant tre fait que lorsque aucunpaquet ne se trouve en priorit haute.

4.2.1.5 Class Based Queuing (CBQ)

Lattente par classe CBQ (Class Based Queueing), propos par Jacobson et tudi par Floyd [5],permet de faire le partitionnemet et le partage de la bande passante par des classes hirarchiques.Dans [5], Sally Floyd et Van Jacobson proposent une architecture base sur le partage de lienhirarchique (link sharing), cette architecture sera implmente par Kenjiro dans ALTQ [6] . Cedcoupage de la bande passante peut tre fait en prenant en compte soit de la famille de protocolesutiliss sur le lien, soit les types de trafics applicatifs (telnet, ftp, mail, ...), ou encore diffrentesorganisations partageant le lien (voir Figure (2.8 a)).

Le but du link sharing est la classification de ces diffrents types de trafic afin d'oprer unpartage de la bande passante entre ces trafics comme le montre la figure (2.8). Chaque classe, avecune demande correspondante ses besoins, doit tre en mesure de recevoir approximativement sabande passante alloue. Par exemple dans la Figure (2.8 b) le link-sharing ne donne aucunegarantie de bande passante pour le trafic mail.

Figure 2.8, a: trois org. partagent le lien ; b : 0% du lien est alloue pour mail.

OrdonnanceurFile haute priorit

File basse priorit

Lien

Org.B Org.C

50% 40% 10%

Org.A video

Lien

telnet ftp mail

30% 30%0%

40%


Le partage de la bande passante peut galement tre hierarchis, entre diverses organisations parexemple, comme le montre la figure (2.9) :

Figure 2.9 : partage du lien entre plusieurs org. , chaque org. regroupe des applications.

En bref, les buts de link sharing peuvent tre rsums par : Chaque classe doit prendre la bande passante alloue. Si les classes prennent leurs bandes passantes alloues, et il existe un excs de la bande

passante, cet excs ne doit pas tre distribu arbitrairement. Diffrentiation entre classes de diffrentes priorits.Lintroduction de la priorit dans le contexte de link sharing se fait par le partage de la bande

entre des classes de priorits diffrents. Cette priorit est interprte selon limplmentation deCBQ [10] .

4.2.2 Gestion Active des files dattente

En complment des techniques dordonnancements cites prcdemment, des techniques degestion active des files dattente (AQM Active Queue Management) assurent une diffrentiation etrpondent certain problme; lorsque des points de congestion se dveloppent un peu partoutdans un rseau charg, chaque flux TCP va dtecter des pertes et s'engager dans la phase decongestion avoidance. Ainsi, de nombreux flux vont repasser en mode slow start et tenter deremettre les paquets perdus, ce qui ne rsoudra en rien la congestion dj prsente car leredmarrage des flux se fera de manire synchrone. Ce phnomne connu sous le nom de globalsynchronization met en vidence l'importance de nouvelles techniques plus appropries pour laprvention de la congestion.

4.2.2.1 Random Early Detection (RED)

RED, Dtection prventive alatoire, est un algorithme de gestion active des files dattente. Sonbut est de prvenir les congestions avant quelles ninterviennent, en dtectant lavance leremplissage des buffers, sans attendre leur saturation. Le mcanisme prend linitiative de rejetercertains paquets TCP par anticipation provenant de la source la plus agressive, ce qui entrane cettesource rduire son dbit.

40%

Lien

Org.B Org.C

50% 40% 10%

Org.A

Vido mail

10%

.

Audio.

10% 1%

telnet


Figure 2.10 : Algorithme de gestion active de file dattente RED .

Le mcanisme RED est caractris par deux seuils maximal et minimal ( Max threshold et Minthreshold) oprant sur la taille moyenne (avg) de la file ( voir figure 2.10). A chaque arrive dunpaquet, un calcul de la valeur moyenne avg de la taille se fait pour obtenir la probabilit P pourque le paquet soit jet, trois cas se prsentent :

Si avg Minth, alors la probabilit P de rejet du paquet est nulle. Si Minth avg Maxth, alors on calcule la probabilit de jeter le paquet selon la formule

suivante :P = (F . Pmax) / (1 - n . F . Pmax)

Avec : - n : compte les paquets accepts dans la file depuis le dernier rejet.- Pmax : par exemple 0.1.- F = (avg - Minth) / (Maxth - Minth)

Si Maxth avg, alors la probabilit P de rejet du paquet est 1.

4.2.2.2 Weighted Random Early Detection (WRED)

Mme technique que la prcdente, de plus elle permet de dterminer quel trafic on jettegrce la prise en compte du champs IP Precedence par les routeurs et cela afin d'viter lamonopolisation des ressources par certaines classes de trafic. Cette pondration gre via cechamp permet au rseau de demander aux flux de trafic moins prioritaires de s'adapter auprofit du trafic plus prioritaire. WRED, RED pondr, est l'algorithme RED tenant en comptedes critres de priorit.

5. Conclusion

Dans ce chapitre, nous avons tudi en dtail le paradigme DiffServ afin de comprendre salogique et dgager les lments spcifiques son fonctionnement. Cette tude nous rvle que lemodle DiffServ s'appuie essentiellement sur une distinction entre l'edge et le core du rseau. Al'edge, nous retenons l'agrgation des flots et la rgulation par des Token buckets pourl'architecture que nous proposons. Une fois rgul, le trafic rentre dans le core o un traitementdiffrenti se fait, autrement dit, les agrgats sont traits avec une prioritisation relative. Cettenotion de prioritisation relative est diffrente de la rservation des ressources. Dans le chapitresuivant, nous reprenons ces lments spcifiques pour les implmenter dans un testbed.

Maxth Minth

MaxthMinth

1

Pmax

Pr de rejet

avg

Chapitre 3 : Implmentation de DiffServ, tests et mesures 14

Chapitre3 Implmentation de DiffServ: tests et mesures

Nous avons dcrit dans le chapitre prcdent les mcanismes permettant ladiffrentiation de services dans les routeurs de lInternet. Dans ce chapitre, nousreprenons les mcanismes spcifiques de DiffServ et nous les implmentons dansun testbed afin de proposer une architecture de mise en uvre. Nous montronsgalement les tests qui ont t effectus pour la mise en uvre des actionsproposes par le groupe de travail DiffServ de lIETF.

1. Plate-Forme DiffServ

La plate-forme (QoSIP) a t monte dans le laboratoire RST de lINT pour crer un domaineDiffServ. Les machines utilises dans ce travail sont montres dans le tableau (3.1), et excutent lesystme dexploitation FreeBSD.4.2 . L'architecture DiffServ (voir figure (2.2)) fait la distinctionentre les fonctions d'un routeur edge et celle d'un routeur core : Les stations ipqos1 et ipqos2 sontutilises pour gnrer le trafic, ipqos3 pour la rception, donc ces stations sont des clients. Lerouteur ipqosr supporte le fonctionnement normal de routage par le protocole RIP. Les fonctionsd'un routeur edge sont supportes sur les interfaces d'entre de ipqosr, alors que les fonctions durouteur core sont supporte sur l'interface de sortie, d'o la cration d'un domaine DiffServ.

Une fonction indispensable pour les mesures et les tests est la synchronisation des horloges desterminaux. Dans le monde IP, cette synchronisation est faite par protocole et le protocole derfrence est NTP ( Network Time Protocol). LINT dispose dun serveur fonctionnant le protocoleNTP, ce serveur consiste une rfrence de temps pour le rseau local de lINT, il est synchronisavec lextrieur par une antenne GPS (Global Positionning System) . Les horloges des troismachines ipqos1, ipqos2, ipqos3 se rfrent celle de ipqosr pour la synchronisation. Cettedernire se rfre au serveur NTP. Cette plate-forme est lie au rseau VTHD (Vraiment Trs HautDbit ) et au rseau local de lINT( figure 3.1). Le rseau VTHD est la plate-forme support del'initiative franaise pour l'Internet Nouvelle Gnration mene sous l'gide du Rseau Nationalpour la Recherche en Tlcommunications.

Figure 3.1 : plate-forme QoSIP de lINT.


Machine Carte rseau

Nom Marque CPU RAM Disquedur

Fonction Marque Type Nb

IPQoS1.int-evry.fr

Transtec 200MH 16MB 3GB Station(gnrationdu trafic)

RealTeK PCIEthernet card

Ethernet100base-T

1

IPQoS2.int-evry.fr

Transtec 800MH 32MB 30GB Station(gnrationdu trafic)

RealTeK PCIEthernet card

Ethernet100base-T

1

IPQoS3.int-evry.fr

GateWay 200MH 16MB 3GB Station(rceptiondu trafic)

3com PCIEthernet card

Ethernet10base-T

1

IPQoSr.int-evry.fr

GateWay 800MH 128MB 30GB Routeur 3com PCIEthernet card

Ethernet100base-TEthernet10base-T

2

1

Tableau 3.1 : caractristiques des machines utilises pour les tests.

2. Logiciels pour DiffServ

La gestion du trafic est une ncessit pour supporter la QoS dans le rseau IP, cette gestionconsiste la mise en uvre des mcanismes sophistiqus pour rsoudre les problmes de dlai,gigue, perte .., et pour guarantir une qualit de service ( marquage, vrification de conformit).Plusieurs mcanismes de gestion des files dattente et dordonnancement ont t dvelopps ettudis, mais le problme cest que leur implmentation nest pas vidante. Dans UNIX BSD, laseule discipline de file dattente implmente est FIFO, et il nexiste pas une mthode gnralepour implmenter une discipline de file dattente alternative.

Dans ce contexte, ALTQ [10] est un outil de recherche et de dveloppement qui a t dvelopppar les quipes de recherche de la socit SONY plus prcisment par kenjiro Cho pour tenter derpondre aux besoins. Il ajoute FreeBSD la capacit de dfinir des nouvelles techniquesdordonnancement en modifiant les fonctions de file dattente dans un grand nombre de pilotesdinterface rseau. Chaque nouvelle politique dordonnancement est un module indpendant quine demande pas la modification dautres fonctions. ALTQ supporte plusieurs disciplines deservices avec diffrents outils permettant dassurer des stratgies dordonnancement (CBQ, WFQ,PRIQ), stratgies de perte des paquets (RED, RIO), stratgies dallocation des buffers, plusieursniveaux de priorit, ainsi quun comportement non-work conserving pour les files dattentes.

2.1 Les disciplines de services supportes par ALTQ

v CBQ : limplmentation CBQ de ALTQ est base sur le modle [5] montr dans le deuximechapitre. Un partage strict de la bande passante dun n u d est la rservation des ressources parles classes, mais cette rservation est assure dans ALTQ par le fichier de configuration et non paspar des signalisations. Chaque classe a sa propre file dattente et sa partie de la bande passante.Dans cette politique de partage stricte, si le trafic dune classe nexiste pas, la bande alloue cetteclasse ne sera pas utilise par dautres trafics. On rfre cette politique par politique nonconservative par classe ( Class Based non-Work Conserving). Avec loption borrow une classepeut emprunter une partie de la bande inutilise de la classe parente ce qui assure une politiqueconservative (Work Conserving).


Les principales modules de limplmentation de CBQ sont montrs par la figure (3.2)

Le classificateur : classe les paquets sur les classes prdfinis, il fonctionne dune maniresimilaire aux filtres. Il regarde ou bien le champ ToS, ou bien les informations (des_addr,dst_port, src_addr, srcport, proto ) puis essaie de trouver la classe qui correspond. Si aucuneclasse nest trouve le paquet est envoy vers la classe par dfaut (default class).

Les estimateurs : CBQ mesure le dbit moyen pour chaque classe et si une classe dpasse cequi lui est attribu, lestimateur dtecte ce dpassement. Limplmentation suit leraisonnement de Floyd et Jacobson [5] : Pour une classe, soit l la longueur du paquet en byteset c la bande passante alloue donc le temps dinter-dpart idal entre deux paquets est calculpar : t idal = l/c (voir figure (3.3).On mesure linter-dpart entre chaque paquets, soit t cettevaleur. alors diff = t - t idal et la classe dpasse sa partie si diff est ngative.

General scheduler : la version actuelle implmente utilise le WRR qui tient compte des valeursde pourcentage et celle de la priorit. Lallocation dune classe j ou autrement dit le nombre desoctets que la classe j est capable dmettre son tour est calcul par la formule suivante :

Wrr-allotj = (Ni . MTU). i

j

p

p

Avec, Ni : nombre de classe de mme priority que j Pi : pourcentage de la classe i. MTU : le Max Transfert Unit du lien.

Link sharing Scheduler : lobjectif de ce module est de distribuer lexcs de la bande passantedans les cas ou les files de certaines classes sont vides. En ralit le module nintervient pasdans les cas ou les classes ont des backlogs car dans ce cas le gnral scheduler distribuecorrectement la bande. Les oprations de CBQ sont bases sur linteraction entre le General

General SchedulerWRR

tidal

t

Classificateur

EstimateurLink-SharingScheduler

Figure 3.2 : Modules de CBQ implmente par ALTQ.

Figure 3.3 : Fonctionnement de lestimateur.


Scheduler et le Link-Sharing Scheduler pour modifier lallocation des classes par le mcanismede WRR afin de satisfaire la configuration.

Une option de priority peut tre utilise pour les classes, mais cette implmentation de CBQforce la classe qui dpasse sa fraction alloue subir une priode de suspension de service. Lesautres classes ont la possibilit dtre servies. Si une valeur de priority nest pas prcise pour uneclasse dans le fichier de configuration, la valeur par dfaut est 1.

v PRIQ : cest limplmentation du priority-based queueing, la classe prioritaire est servie enpremier. une prioritisation est implmente par priority [valeur] allant de 1 a 7 , le WRR avecpriority est vu comme plusieurs WRR en cascade , le premier sert la classe de priority 7 et sarrtequand il ny a plus des paquets de priority 7 , ce temps le priority 6 WRR commence servir laclasse de priority 6 etc.. .

v WFQ : cest limplmentation du Weighted Fair Queueing. mais altq selon kenjiro [10]implmente une variante de WFQ , dite SFQ Stochastic Fairness Queueing [18] .Une fonction estutilise pour correspondre les flots aux files( selon adresse destination, ou par flot ), donc il estpossible que deux flots passent dans une mme file. Le nombre des files dattentes est par dfaut256, et contrairement au WFQ pas de guarantie assur par SFQ.

2.2 Le fonctionnement de ALTQ

Le fichier de configuration doit contenir les commandes de configurations assurant lemcanisme voulu, lexcution dun tel fichier est fait par le daemon altqd. Dans ce qui suit unebrve description des commandes :

- interface : en gnral cest la premier commande utilise dans le fichier de configuration.Syntaxe : interface nom_interface [ bandwidth bps ] [ type_file_attente]Le nom de linterface (exemple xl1 ) est le nom physique de la carte rseau reconnut par le

systme dexploitation. Le paramtre bandwidth est la bande passante utiliser, ne dpasse pas lacapacit de la carte.

- class : Cette commande permet de dfinir une classe de serviceSyntaxe : class type_discipline nom_interface nom_class class_parent [ borrow] [default| control] [pbandwidth pourcentage][ maxburst count] [minburst count] [packetsize count ] [ priority pri] [red|rio]

Le paramtre type_discipline permet de prciser la discipline de file dattente utilise, ALTQfournit plusieurs disciplines de queuing CBQ, WFQ, PRIQ, FIFOQ Cette discipline seraapplique sur linterface nom_interface. Une classe est nomme arbitrairement nom_classe et ellevient hirarchiquement au-dessous de la classe parent. Si loption borrow est spcifie alors cetteclasse peut emprunter de la bande passante de la classe parent si cette dernire possde despacedisponible. pbandwidth nous permet de spcifier le pourcentage de la bande accord cette classe.Si loption default est utilise, la classe nom_classe sera la classe par dfaut pour les flux nonconcerns par les oprations de QoS. Si loption control est indique alors cette classe sera uneclasse de contrle. Une classe de contrle est utilise par le systme pour vhiculer les messages decontrle dans le rseau. maxburst est utilis pour indiquer la taille maximale de la rafale le champpriority indique la priorit de la classe, ce champ nest pris en considration que si la classe nedpasse pas ces limites. Si on ne dfinit pas la classe de contrle, elle sera crer automatiquementpar le systme, et elle obtiendra 2 % de la bande accorde la classe par dfaut.


- filter : Cette commande permet de filtrer un flux et de lassocier une classe ou unconditionneur.

Syntaxe : filter nom_interface nom_class|nom_conditr adr_des port_des adr_src port_src prot [tos] Ou pour Ipv6 :filter6 nom_interface nom_class|nom_conditr adr_des port_des adr_src port_src prot[ tos]

Les flux sont filtrs la base des adresses source/destination et des ports sources /destinationet le numro du protocole on peut aussi ajouter le champ tos. filter6 est utilis avec les paquetsIPv6.

- conditionner : Cette commande est utilise pour conditionner les paquets. Pour ALTQ leconditionnement est lensemble des oprations suivantes :Vrification de conformit, marquage,rejet.

Syntaxe : Conditionner nom_interface nom_conditionneur actionLe conditionneur dont le nom est nom_conditionneur est appliqu sur linterface nom_interface.

dans le champ action on peut imbriquer plusieurs autre actions :

- tbmeter : cest limplmentation du token-bucketsyntaxe : tbmeter dbit bucket-size .Si le flux qui passe est conforme alors laction prise est in_action sinon cest out_action

- trtcm (2 rate 3 color marker) il est utilis pour AF. Le trtcm est constitu par deux tokenbockets, un pour le dbit moyen et lautre pour le dbit crt. Si le paquet est conforme au dbitmoyen alors cest laction verte qui est prise, si non sil est conforme au dbit crt, cest lactionjaune qui est prise, sinon cest la couleur rouge.

2.3 Les gestionnaires de files dattentes

Plusieurs gestionnaires de files dattentes ont t proposs par ALTQ : RED ( Random Early Detection) : une simple implmentation de RED se fait par :interface [nom_de_linterface] bandwidth redsoit encore interface [nom_de_linterface] bandwidth red thmin [nb] thmax [nb] inv_pmax [nb] qlimit [nb]

Avec Thmin et Thmax sont les seuils maximaux et minimaux, inv_pamx est linverse de laprobabilit maximale de rejetqlimit : la longueur max de la file.

RIO (RED With In and Out ) : RIO tant RED avec distinction les paquets conformes (marqusIN) et non conformes (marqus OUT).


3. Logiciels de gnration du trafic et de mesure

3.1 Gnration de trafic

3.1.1 Netperf

Netperf [15] est un gnrateur de trafic dvelopp par Rick Jones. Il est utilis pour gnrer etmesurer des trafics continus UDP et TCP (bulk stream), il envoie un trafic avec le maximumdbit possible et avec le maximum transfert unit MTU.

Netperf utilise le paradigme client / serveur, il doit tre active dans les 2 stations : la stationde rception comme un serveur coutant sur un port prcis (20001 par exemple) :

#netserver -p 20001et la station dmission doit au moins prciser ladresse du serveur ou destination et le numro deport. le type du trafic est TCP par dfaut, pour choisir UDP il faut prciser par loption -t.

#netperf -H [adresse] p 20001 t [type du trafic ] l [longueur en secondes]

3.1.2 Iperf

Iperf [16] dsigne une version volue dun autre gnrateur de trafic ttcp. Iperf utilise encorele paradigme client / serveur: le serveur est la station de rception et la sation dmission est unclient pour le server. Iperf permet denvoyer un trafic bien dfini et dafficher les valeurs du dbitet de la gigue des intervalles de temps spcifis par lutilisateur (le plus petit est 1 seconde).

3.2 Logiciels de mesures et dobservation

Pour mesurer les trafics de tests, on a utilis plusieurs logiciels et analyseurs de trafic commealtqstat et cbqmonitor de ALTQ [10] ainsi que TTT (Tele Traffic Tapper) qui est un programmebas sur Tcpdump permettant de visualiser graphiquement et en temps rel le trafic passant surune interface prcise. Altqstat est un module de ALTQ, lanc sur une interface, capte le dbit desclasses, et dautres informations.

4. Implmentation de la Diffrentiation de services

Les tests faits dans cette section ont pour but la mise en uvre des services proposs par lemodle DiffServ. Dans ce qui suit, des exprimentations montrent le marquage, et leconditionnement des flux, ainsi que le dploiement des disciplines de services tels que FIFO,CBQ, PRIQ. La figure (3.4) expose la topologie utilise pour les tests : ALTQ est lanc sur lerouteur ipqosr, les interfaces dentres (cot ipqos1 rl0 et ipqos2 xl0) seront considres comme desn uds dextrmits(edges) et donc ils implmentent des fonctions de classification, de marquageainsi que des outils de vrification de conformit, alors que linterface de sortie (cot ipqos3 xl1)sera considre comme un nud de corps de rseau(core ) donc il intgre des disciplines de filesdattentes .


4.1 Actions ledge

4.1.1 Marquage du trafic

Dans larchitecture DiffServ, la diffrentiation de service doit tre assure par agrgat et non paspar flot, les paquets dun mme agrgat doivent avoir le mme DSCP. Un simple marqueur surl'interface rl0 qui met le code 0xb8 dans le champ DSCP des flux UDP (numro du protocole 17)mis par ipqos1 et reu par ipqos3 est configur comme suit :

interface rl0 conditioner rl0 udp filter rl0 udp 157.159.250.113 0 157.159.249.2 0 17

4.1.2 Implmentation dun Token Bucket

La rgulation du trafic se fait par limplmentation dun token buket en prcisant les paramtresde rgulation : le dbit moyen et le bucket size, dans ce cas respectivement : 6M et 64K .

conditioner rl0 udp filter rl0 udp 157.159.250.113 0 157.159.249.2 0 17

on peut coupler le marquage et la rgulation, dans ce cas les paquets conformes sont marquspar le DSCP, les non conformes sont rejets.

conditioner rl0 udp filter rl0 udp 157.159.250.113 0 157.159.249.2 0 17

4.1.3 Rgulation du trafic UDP

DiffServ propose une diffrentiation de services pour des flots rguls et marqus dans lerouteur edge. Le protocole de transport UDP ne prsente pas des mcanismes de controle de fluxqui permet la source de diminuer son dbit o laugmenter selon ltat du rseau. Alors pourrguler un trafic UDP lentre dun domaine DiffServ limplmentation dun Token bucket, dontles paramtres correspondent aux profile, est demande. Les paquets conformes entrent dans ledomaine et les non conformes sont rejets.

Figure 3.4 : Topologie du rseau pour les tests.


4.1.4 Rgulation du trafic TCP

Si la rgulation dun trafic UDP par des Token Buckets nest pas dtecte par la source, ce nestpas le cas du trafic TCP, car ce dernier est adaptatif et une source TCP ragit avec la variation deltat du rseau. Dans cette section on regarde limpact de la rgulation par TB sur un flux TCP. Lecomportement des mcanismes de contrle de flux de TCP et les profiles des flux TCP sont sujetd'tude. Le scnario de test suivant permet de donner des rsultats. On implmente un TB sur uneinterface et on regarde le profile d'un flux TCP passant par ce TB en changeant la valeur du bucketsize : pratiquement, on a implment un TB sur linterface rl0 ayant un dbit moyen de 6M , et on apris plusieurs valeurs du bucket-size en Kbytes (6, 64, 200, 300 Kbytes), le trafic TCP est lanc parnetperf pendant 30s partir de ipqos1 pour chaque valeur du bucket-size, la taille dun paquet est1500 bytes, le nombre de paquets conformes et non confomes et le dbit dans chaque cas sontcapts des intervalles de temps dune seconde et sont montrs dans les figures (3.5 a) , (3.5 b) et(3.6) :

Dans tous les cas, la mme source met le trafic et pendant la mme dure 30s. La figure (3.5 a)montre le nombre de paquets conformes (axe des ordonnes) pour des valeurs diffrentes dubucket size (axe des abscisses), la figure (3.5 b) montre le nombre des paquets non conformes.lafigure (3.6) montre la variation des dbits.

Rgulation de TCP : dbit moyen 6M, diffrent bucket size

-2

0

2

4

6

8

10

0 5 10 15 20 25 30 35

temps en seconde

dbit

en M

bps

bucket-size 6K bucket-size 64K

bucket-size 200K bucket-size 300K

Figure 3.5 : a- nombres des paquets conformes . b- nombres des paquets non conformes.

Figure 3.6 : Variation du dbit de TCP avec diffrent valeur du bucket size.

381

3394

8697

11051

0

2000

4000

6000

8000

10000

12000

6K 64K 200K 300K

nb de paquets conformes pendant 30 secondes

8984 81

64

01020

3040506070

8090

100

6K 64K 200K 300K

nb de paquets non conformes (jets) pendant 30 secondes


Les rsultats montrent un comportement mal adapt de TCP la rgulation par un TB, lesparamtres du TB influent normment sur le profile du flux TCP. Dans tous les cas, le fluxnatteint pas le dbit moyen indiqu par le TB, pour un bucket-size de 6 Kbytes (4 paquets ), ledbit de TCP est presque nul. Dans TCP, le contrle de dbit est bas sur la dtection des pertes(phnomne slow-start), un bucket-size de 4 paquets produit directement la perte des paquets, etla source diminue son dbit. Pendant 30s, la source nmet que 381 paquets. En augmentant lebucket-size, la source met un nombre plus grand de paquets. Ce test nous mne se demander silfaut rguler un trafic TCP par un TB ? Et si une telle rgulation est ncessaire, quelles sont lesmeilleures valeurs des paramtres du TB utiliser pour avoir le profile configur ? .

Des tudes faites dans [11] donne une manire de dterminer les paramtres du TB pour lemodle suivant : une source utilise TCP pour mettre les paquets, un TB est utilis ledge dundomaine DS, et dans le core un algorithme de gestion de file dattente est coupl avec FIFO. Lesparamtres de lalgorithme de gestion de la file dattente, ainsi que le RTT ( Round Tripe Time)entrent en jeu. La rsolution dune telle problmatique ne fait pas partie de ce travail, donc dans lestests, on ne rgule pas le trafic TCP.

4.2 Actions dans le Core

La diffrentiation de service dans le core du rseau consiste traiter certains paquets avecpriorit par rapport aux autres. Les disciplines de services sont l'objet d'une srie des tests, pourchaque discipline, envisageant le partage de service entre les flots TCP et UDP simultanment etsparment.

4.2.1 FIFO First In First OutDans ce cas, on regarde le comportement FIFO qui est implment actuellement dans

lInternet :

a) Flux TCP :

Afin de tester le comportement des flots TCP par le discipline FIFO , deux flux TCP sont lancspar Netperf partir de ipqosr1 et ipqosr2 et destination ipqos3, le scnario du test est le suivant :

On lance TCP1 linstant t0 puis linstant t1 on lance TCP2, par suite linstant t2 TCP1 estarrt. TTT (Tele Traffic Tapper) permet de visualiser graphiquement et en temps rel le traficpassant sur linterface de sortie xl1 du routeur ipqosr, la figure (3.7) montre le dbit des flux TCP1et TCP2, laxe des abscisses est le temps en seconde et laxe des ordonnes est le dbit en Mbps,nous observons que : quand un seul flux (TCP1) est prsent, il prend la bande passante disponible.quand Il y a deux connexions TCP : Les deux flux partagent la bande passante dune manirequitable et se synchronisent. Ce comportement montre lefficacit de TCP quant au partagequitable de la bande passante mais le fait que le contrle de dbit est bas sur la dtection despertes, ceci mne la synchronisation globale. Quand TCP1 est arrt, Le flux TCP2 prend labande passante toute entire.

t0

t1

t2

TCP1

TCP2Temps


Figure 3.7 : Flux TCP1 et TCP2 avec FIFO.

b) Flux TCP et UDP :

Lobjectif de ce test est de regarder la cohabitation dun flux UDP et dun autre TCP. le scnariodu test est le suivant :

On lance TCP par Netperf linstant t0 partir de ipqos1, t1 un flux UDP 2Mbps est lancpar iperf partir de ipqos2 , puis t2 arrt de UDP (iperf) et lancement de UDP t3 par Netperf.

Le rsultat est capt par TTT, et la figure (3.8) montre le dbit en Mbps pendant le temps delobservation :

t1

Figure 3.8 : TCP et UDP avec FIFO.

t3

t0

t2

TCP

UDP Temps


On observe que TCP occupe la bande passante disponible en l'absence de UDP, maislintervention de UDP (non TCP friendly) force TCP rduire son dbit, le rsultat: UDP occupe2Mbps, et ce qui reste est utilis par TCP. Mais quand UDP est lanc par Netperf , c. . d. un dbitmaximal possible , il occupe la bande passante entirement , et TCP est presque inexistant. De cequi prcde, on peut dire que dans lInternet actuel ( FIFO), UDP ne voit pas TCP, donc il passetoujours quand il y a de la bande passante, alors que ce nest pas rciproque pour TCP. Les paquetsde UDP arrivent occupent le bande passante, produisent des pertes des paquets TCP, ce dernierdtecte les pertes et ragit de faon sadapter ltat du rseau, il diminue son dbit ( algorithmeslow-start). Quand UDP est agressif, le phnomne dadaptation de TCP le mne la disparition.UDP est dit non TCP friendly du fait que sa prsence affecte considrablement le comportementdes flux TCP.

c) FLUX UDP

Entre des flux UDP, pas dadaptation de la source par rapport ltat du rseau, donc le partagede la bande passante est dict par le profile du flux gnr, le service est FIFO o le paquet quiarrive avant sort avant.

Plusieurs tests sont faits montrent les rsultats suivantes:- Des flux contrls lancs par iperf des dbits prcis telque la somme des dbits des flux

est infrieure la bande passante, alors chaque flux prend le dbit prcis.- Pour des flux lancs par Netperf (dbit le plus grande possible), les flux partagent la bande

presque en galit selon la puissance dmission de la source.

4.2.2 CBQ (Class Based Queueing)

La mise en pratique dun partage strict de la bande passante (sans borrow) donc nonconservative par classe (Class Based non-work conserving), et une autre (avec borrow) permettantune meilleure utilisation de la bande passante, alors conservative, est ralis par le module CBQ deALTQ.

4.2.2.1 CBQ non Work Conserving

a) Flux TCP :Ce test a pour but de regarder leffet de la partition de la bande passante entre deux flux TCP,

dans cette politique non conservative par classe, on prvoit quune classe ne prend que sa bandealloue. La figure (3.9)montre le partage de la bande, on prend 10% de la bande passant du lienpour le trafic de contrle, gnralement le trafic de contrle est moins que ca. La bande rservepour la classe TCP1 est 40% du lien, celle du TCP2 est 30%, alors il reste 20% du lien inutilisable.

Figure 3.9 : Partage du lien TCP1 40%,TCP2 30%.

10%90%

30%

lien

default

TCP2

control

40%

TCP1


Le fichier de configuration est le suivant :

Dans ce fichier, chaque flot reprsente un agrgat qui sera marqu linterface dentre, pourle flux lanc partir de ipqos1, il est marqu sur rl0, et le flux venant de ipqos2 sur xl0. Le partagede la bande passante qui est 10M ( interface xl1) est : 10% control, 40% pour TCP1, 30% pour TCP2.La diffrentiation requise est faite en se basant sur le champ DSCP (ToS dans ce cas ), donc le flotest vu comme tant un agrgat.

Le scnario de ce test envisage tous les cas, la prsence des deux flux, et labsence de lun enprsence de lautre, est le suivant :

TCP1 est lanc t0 partir de ipqos1, t1 TCP2 est lanc partir de ipqos2 , et le cas inverseTCP2 puis TCP1 aux instants t3 et t4 , Les scripts de lancement sont :

- Pour TCP1 (ipqos1)

#interface 157.159.249.129 inputin terface rl0

# marquage agrega1 =flot TCP1conditioner rl0 agr1_cdnr filter rl0 agr1_cdnr 157.159.250.113 0 0 0 6

#interface 157.159.249.1 inputinterface xl0

# marquage agrega2 =flot TCP2conditioner xl0 agr2_cdnr

filter xl0 agr2_cdnr 157.159.250.113 0 0 0 6

#interface 157.159.250.111 outputinterface xl1 bandwidth 10M cbqclass cbq xl1 root_class NULL pbandwidth 100class cbq xl1 ctl_class root_class pbandwidth 10 controlclass cbq xl1 def_class root_class pbandwidth 90 default

# agrega 1class cbq xl1 TCP1_class def_class pbandwidth 40filter xl1 TCP1_class 0 0 0 0 0 tos 0x18

# agrega 2class cbq xl1 TCP2_class def_class pbandwidth 30filter xl1 TCP2_class 0 0 0 0 0 tos 0x28

#!/ bin/ shPATH=/bin:/usr/NETPERF/netperf-2.1pl3/export PATHnetperf -H 157.159.250.113 -t TCP_STREAM -p 20001 -l 40sleep 25netperf -H 157.159.250.113 -t TCP_STREAM -p 20001 -l 20sleep 5

t3t1TCP2

t4t2t0

TCP1

Temps


- Pour TCP2 ( ipqos2) :

Les valeurs des dbits des flux sont captes par altqstat, on affiche les rsultats dans la figure(3.10) :

Interprtation : ce test montre un partage strict de la bande passante et un rsultat conforme laconfiguration, la bande est partage selon les valeurs imposes. La nature non conservative decette politique fait de sorte quun flux ne bnficie pas de labsence de lautre ou bien de la bandedisponible. C'est la rservation de la bande passante dans un n ud .

Une note remarquable dune telle configuration est que la synchronisation entre les flux TCPnexiste plus. On trouve que chaque flot TCP occupe la bande alloue sans partage quitable etsynchronisation avec lautre flot. Par tat logiciel, les deux flux passent par deux files diffrentes,mais ce nest pas le cas physiquement, linteraction entre les flux existent et le profile de lun estmoins stable par la prsence de lautre que dans son absence mais la synchronisation est annule.(Ex : TCP1 pendant les intervalles de temps en seconde [0,20]et [20,40] ).


Ce test a pour but de regarder leffet de la rpartition de la bande passante entre TCP et UDP,la figure (3.11) montre le partage de la bande : 10% du lien pour le trafic de control, la banderserve pour la classe TCP est 50% du lien, celle du UDP est 20%, il reste 20% du lien inutilisable.

Figure 3.10 : Dbit de TCP1 et TCP2 avec CBQ .

CBQ:TCP1 40% - TCP2 30%

-0,50

0,51

1,52

2,53

3,54

4,5

0 10 20 30 40 50 60 70 80 90 100

temps en seconde

dbit

en M

bps

TCP1 TCP2

#!/ bin/ shPATH=/bin:/usr/NETPERF/netperf-2.1pl3/export PATHsleep 20netperf -H 157.159.250.113 -t TCP_STREAM -p 20002 -l 20sleep 5netperf -H 157.159.250.113 -t TCP_STREAM -p 20002 -l 40sleep 5



Dans ce fichier, le marquage sur les interfaces dentres, le partage de la bande est : TCP 50%, UDP 20%. Le scnario de lancement est similaire celui du cas prcdant, mais on lance UDP partir de ipqos1 et TCP partir de ipqos2. Les scripts de lancement des flots sont les suivantes :

- Pour UDP (ipqos1)

Figure 3.11 : Partage du lien TCP 50%,UDP 20%.


# marquage agrega1 =flot TCPconditioner xl0 agr1_cdnr filter xl0 agr1_cdnr 157.159.250.113 0 0 0 6

#interface 157.159.249.129 inputinterface rl0

# marquage agrega2 =flot UDPconditioner rl0 agr2_cdnr

filter rl0 agr2_cdnr 157.159.250.113 0 0 0 17#interface 157.159.250.111 output

interface xl1 bandwidth 10M cbqclass cbq xl1 root_class NULL pbandwidth 100class cbq xl1 ctl_class root_class pbandwidth 10 controlclass cbq xl1 def_class root_class pbandwidth 90 default

# agrega1class cbq xl1 TCP_class def_class pbandwidth 50filter xl1 TCP_class 0 0 0 0 0 tos 0x18

# agrega2class cbq xl1 UDP_class def_class pbandwidth 20fi lter xl1 UDP_class 0 0 0 0 0 tos 0x28

#!/ bin/ shPATH=/bin:/usr/NETPERF/netperf-2.1pl3/export PATHnetperf -H 157.159.250.113 -t UDP_STREAM -p 20001 -l 40sleep 25netperf -H 157.159.250.113 -t UDP_STREAM -p 20001 -l 20sleep 5

10%90%

20%

lien

default

UDP

control

50%

TCP


- Pour TCP ( ipqos2) :

Les valeurs des dbits des flux sont captes par altqstat, et sont affichs dans la figure (3.12) :

Interprtation : la figure montre un partage strict de la bande passante la bande est partageselon les valeurs imposes. Cette configuration protge TCP en prsence de UDP, donc une bonneapproche pour la cohabitation de TCP avec les flux non TCP friendly. La bande disponible (20%)nest pas utilise.

c) Flux UDP :

Dans ce cas, la mme procdure est utilise, mais le fait de lancer des flux UDP simultanmentpar NETPERF mne la saturation de linterface xl1 ce qui bloque le systme. Pour viter ceproblme, on attache des TBs sur les interfaces dentres xl0 et rl0 pour limiter le trafic, et pour nepas perdre lobjectif du test, on configure les TB de telles faons ce que les flux mis dpasse lavaleur configure par le pourcentage. De telle faon on ne perd pas la gnralit du test. Le fluxUDP1 40%, UDP2 30% (figure 3.13), donc on prend les paramtres du TB :

Pour UDP1 : dbit moyen : 6M bucket size : 100K Pour UDP2 : dbit moyen : 6M bucket size : 100K.

Figure 3.12 : Dbit de TCP et UDP avec CBQ.

Figure 3.13: Partage du lien UDP1 40%,UDP2 30%.

CBQ: UDP 20% - TCP 50%

-1

0

1

2

3

4

5

6

0 20 40 60 80 100

temps en seconde

dbit

en M

bps

UDP TCP

#!/ bin/ shPATH=/bin:/usr/NETPERF/netperf-2.1pl3/export PATHsleep 20netperf -H 157.159.250.113 -t TCP_STREAM -p 20002 -l 20sleep 5netperf -H 157.159.250.113 -t TCP_STREAM -p 20002 -l 40sleep 5

10%90%

30%

lien

default

UDP2

control

40%

UDP1


le fichier de configuration est le suivant :

Le scnario de lancement des flots est similaire aux cas prcdents, mais le protocole detransport est UDP. Les valeurs des dbits des flux sont captes par altqstat et affichs dans lafigure (3.14) :

Interprtation : malgr que UDP1 est limit 6M, il ne prend que la bande alloue par lepourcentage de 40% et il nest pas affect par la prsence de lautre. De mme pour le flux UDP2mais le pourcentage est 30%. Donc la perte des paquets se fait dans le core car le trafic de chaqueflot dpasse la bande passante alloue , d'o l'importance de la rgulation des flux non adaptatifs l'entre du domaine DiffServ pour jeter ds l'entre le trafic non conforme. On remarque queUDP1 natteint pas exactement 4M alors que UDP2 atteint exactement 3M, ceci est justifi par le faitque la machine ipqos1 est moins puissante que ipqos2.

Figure 3.14 : Dbit de UDP1 et UDP2 avec CBQ.

CBQ: UDP1 40% - UDP2 30%

-1

0

1

2

3

4

5

0 20 40 60 80 100

temps en seconde

dbit

en M

bps

UDP1 UPD2

#interface 157.159.249.129 inputinterface rl0

# marquage agrega1 =flot UDP1conditioner rl0 agr1_cdnr < tbmeter 6M 100K >filter rl0 agr1_cdnr 157.159.250.113 0 0 0 17

#interface 157.159.249.1 inputinte rface xl0

# marquage agrega2 =flot UDP2conditioner xl0 agr2_cdnr < tbmeter 6M 100K >

filter xl0 agr2_cdnr 157.159.250.113 0 0 0 17#interface 157.159.250.111 output

interface xl1 bandwidth 10M cbqclass cbq xl1 root_class NULL pbandwidth 100class cbq xl1 ctl_class root_class pbandwidth 10 controlclass cbq xl1 def_class root_class pbandwidth 90 default

# agrega 1class cbq xl1 UDP1_class def_class pbandwidth 40filter xl1 UDP1_class 0 0 0 0 0 tos 0x18

# agrega 2class cbq xl1 UDP2_class def_class pbandwidth 30filter xl1 UDP2_class 0 0 0 0 0 tos 0x28


4.2.2.2 CBQ Work Conserving

Pour optimiser lutilisation de la bande passante, nous utilisons une implmentation dunepolitique conservative (Work Conserving ) de CBQ. Avec loption borrow une classe peutemprunter de la bande de la classe parent. sans borrow, on a vu que les paquets qui excdent labande alloue sont perdus. Dans cette section on rpte la srie des tests en ajoutant borrow auxfichiers pour permette aux classes TCP et UDP demprunter de la bande de la classe default.

a) Flux TCP :

Dans ce cas, TCP1 peut emprunter du def_class, de mme pour TCP2. Il suffit dajouter borrowaprs def_class dans la commande class. Les scripts de lancements sont les mmes du cas sansborrow et la figure ( 3.15) montre la configuration qui en rsulte.


Figure 3.15 : Partage du lien TCP1 40%,TCP2 30%, CBQ conservative.

#interface 157.159.249.129 inputinter face rl0

# marquage agrega1 =flot TCP1conditioner rl0 agr1_cdnr filter rl0 agr1_cdnr 157.159.250.113 0 0 0 6


# marquage agrega2 =flot TCP2 inputconditioner xl0 agr2_cdnr

filter xl0 agr2_cdnr 157.159.250.113 0 0 0 6

#interface 157.159.250.111 outputinterface xl1 bandwidth 10M cbqclass cbq xl1 root_class NULL pbandwidth 100class cbq xl1 ctl_class root_class pbandwidth 10 controlclass cbq xl1 def_class root_class pbandwidth 90 default

# agrega 1class cbq xl1 TCP1_class def_class borrow pbandwidth 40filter xl1 TCP1_class 0 0 0 0 0 tos 0x18

# agrega 2class cbq xl1 TCP2_class def_class borrow pbandwidth 30filter xl1 TCP2_class 0 0 0 0 0 tos 0x28

borrow40%

30%

10%90%

lien

default

TCP2

control

TCP1


Les scripts de lancements sont les mmes que dans le cas sans borrow, les rsultats sont affichspar la figure (3.16) :

Dans ce cas, on remarque lutilisation de la bande passante par une classe lors de labsence delautre. Dans lintervalle de temps [0,10], TCP1 dpasse sa bande passante limite initialement 4M , et il atteint parfois 6M , mais il ne bnficie pas au maximum de labsence du TCP2, car il peutemprunter la totalit de la classe parent def_class et peut aller jusquau 9M , mais ce nest pas cequon trouve. Ce mme comportement est vu dans lintervalle de temps [45,65] mais pour TCP2qui passe 4M . Dans le cas de prsence des deux flots TCP, on a le mme comportement quedans le cas du test sans borrow. De tels rsultats posent la question sur la faon de distribution dela bande passante en excs entre les classes et comment le link sharing scheduler implmentragit pour profiter de la bande en excs surtout dans la prsence des deux flots ( 20% de la bandeest encore non allou et se trouve pour le def_class laquelle TCP1et TCP2 peuvent emprunter).


Pour regarder limpact dune politique conservative, on ajoute borrow pour les classes TCP etUDP, les scripts de lancements sont les mmes que dans le cas sans borrow, et la figure (3.17)montre les rsultats. On trouve la mme interprtation que dans le cas prcdent.

Figure 3.16 : Dbit de TCP1 et TCP2, CBQ conservative .

CBQ conservative: TCP 40% - TCP2 30%

-101234567

0 20 40 60 80 100

temps en seconde

dbit

en M

bps

TCP1 TCP2

CBQ conservative : UDP 20% - TCP 50%

-2

0

2

4

6

8

0 20 40 60 80 100

temps en seconde

dbit

en M

bps

Documents

Une Architecture de Différentiation de Service dans l’Internet : Théorie et Mesures