IntServ sur DiffServ: Etude du rapport micro-flux/agrgat

Abed Ellatif Samhat, Tijani Chahed

Institut National des Tlcommunications Dpartement Rseaux et Services des Tlcommunications 9 rue Charles Fourier, 91011 Evry Cedex , France. {abedellatif.samhat, tijani.chahed}@int-evry.fr

Cet article traite la qualit de service de bout-en-bout dans l'Internet, en proposant une architecture base sur IntServ dans le LAN la priphrie de DiffServ dans le WAN. Dans une premire partie, nous faisons un rappel thorique des rsultats que nous avons obtenu dans ce contexte et qui visent essentiellement le rapport entre l'agrgat diffserv et flux individuels intserv qui le constituent. Ensuite, une srie d'exprimentations sur une plateforme de QoS locale valide nos rsultats.
RSUM ABSTRACT.

We focus in this paper on end-to-end QoS in the Internet wherein IntServ acting on a per-flow basis is found in local networks in the periphery of large networks where DiffServ is implemented. We first recall the theoretical results we obtained in this area; especially the relationship between the diffserv aggregate and its constituting intserv single flows. We then make use of a set of experimentation on a local QoS testbed to validate our results. Qualit de Service de bout-en-bout, DiffServ, IntServ. End-to-End Quality of Service, DiffServ, IntServ.

MOTS-CLS : KEYWORDS:

GRES Fvrier 2003, Fortaleza-CE-Brsil.

1. Introduction L'Internet a t conu pour assurer l'interconnexion des rseaux en mode paquet sans prendre en compte la qualit de service. Il est fond sur un service unique, le Best Effort, qui permet une simplification des quipements d'interconnexion oprant par la discipline FIFO ( First In First Out), mais aucune garantie pour le dlai ou la perte des paquets. Avec l'apparition de nouvelles applications multimdia (visioconfrence, ) exigeant de la bande passante ainsi que des contraintes strictes de la qualit de service, le Best Effort n'est plus suffisant pour viter les congestions; phnomne qui allonge les dlais, gnre de la gigue et provoque la perte des paquets. Pour amliorer la QoS dans l'Internet, le groupe IntServ (Integrated Services) de l'IETF, cre en 1994, a propos une architecture Intgration de Services dans laquelle il est possible de garantir le taux de perte et le dlai dacheminement observs par un flux individuel, tout en contrlant la distribution de ressources entre les flux. Le modle de IntServ, issu des travaux de standardisation, dfinit deux nouveaux services: Garanti (Guaranteed) et charge contrle (Controlled Load), mieux adapts aux nouveaux besoins des utilisateurs et des applications. La philosophie de ce modle repose sur un contrle d'admission et sur la rservation de ressources sur tous les nuds traverss et pour chaque flux. Pour effectuer cette rservation par flux, le protocole de signalisation RSVP (ReSerVation Protocol) a t dvelopp. RSVP tablit et maintient un tat logiciel entre les nuds constituants le chemin emprunt par les paquets. Cet tat logiciel est caractris par des messages priodiques de rafrachissement envoys le long du chemin pour maintenir l'tat de rservation. Au niveau technique, la rservation de ressources par flux prsente des difficults dimplmentation et des limitations de dploiement. Le dploiement grande chelle de RSVP se heurte la difficult de grer un grand nombre dutilisateurs (scalability). Plus il y a dutilisateurs de IntServ/RSVP, plus il y a dtats crer et maintenir pour des destinations diffrentes chaque fois. Le cot introduit par la gestion des tats et lordonnancement par flux peut entraner une rduction considrable de leur performance. Du fait que la signalisation de IntServ opre au niveau de chaque flux, le modle nest pas scalable et son application se limite aux sites priphriques. L'IETF a cre en 1997 le groupe DiffServ (Differentiated Services) qui bnficie des travaux de IntServ et tente de dpasser les difficults rencontres dans le modle intserv. Le modle DiffServ [1] introduit la notion de lagrgation des flux en quelques classes offrant des services spcifiques par agrgat (per Aggregate), il n'offre aucune garantie sur les flux individuels. Dans ce modle il ny a pas de rservation de ressources travers les nuds, tel que 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 assur (Assured Forwarding). L'architecture gnrique pour un domaine DiffServ fait la distinction entre le

IntServ sur DiffServ: Etude du rapport micro-flux/agrgat

systme qui constitue le cur du rseau (core) ou routeurs internes du domaine, et les systmes ralisant l'accs aux rseaux terminaux (edge) ou routeurs de frontire du domaine. La fonction principale des routeurs constituant le core consistent acheminer les paquets aussi vite que possible selon la priorit de la classe du paquet, cette priorit est traduite par l'tiquette du champ DS (DiffServ) de l'en-tte IP. Les routeurs d'accs se chargent des fonctions de conditionnement, de contrle d'intgrit et d'admission des paquets dans le rseau. L'agrgation des flux l'edge d'un domaine DiffServ chappe la problmatique de passage l'chelle, en permettant d'augmenter les performances des routeurs du cur surtout pour les rseaux de grandes tailles o des milliers de flux sont achemins. L'agrgation sentend souvent en termes dterministes [7] o les diffrents paramtres de Tspec (Traffic Specification) sont grossirement additionns sans ncessairement tenir en compte le comportement rel des flux, qui peut tre assez variable, lintrieur de lagrgat. Dans [3], une tude exprimentale montre un gain de l'agrgation en terme de la taille de rafale de l'agrgat. Mesurer l'impact de l'agrgation sur les micro-flux en terme du profil de chacun fait partie de ce travail. La QoS relve de lintgralit du systme de bout-en-bout. Il est donc essentiel dtudier le comportement du flux travers les diffrents points du systme, limpact des diffrentes oprations quil subit ainsi que la performance globale qui en rsulte. Dans ce contexte htrogne, IntServ sur DiffServ [2], les flux sont traits deux chelles diffrentes: flux individuel et agrgat; De mme la QoS est assure suivant deux politiques diffrentes: rservation de ressources et priorit. Comment promettre pour un flux IntServ une QoS base de rservation au niveau de flux, dans un domaine DiffServ o il sera agrg et prioritis ? Une tude analytique de la distribution des paramtres de QoS d'un agrgat, notamment perte, sur les flux qui le constituent est prsente, et une validation exprimentale est ralise. Cet article est organis de la faon suivante : Dans la section 2, nous prsentons le systme de bout-en-bout IntServ/DiffServ ainsi que nos rsultats thoriques dans ce contexte examinant le rapport micro-flux/agrgat. La troisime section prsente la plate-forme QoSIP et les exprimentations de validation des tudes analytiques sur cette plate-forme. La section 4 rsume la conclusion de ce travail ainsi que des futurs travaux . 2. La qualit de service de bout-en-bout Dans l'Internet, les flux de donnes de diffrents exigences en terme de qualit de service traversent gnralement une succession des rseaux , chacun pouvant avoir sa propre politique de QoS, de ces politiques on cite le surdimensionnement, la rservation des ressources et la diffrentiation des services. La QoS doit tre gre et assure pour respecter le contrat du client dans n'importe quel type de

GRES Fvrier 2003, Fortaleza-CE-Brsil.

politique de QoS dans les rseaux de passage. Pour maintenir une QoS de bout-enbout, une architecture hybride IntServ/DiffServ [2] est propose, et nos travaux dans [6] portent sur la mise en correspondance (Mapping) entre les paramtres de QoS permettant d'tablir les correspondances entre les classes de services de chaque modle. La figure 1 prsente le systme: le modle IntServ bas sur RSVP et oprant au niveau flux individuel est utilis aux sites priphriques comme les rseaux d'entreprise ou les rseaux de petite taille (LAN). DiffServ, bas sur la prioritisation et traitant des agrgats est utilis pour les rseaux de transitions ou le cur des rseaux importants (WAN). Dans la perspective de IntServ, les rgions DiffServ du rseau sont traites comme des liens virtuels reliant les routeurs ou les terminaux IntServ, et la visibilit de l'utilisateur est rduite IntServ.

IntServ

IntServ

Edge DiffServ

Edge

Figure 1. Architecture IntServ/DiffServ Dans le modle DiffServ, un contrat de QoS est ngoci et le rseau s'engage assurer la QoS demande pour les flux tant que les sources respectent le profil de trafic accord; la validation est assure par une rgulation du trafic l'edge du domaine. Dans les travaux de l'IETF concernant la QoS , l'algorithme recommand pour caractriser le comportement d'un flux est le seau jetons (Token Bucket). Le seau jetons caractrise un flux grce deux paramtres r et b. Le premier reprsente le dbit moyen d'mission; le deuxime, renfermant la dviation temporaire acceptable de ce dbit, indique la taille maximale des rafales que la source peut gnrer. En tant qu'algorithme, r est la vitesse de remplissage du seau et b est la taille de celui-ci. Dans le modle IntServ de lIETF, les descripteurs de trafic ou Tspecs d'un flux sont dfinis par deux token bucket, l'un pour contrler le dbit moyen (r,b), et lautre pour le dbit crte (p: dbit crte, M: Maximum Transfert Unit) de telle faon que la courbe d'arrive du flux en fonction du temps t est dtermine par l'enveloppe min(rt+b, pt+M) . 2.1. Impact de l'agrgation l'egde d'un domaine DiffServ A l'entre d'un domaine DiffServ, un flux individuel de donnes est donc caractris par le dbit moyen r et la taille de rafale b. En se basant sur l'approche

IntServ sur DiffServ: Etude du rapport micro-flux/agrgat

dterministe qui utilise les courbes de service [7], le dbit moyen de lagrgat ainsi que sa taille de rafale sont respectivement laddition des dbits moyens, et des tailles de rafale, des flux individuels (micro-flux) qui le constituent. Dans l'approche statistique, les caractristiques statistiques des flux sont considres [8]. Un flux est donc modlis par une source ON/OFF qui met une rafale de taille b un dbit crte p dans la phase ON. Soit PON la probabilit quune source se trouve ltat ON, alors le dbit moyen est r= p.PON. Dans ce cas, ltude de lagrgation de N flux (sources) se rfre la considration dun processus de Markov temps continu et tat discret reprsentant le nombre de sources mettant simultanment, N+1 est le nombre des tats. Pour N sources indpendantes et identiquement distribues, la probabilit que k sources soient ON simultanment est donne par la loi de Binme:
k k Pk = C N PON (1 PON ) N k

Le nombre moyen des sources ON simultanment est E ( k ) = P ' (1) = N .PON , calcul en utilisant la fonction gnratrice

P ( z ) = z k Pk = (1 PON + zPON ) N
i =0

Par suite le dbit moyen de lagrgat est : rag=E(k).p =N.r = r

i =1

Pour la taille de la rafale de lagrgat: bag = E(k).b On trouve donc que le dbit moyen de lagrgat est la somme des dbits moyens des flux qui le constituent, c'est le mme rsultat dans les deux approches. Mais la variation de E(k), et plus prcisment la probabilit quune source soit ON, entre en jeu pour la taille de rafale; la taille de rafale de l'agrgat dpend des caractristiques des sources. La validation exprimentale de cette tude dans [3] a montr que l'approche statistique est plus raliste, donc l'agrgation prsente un gain statistique en terme de la taille de rafale au niveau de l'agrgat. Ce gain affecte-t-il le profil des microflux ou autrement dit, le micro-flux garde-t-il son profil l'intrieur de l'agrgat ou bien il est affect par l'interaction avec d'autres micro-flux. Des difficults s'imposent pour rpondre analytiquement cette question, une tude exprimentale fait partie de la section 3. 2.2. Distribution des pertes d'un agrgat entre les micro-flux dans le cur d'un domaine DiffServ Considrons la distribution des pertes d'un agrgat entre les micro-flux qui le constituent en supposant que les pertes sont dues au dbordement de la file d'attente dans un routeur. Donc, les pertes d'un flux qui font l'objectif de notre tude sont les

GRES Fvrier 2003, Fortaleza-CE-Brsil.

pertes rencontres une fois le flux est entr dans le domaine DiffServ. Notons que les paquets d'un agrgat sont identiques devant toutes les actions subies par l'agrgat, autrement dit, aucune diffrentiation entre les micro-flux l'intrieur d'un agrgat. Soit (t ) le dbit instantan de l'agrgat, c'est donc la somme des dbits l'agrgat et d'un flux individuel i sont respectivement r = E{ (t )} et ri instantans i (t ) des flux individuels (identiques ou non). Les dbits moyens de

= E{i (t )}. Pour un serveur de capacit C , la probabilit instantane p de perte d'un paquet arrivant d'un agrgat est calcule par:

( (t ) C ) + avec x + = max(0, x) . (t ) La charge instantane est : (t ) = (t ) / C . Donc p peut tre crite sous la p=
forme:

( (t ) 1) + p= (t )
La probabilit de l'ensemble des pertes ( c..d. longue terme) est calcule par:

P=

1 1 E ( (t ) C ) + = E{p ( (t )} r r

Pour un flux individuel i , et avec i (t ) = i (t ) / C , pi et Pi sont respectivement :

pi =

(i (t ) C ) + ( i (t ) 1) + = i (t ) i (t )

et Pi =

1 E{( pi (i (t )} ri

D'aprs [4], le rapport des probabilits de perte individuel/agrgat peut tre approxim par :

avec = E{ (t )} , cette quation permet en cas de connaissance des caractristiques statistiques ( loi de distribution d'arrive des paquets ) du flux et de l'agrgat de P dterminer le rapport i , donc de quantifier les pertes subies par le flux par P rapport celles de l'agrgat. Dans la vision IntServ/DiffServ, soient PDS la probabilit des pertes d'un agrgat au niveau DiffServ, PIS la probabilit des pertes vues au niveau IntServ,

Pi E{i (t ) / (t ) = C} P ri

i (t ) reprsente IntServ, et (t ) DiffServ. L'quation ci-dessus nous donne

IntServ sur DiffServ: Etude du rapport micro-flux/agrgat

PIS E{i (t ) / (t ) = C} PDS ri

3. Etude Exprimentale 3.1. Plate-forme QoSIP La plate-forme (QoSIP) a t monte dans le laboratoire RST de lINT pour crer un domaine DiffServ (voir Figure 2). Les machines excutent le systme dexploitation FreeBSD4.7 . Les stations ipqos1 et ipqos2 sont utilises pour gnrer le trafic, ipqos3 et ipqos4 pour la rception, donc ces stations sont des clients. Le routeur ipqosr supporte le fonctionnement normal de routage par le protocole RIP.

xl0 Ipqos1 Ipqosr

xl1

Ipqos4

Ipqos2 Figure 2. Plate-forme QoSIP

rl0

Ipqos3

Le modle DiffServ fait la distinction entre les fonctions d'un routeur edge et celle d'un routeur du cur : Les fonctions d'un routeur edge sont supportes sur les interfaces d'entre xl0 et rl0 de ipqosr, alors que les fonctions d'un routeur du cur sont supportes sur l'interface de sortie xl1. Nous utilisons Iperf [10] pour la gnration du trafic. L'outil d'implmentation des mcanismes l'edge ainsi que dans le cur du rseau est ALTQ [5] [9], il est attach sur l'interface prcise et le module altqstat capte les statistiques. Le module le plus utilis dans nos exprimentations est le token buket. Son implmentation par ALTQ sur une interface prcise, permet de dterminer le profil d'un flux, de plus, il sert comme outil de mesure des nombres des paquets conformes au profil et non conformes (perdues) sur l'interface en considration .

GRES Fvrier 2003, Fortaleza-CE-Brsil.

3.2. Impact de l'agrgation l'edge sur les profils des micro-flux L'tude analytique de l'impact de l'agrgation sur le profil d'un micro-flux l'intrieur d'un agrgat rencontre des difficults. Dans la suite, nous prsentons une tude exprimentale pour rpondre cette problmatique. Nous avons implment sur notre plate-forme un scnario (1) qui permettra d'valuer cet impact. Le scnario consiste gnrer un flux sous un profil dtermin, l'agrger avec d'autres et puis regarder son profil aprs agrgation. Les inter-arrives des paquets dcrivent parfaitement le profil d'un flux. Pour raliser cet objectif un flux (micro-flux) est gnr partir de ipqos2 et destination de ipqos4, il rejoint un autre flux (agrgat) gnr de ipqos1 vers ipqos3. Sur l'interface rl0 de ipqosr on mesure, en utilisant tcpdump, les inter-arrives des paquets du flux avant qu'il rejoint l'agrgat, av reprsente ces valeurs. En sortant de ipqosr, nous mesurons aussi les inter-arrives des paquets du flux sur l'interface d'entre de ipqos4, soit ap les valeurs correspondantes. L'unit de mesure est la micro-seconde (s). = ap -av reprsente la variation du profil, le profil est inchang tant que est gale zro . Pour des rapports de 1/100 et 1/20 entre micro-flux et agrgat, la figure 3 montre pour un micro-flux de 10 kb/s puis de 50kb/s et un agrgat de dbit moyen 1Mb/s, le temps d'observation est de 150 secondes dans chaque cas. Ces rsultats confirment un changement de profil du flux aprs l'agrgation . Nous signalons que ce changement est mesur une chelle microscopique ( en s).

, cas 10 kb/s 1500 1000 500

1 5 0 0 1 0 0 0

, ca s5 0kb /s

en s

0 -500 -1000 -1500

en s

5 0 0 0 -5 0 0

-1 0 0 0

Figure 3. Variation de profil du flux cas 10 kb/s et 50 kb/s Pour valuer le changement l'chelle de rafale, nous avons implment un autre scnario (2) utilisant les token buckets: un flux (micro-flux) est gnr partir de ipqos2 et destination de ipqos4, son profil est dtermin par un token bucket TB2 sur l'interface rl0 de ipqosr, il rejoint un autre flux (agrgat) gnr de ipqos1 vers ipqos3. Sur l'interface d'entre de ipqos4, on attache un token bucket TB4 de mme profil que TB2 pour mesurer le nombre des paquets conformes et perdus. Pour un agrgat de dbit moyen 1Mb/s et de taille de rafale 50 koctets dfini par un token bucket TB1 sur l'interface xl0, nous avons aussi pris un micro-flux de l'ordre

IntServ sur DiffServ: Etude du rapport micro-flux/agrgat

de 1/100, donc TB2 (r=10kb/s, b=3koctets). TB4 est identique TB2; les mesures faites par TB4 montre qu'aucun paquet n'est perdu, donc pas d'augmentation de la taille de rafale. La moindre diminution de b de TB4 moins de 3koctets provoque des pertes de paquets. Ce mme scnario est rpt mais avec un micro-flux de profil (r=50kb/s, b=6koctets). Les rsultats sont similaires. L'interprtation des rsultats des ces scnarios est que le changement de profil dtect par le scnario (1) est invisible l'chelle de rafale. 3.3. Distribution des pertes d'un agrgat entre les micro-flux qui le constituent Dans ce paragraphe, nous prsentons une srie d'exprimentation pour tudier la distribution des pertes d'un agrgat entre les micro-flux qui le constituent. Le scnario consiste envoyer un flux (micro-flux) gnr partir de ipqos2 et destination de ipqos4, son profil est mesur par un token bucket TB2 sur l'interface rl0 de ipqosr, il rejoint un autre flux gnr de ipqos1 vers ipqos3, ce dernier est aussi mesur par un token bucket TB1 sur l'interface xl0 de ipqosr. Sur l'interface de sortie xl1 de ipqosr, un mcanisme de limitation de la bande passante est assur pour causer des pertes sur l'agrgat ( les deux flux). Sur l'interface d'entre de ipqos4, on attache un token bucket TB4 pour mesurer les paquets du flux non perdues sur xl1, de mme TB3 pour le reste de l'agrgat sur l'interface d'entre de ipqos3. Dans la srie des tests, TB1 est le mme (r=1Mb/s,b=50koctets), alors que le micro-flux varie en formant une partie de l'agrgat allant de 1% 50% . Les pertes causes dans les scnarios varient aussi entre 1% 7% du volume de l'agrgat. La figure 4 montre le pourcentage des pertes du micro-flux et le pourcentage de son volume dans l'agrgat pour les diffrents cas dtermins par TB2.
Agrgat ( 1M 2M )
Volum e du m icro-flux dans l'agrgat (% ) 60,00 50,00 40,00 30,00 20,00 10,00 0,00 Perte du m icro-flux (% )

Figure 4. Perte du micro-flux (%) et son volume dans l'agrgat (%)

(1 0k ,3 k) (3 0k ,5 k) (5 0k ,5 k) (7 5k ,5 k) (1 00 k, 5k ) (2 00 k, 10 k) (3 00 k, 15 k) (4 00 k, 20 k) (5 00 k, 25 k) (8 00 k, 40 k) (1 M ,5 0k )
Profile du m icro-flux

10

GRES Fvrier 2003, Fortaleza-CE-Brsil.

Un rsultat d'quit est que les pertes d'un micro-flux soit au mme niveau de sa participation l'agrgat. Dans les exprimentations ce rsultat n'est pas toujours obtenu. Nous avons trouv que les pertes sont parfois diffrentes de la critre d'quit. Dans le cas o notre micro-flux a eu moins de perte que son % de participation l'agrgat, cela veut dire que d'autres micro-flux ont eu plus de pertes. Donc la distribution des pertes d'un agrgat entre les micro-flux qui le constituent est alatoire. Le rsultat vu d'une autre manire est illustr dans la figure 5 o l'axe des abscisses reprsente le pourcentage de participation du micro-flux l'agrgat, et l'axe des ordonnes est le pourcentage de perte. On peut parler de plusieurs zones . Une zone positive (au dessous de Y=x) o les pertes sont moins du niveau de participation et une zone ngative (au dessus de Y=x) o les pertes sont plus du niveau de participation. La frontire entre les deux zones est l'quit (Y=x). Pratiquement, un micro-flux se situe alatoirement dans l'une de ces zones. Ce rsultat prouve que si une classe DiffServ tolre un taux de perte donn, les taux de pertes des micro-flux peuvent ne pas tre du mme ordre. Ceci confirme que la garantie d'un taux de perte promis pour un flux IntServ traversant un domaine DiffServ dans la rgion DiffServ n'est pas stricte.

60 50 40 30 20 10 0 0 10 20 30 40 50 60 Volume du micro-flux dans l'agrgat (%)

Perte du micro-flux (%)

Perte du microflux(%) Equit

Figure 5. Perte du micro-flux(%) vs son volume dans l'agrgat(%) 4. Conclusion Dans cet article, nous avons tudi le rapport micro-flux/agrgat, qui s'inscrit dans le cadre d'une architecture hybride IntServ/DiffServ offrant de la QoS de bouten-bout. Nous nous sommes concentr sur l'impact de l'agrgation sur les profils des flux individuels ainsi que la distribution des paramtres de QoS d'un agrgat, notamment perte, entre les micro-flux qui le constituent. Les mesures ont montr que le phnomne d'agrgation affecte les profils individuels des flux, un effet

IntServ sur DiffServ: Etude du rapport micro-flux/agrgat

11

invisible l'chelle de rafale. Nous avons montr que la distribution des pertes est dtermine thoriquement, mais elle est alatoire pratiquement. Dans ce travail nous avons trait la QoS de bout-en-bout dans un contexte filaire, nos futurs travaux examinent la qualit de service de bout-en-bout dans un systme comportant des rseaux d'accs non filaire. 5. Bibliographie
[1] S. Black and all, RFC 2475,"An Architecture for Differentiated Service", December 1998. [2] Y. Bernet and all, "A Framework for Integrated Services Operation Over DiffServ Networks", IETF, RFC 2998, November 2000 . [3] A. Samhat et T. Chahed, "La diffrentiation de service base sur des mesures", GRES'2001, Marrakech , Dcembre 2001 . [4] J. Roberts, U. Mocci, J. Virtamo, "Broadband Network teletraffic", Springer, 1996 . [5] K. Cho, "The Design and Implementation of the ALTQ Traffic Management System", Ph-D thesis , January 2001 . [6] T. Chahed, G. Hebuterne, C. Fayet, On Mapping of QoS Between Integrated Services and Differentiated Services, IEEE/IFIP IWQoS 2000, Pittsburgh, June 2000.

[7] R.L. Cruz, "Quality of Service Guarantees in Virtual Circuit Switched Networks" Invited
Paper for the IEEE Journal on selected Areas in Communications: Advances in the Fundamentals of Networking, September 30, 1994. Revised March 11, 1995. [8] T. Chahed, A-F. Canton,"Towards Statistical Traffic Engineering", INT, March 2001. [9] ALTQ Tips, http//www.csl.sony.co.jp/person/kjc/ kjc/software/TIPS.txt. [10] http://dast.nlanr.net/Projects/Iperf/.