Conditions `a v´erifier pour l’acceptation d’un nouveau flux τ i dans la classe EF

Condition de charge locale ∀ h ∈ L_i, U_j∈EF^h ≤ 1

Condition de charge distribu´ee P

j∈EF, j6=iU_j^slowj < 1

Condition sur la dur´ee de s´ejour ^{• ∀ h ∈ Li, R}

h i ≤ dh

i

• ∀ flux τ_j, j ∈ EF , suivant L_j, ∀ h ∈ L_jT L_i, R^h_j ≤ dh j

Condition sur le temps de r´eponse de bout-en-bout

• R^Li

i ≤ D

• ∀ flux τ_j, j ∈ EF , suivant Lj avecLjT Li 6= ∅, R^Li

j ≤ D

Nous pr´ecisons maintenant chacune de ces conditions. Condition de charge locale

Lorsqu’un nouveau flux EF τ_i arrive dans le domaine DiffServ, la premi`ere condition `a v´erifier par le contrˆole d’admission est que le facteur d’utilisation de chacun des nœuds visit´es par τi reste inf´erieur `a 1 (voir remarque 3.2.1, page 26).

Condition de charge distribu´ee

Cette condition est n´ecessaire pour appliquer la propri´et´e 9.2.1. Elle a ´et´e d´emontr´ee lors de l’´etude du temps de r´eponse pire cas de bout-en-bout en environnement distribu´e dans le chapitre 7, page 119.

Condition sur la dur´ee de s´ejour

Si les conditions de charge sont respect´ees, le contrˆole d’admission v´erifie que sur tout nœud h ∈ L_i, la dur´ee de s´ejour de chaque flux τj de la classeEFsur ce nœud reste inf´erieure ou ´egale `a d^h_j. Si nous notons

Jin^h_j la gigue du flux τ_j en entr´ee du nœud h, alors d’apr`es la propri´et´e 5.6.1 ´etablie page 69, nous avons pour tout flux τi, i ∈ EF :

R^h_i ≤ P j∈EF  1 +^{J in} h j Tj  · Ch j + max j /∈EF  0; max n C_j^h o

− 1^ (avec C_j^h = 0 si τjne visite pas le nœud h).

Pour tout flux τi suivant une ligne de diffusion Li compos´ee de q nœuds num´erot´es de 1 `a q, nous avons :

Jin^h_i = Smax^h_i − Smin^h_i ≤^Ph−1 h0=1d^h_i⁰ + (h − 1) · Lmax  −^Ph−1 h0=1C_j^h0+ (h − 1) · Lmin  .

5Pour tout flux τjsuivant une ligne de diffusion Lj, nous notons Rh

j sa dur´ee de s´ejour maximale sur le nœud h et R^Lj

j son

9.2. ARCHITECTUREDIFFSERV 157

Condition sur le temps de r´eponse de bout-en-bout

Pour garantir un temps de r´eponse pire cas de bout-en-bout inf´erieur ou ´egal `a l’´ech´eance du domaine `a tout flux de la classeEF, le contrˆole d’admission doit v´erifier que le temps de r´eponse de bout-en-bout de τi, mais aussi celui de chaque fluxEFτ_jsuivant une ligne de diffusion L_javec L_j∩ L_i6= ∅, sont born´es par D,

soit : R^Li

i ≤ D et ∀ j ∈ EF tel que Lj∩ L_i6= ∅, R^Lj

j ≤ D.

Pour calculer le temps de r´eponse pire cas de bout-en-bout d’un flux de la classeEF, nous avons ´etabli la propri´et´e 9.2.1. Dans la borne propos´ee, le terme Smax^{f irst}_j ^j doit ˆetre ´evalu´e pour tout flux τ_j, j ∈ EF . Ce terme repr´esente le temps maximum mis par un paquet de τj depuis son instant de g´en´eration sur son nœud source pour arriver sur le nœud f irstj. Pour tout flux τi de la classeEF suivant une ligne de diffusion Li

compos´ee de q nœuds num´erot´es de 1 `a q, nous avons :

Smax^h_i = h−1 P h0=1 R^h_i⁰+ (h − 1) · Lmax ≤ h−1 P h0=1 d^h_i⁰ + (h − 1) · Lmax.

Remarque 9.2.1 Lorsqu’un nouveau flux de la classeEFarrive dans le domaine DiffServ, le contrˆole d’ad-mission en-ligne pr´esent´e ci-dessus n’implique que le nouveau fluxEFet les fluxEFle croisant.

Nous illustrons par un exemple le fonctionnement, ´etape par ´etape, du contrˆole d’admission.

9.2.5 Exemple

Nous donnons ici un exemple de borne sur le temps de r´eponse de bout-en-bout ´etablie dans la sous-section pr´ec´edente. Nous consid´erons que trois flux, τ₁, τ₂ and τ₃, ont d´ej`a ´et´e accept´es dans la classe EF. Comme le montre la figure 9.3 :

• τ_{1visite les nœuds 1, 2, 3 et 4 ;} • τ₂visite les nœuds 5, 2, 3 et 6 ;

• τ₃visite les nœuds 7, 2 et 8.

FIG. 9.3 – TraficEFdans le domaine DiffServ

Les hypoth`eses sont les suivantes. L’´ech´eance du domaine est D = 100. Tous les flux τi, i = 1..4, ont une p´eriode T_i = 10, arrivent sans gigue dans le domaine et ont une dur´ee de s´ejour maximale garantie ´egale

`a 10 dans les routeurs d’entr´ee, 25 dans les routeurs au cœur du domaine et 40 dans les routeurs de sortie. De plus, le temps de traitement d’un paquet quelconque est ´egal `a 3 dans les routeurs d’entr´ee et de sortie, 2 dans les routeurs au cœur du domaine. Enfin, Lmax= Lmin= 1.

1. Le contrˆole d’admission v´erifie que sur tout nœud h = 1..4, U_j∈EF^h ≤ 1.

Puisque U_j∈EF¹ = U_j∈EF³ = U_j∈EF⁴ = 0.6 et U_j∈EF² = 0.8, Cette condition est satisfaite.

2. La condition de charge distribu´ee est ´egalement satisfaite. En effet :

P

j∈EF, j6=iU^slowj

j = ^C4¹

T₄ +^C2²

T₂ +^C3²

T₃ = 0, 3 + 0, 2 + 0, 2 = 0, 7 < 1.

3. Le contrˆole d’admission doit alors v´erifier que les dur´ees de s´ejour des fluxEFsur les nœuds communs `a τ4restent born´ees par leurs ´ech´eances interm´ediaires. Cette condition est v´erifi´ee. Par exemple, les dur´ees de s´ejour maximales du flux τ2sur les nœuds 2 et 3 sont respectivement 15 et 25.

4. Enfin, la condition sur le temps de r´eponse de bout-en-bout doit ˆetre v´erifi´ee par le contrˆole d’admis-sion. Par exemple, le temps de r´eponse pire cas de bout-en-bout du flux τ4 est inf´erieur ou ´egal `a :

P j∈EF  1 + ^Smax f irstj j +Jj T_j  · C^slowj j + 4 P h=1 h6=slow max j∈EFCh j +P⁴ h=1 max  0; max j /∈EF{Ch j − 1}  + (q − 1) · Lmax. | {z } C1 1+(1+¹¹₁₀)·C2 2+(1+¹¹₁₀)·C2 3+C1 4 = 14,4 | {z } 7 | {z } 6 | {z } 3

La borne sur le temps de r´eponse pire cas de bout-en-bout du flux τ4est donc ´egale `a 30 (le temps ´etant suppos´e discret).

Le temps de r´eponse pire cas de bout-en-bout exact (obtenu par un outil d´evelopp´e dans le cadre de cette th`ese et pr´esent´e page 2.4) est ´egal `a 26. Nous surestimons donc la valeur exacte d’environ 15%. Cela dit, il est important de remarquer que si les flux τ₂ et τ₃ sont gˆen´es par de nouveaux flux ne croisant pas τ₄, la valeur exacte du temps de r´eponse pire cas de bout-en-bout de τ₄ augmentera alors que la borne calcul´ee restera inchang´ee. Par exemple, si deux nouveaux fluxEFsouhaitent visiter respectivement les nœuds 5 et 7, avec une p´eriode ´egale `a 20 et un temps de traitement maximum ´egal `a 7, ils seront accept´es par le contrˆole d’admission. La valeur exacte du temps de r´eponse pire cas de bout-en-bout sera alors ´egale `a 29, alors que la borne calcul´ee pr´ec´edemment restera ´egale `a 30. La surestimation n’est plus que de l’ordre de 3%. La borne ainsi calcul´ee pour le temps de r´eponse de τ4 reste valide tant que les ´ech´eances interm´ediaires des flux croisant τ₄sont v´erifi´ees. Par ailleurs, il est ´egalement important de souligner que la charge obtenue dans notre exemple pour la classeEFatteint 80%.

9.2.6 Discussion

9.2.6.a Classes et priorit´es fixes

Nous avons consid´er´e pour l’´etablissement du contrˆole d’admission qu’`a chaque classe correspondait une priorit´e fixe. Tous les flux d’une classe ´etaient donc trait´esDP^?puisqu’ils partageaient la mˆeme priorit´e fixe.

9.3. AUTRES ARCHITECTURES 159

Il est possible de g´en´eraliser en permettant `a des flux ayant des degr´es d’importance diff´erents (donc des priorit´es fixes diff´erentes) d’appartenir `a une mˆeme classe de service. La seule exigence `a respecter est que les priorit´es fixes attribu´ees `a la classe EF soient plus grandes que celles attribu´ees aux classes AF, elles-mˆemes plus grandes que celles attribu´ees `a la classe best-effort.

9.2.6.b Garanties apport´ees aux autres classes

Nous avons vu dans les sous-sections pr´ec´edentes comment borner le temps de r´eponse de bout-en-bout d’un flux de la classeEF. Il est ´egalement possible d’utiliser les r´esultats ´etablis dans cette th`ese pour borner le temps de r´eponse de bout-en-bout d’un flux d’une autre classe (par exempleAFou best-effort ), sous r´eserve que les flux soient ordonnanc´esFP/DP*. Un contrˆole d’admission similaire `a celui pr´esent´e ci-dessus pourra ˆetre d´eriv´e. Pour cela, il suffit de reprendre la prori´et´e 7.3.5 donnant une borne sur le temps de r´eponse pire cas de bout-en-bout d’un flux, en notant l’existence de flux plus prioritaires que les flux consid´er´es (ce qui n’´etait pas le cas pour la classeEF).

9.3 AUTRES ARCHITECTURES

9.3.1 Architecture IntServ

Le mod`ele de QoS IntServ a ´et´e pr´esent´e dans la section 3.4.1, page 38. Dans un telle architecture, la qua-lit´e de service est g´er´ee par flux. L’admission d’un nouveau flux est effectu´ee lors de la phase de r´eservation des ressources. Les r´esultats ´etablis dans cette th`ese peuvent ˆetre appliqu´es d`es lors que les flux sont ordon-nanc´esFP/DP<sup>?</sup> dans les nœuds travers´es. Dans ce cas, la priorit´e fixe d’un flux est fonction de son degr´e d’importance ; sa priorit´e dynamique est elle fonction de son param`etre temporel. Le contrˆole d’admission s’appuiera alors sur la borne obtenue sur le temps de r´eponse de bout-en-bout (voir propri´et´e 7.3.5).

9.3.2 Architecture hybride

Dans une architecture hybride, la QoS est g´er´ee soit par classe (type DiffServ), soit par flux (type IntServ). Il est ´egalement possible dans une telle architecture d’offrir des garanties d´eterministes sur le temps de r´eponse et la gigue de bout-en-bout des flux. En effet, les r´esultats ´etablis dans cette th`ese peuvent s’appliquer d`es lors que les flux sont ordonnanc´esFP/DP^?dans chacun des nœuds visit´es. Dans cette architecture, g´erer la QoS par flux peut revenir, du point de vue du calcul des temps de r´eponse, `a g´erer la QoS par classe, en consid´erant que ce flux est le seul `a appartenir `a cette classe.

9.4 CONCLUSION

Dans ce chapitre, nous avons propos´e une solution bas´ee sur DiffServ etMPLSpour fournir `a des appli-cations temps-r´eel des garanties d´eterministes sur le temps de r´eponse et la gigue de bout-en-bout. Dans ce cadre, nous avons montr´e la mise en œuvre d’un contrˆole d’admission en nous basant sur les r´esultats ´etablis dans le chapitre 7. Afin de r´eduire la complexit´e du contrˆole d’admission, permettant ainsi une ex´ecution en ligne, nous avons major´e l’impact des flux croisant le flux demandant son admission.

Nous avons ensuite montr´e comment ´etendre ces r´esultats `a d’autres architectures de QoS (architecture Int-Serv et architecture hybride).

Quatri`eme partie

CHAPITRE

10

Conclusion et perspectives

10.1 Conclusion . . . 164 10.2 Perspectives . . . 165

10.1 CONCLUSION

Dans cette th`ese, nous nous sommes int´eress´es `a des applications ayant des contraintes fortes en termes de temps de r´eponse et de gigue de bout-en-bout dans un r´eseau de type Internet. En effet, les nouvelles applications telles que la t´el´ephonie surIP, la vid´eo `a la demande ou encore les jeux interactifs distribu´es ont besoins de garanties temporelles de QoS pour fonctionner correctement. A partir de deux param`etres de QoS sp´ecifi´es par l’utilisateur, nous avons propos´e une solution pour garantir de mani`ere d´eterministe des bornes sur le temps de r´eponse et la gigue de bout-en-bout du flux consid´er´e. Les deux param`etres sont les suivants :

• un degr´e d’importance, repr´esentant la criticit´e du flux du point de vue utilisateur ; • un param`etre temporel, utilis´e pour d´epartager les flux de mˆeme degr´e d’importance.

Notre solution consiste en un mod`ele d’ordonnancement `a base de priorit´es fixes (FP) combin´e `a un ordon-nancement `a base de priorit´e dynamiques (DP). La priorit´e fixe est le crit`ere principal d’ordonnancement, la priorit´e dynamique ne servant qu’`a d´epartager les flux de mˆeme priorit´e fixe. Ainsi, un paquet entrant dans le r´eseau se voit assigner la priorit´e fixe du flux auquel il appartient et une priorit´e dynamique. Il est ensuite ordonnanc´e dans le r´eseau selon ses priorit´es, attribu´ees sur son nœud d’entr´ee. Nous avons not´e cet ordonnancementFP/DP^?. Ce principe correspond `a la tendance actuelle qui consiste `a reporter les traitements complexes dans les nœuds d’entr´ee ou de sortie du r´eseau, afin d’am´eliorer les performances des routeurs au cœur du r´eseau.

Nous avons alors r´ealis´e une analyse pire cas pour ´etablir des bornes math´ematiquement calculables sur les temps de r´eponse et les gigues de bout-en-bout de n flux coexistant dans un r´eseau. Pour cela, nous avons adopt´e une approche dite “par trajectoire”, qui ne consid`ere que des sc´enarios possibles.

L’´etablissement de ces bornes a ´et´e effectu´e successivement dans trois configurations de complexit´e crois-sante :

• cas monoprocesseur ;

• cas d’une simple ligne de diffusion : tous les flux suivent la mˆeme s´equence de nœuds ; • cas g´en´eral distribu´e : les flux suivent des lignes quelconques.

Puis, nous avons appliqu´e nos r´esultats `a deux ordonnancementsFP/DP<sup>?</sup>particuliers :FP/FIFO<sup>?</sup>etFP/EDF<sup>?</sup>. En consid´erant les cas o`u (i) les flux ont tous une priorit´e fixe diff´erente et (ii) les flux ont tous la mˆeme prio-rit´e fixe, nous avons ´egalement ´etablis des r´esultats pour les ordonnancements FP, FIFO^? et EDF^?. Nous avons alors montr´e que nos r´esultats am´eliorent les r´esultats existants en contexte monoprocesseur pour les ordonnancementsFIFOetEDFet que nous apportons de nouveaux r´esultats en environnement distribu´e. Pour chaque configuration ´etudi´ee (monoprocesseur, ligne de diffusion et cas g´en´eral distribu´e), les r´esultats obtenus avec l’approche par trajectoire am´eliorent significativement les r´esultats obtenus par l’approche ho-listique. Par ailleurs, nous avons ´evalu´e la pr´ecision de nos r´esultats par des exemples num´eriques en les comparant avec les valeurs exactes, fournies par un outil de validation que nous avons d´evelopp´e.

Ensuite, nous avons analys´e l’impact d’une remise en forme d’un flux sur son temps de r´eponse et sa gigue de bout-en-bout. Pour cela, nous avons consid´er´e deux techniques de remise en forme : l’annulation de gigue et le seau `a jetons. Apr`es avoir ´etabli un ensemble de propri´et´es portant notamment sur le d´elai introduit par un module de remise en forme et le temps de r´eponse pire cas de bout-en-bout en r´esultant, nous avons discut´e (i) l’int´erˆet d’une remise en forme et (ii) des m´erites respectifs des deux techniques de remise en forme ´etudi´ees.

10.2. PERSPECTIVES 165

Enfin, nous avons pr´esent´e une application imm´ediate de nos r´esultats en proposant une solution qui permet de pallier l’absence de garanties d´eterministes du service EF dans le mod`ele DiffServ. En effet, dans une architecture combinant DiffServ et MPLS, nous avons d´eriv´e un contrˆole d’admission `a partir des r´esultats ´etablis dans cette th`ese, permettant de garantir de mani`ere d´eterministe les temps de r´eponse et les gigues de bout-en-bout des flux de la classe EF. Cette classe a ´et´e d´evelopp´ee pour des applications temps-r´eel. Nous avons ensuite montr´e comment g´en´eraliser `a d’autres architectures de QoS (architecture IntServ et architecture hybride).

10.2 PERSPECTIVES

A l’issue de cette th`ese, plusieurs perspectives pourraient ˆetre investigu´ees. Elles concernent quatre do-maines sp´ecifiques, `a savoir :

• Ordonnancement

Les r´esultats ´etablis dans cette th`ese permettent de calculer des temps de r´eponse pire cas en contexte monoprocesseur, dans le cas d’une simple ligne de diffusion et en environnement distribu´e, pour des ordonnancements de typeFP/DP^?1. Dans ce cadre, quatre extensions seraient int´eressantes :

◦ Evaluation de la complexit´e

Nous avons pr´esent´e un exemple d’application des r´esultats obtenus dans le cas g´en´eral distribu´e, `a savoir la mise en place d’un contrˆole d’admission dans une architecture DiffServ/MPLSpour la classeEF. Afin de r´ealiser ce contrˆole d’admission en-ligne (complexit´e pseudo-polynˆomiale), nous avons introduit des ´ech´eances interm´ediaires, limitant ainsi la complexit´e de calcul lors de l’arriv´ee d’un nouveau flux EF. Il serait int´eressant d’´evaluer, d’une mani`ere plus g´en´erale, la complexit´e des r´esultats ´etablis dans cette th`ese. Nous pourrions ´egalement mettre en ´evidence le compromis entre pr´ecision de la borne obtenue et complexit´e de calcul.

◦ Comparaison deFP/FIFO^?etFP/EDF^?

Deux ordonnancements FP/DP^? particuliers ont ´et´e ´etudi´es : FP/FIFO^? et FP/EDF^?. Nous avons montr´e qu’en monoprocesseur, FP/EDF domine FP/FIFO lorsque les flux partageant la mˆeme priorit´e fixe ont mˆeme temps de traitement maximum. Nous aimerions identifier l’ensemble des cas pour lesquels cette propri´et´e est v´erifi´ee. Nous aimerions ´egalement comparer FP/FIFO^? et

FP/EDF^?dans le cas d’une ligne de diffusion, puis dans le cas g´en´eral distribu´e.

◦ Attribution d’une ´ech´eance locale pourFP/EDF^?etFP/EDF

Dans le cadre de cette th`ese, nous n’avons pas d´evelopp´e de m´ethode d’attribution d’une ´ech´eance locale `a partir d’une ´ech´eance de bout-en-bout. Ce probl`eme a ´et´e formellement ´etudi´e dans [86]. La m´ethode la plus simple que nous avons adopt´ee pour les exemples est la r´epartition ´equitable : l’´ech´eance locale est ´egale `a l’´ech´eance de bout-en-bout divis´ee par le nombre de nœuds visit´es. Il serait int´eressant de comparer cette m´ethode avec d’autres m´ethodes, telles que l’attribution proportionnelle `a la charge.

◦ Comparaison deFP/DP^?etFP/DP

Pour une m´ethode d’attribution d’´ech´eances fix´ee, nous souhaiterions comparer en environne-ment distribu´e les temps de r´eponse pire cas obtenus avec (i) un ordonnanceenvironne-ment de typeFP/DP^?

et (ii) un ordonnancement de typeFP/DPet identifier les cas pour lesquels l’un des deux ordon-nancements domine l’autre.

1

Par ailleurs, tout au long de cette th`ese, nous avons confront´e les r´esultats obtenus par analyse pire cas avec ceux fournis par un outil donnant la solution exhaustive `a un probl`eme d’ordonnancement donn´e. Nous nous sommes rapidement heurt´es `a un probl`eme de complexit´e exponentielle en pire cas.

◦ Complexit´e de calcul de l’outil de validation

L’outil de validation que nous avons d´evelopp´e dans le cadre de cette th`ese g´en`ere tous les sc´enarios d’activations possibles et m´emorise le temps de r´eponse pire cas pour chacun des flux. Cet outil nous a ainsi permis de valider l’ensemble de nos r´esultats et d’´evaluer leur pr´ecision. Malheureusement, la complexit´e de calcul interdit l’utilisation de cette approche exhaustive dans le cadre d’un nombre ´elev´e de flux. Pour y rem´edier, il serait n´ecessaire de ne tester que les sc´enarios pire cas parmi l’ensemble des sc´enarios possibles. Pour ce faire, il est n´ecessaire d’´etablir les propri´et´es permettant de caract´eriser les sc´enarios pire cas.

• Network Calculus

Nous avons pr´esent´e dans l’´etat de l’art de cette th`ese l’approche Network Calculus et les r´esultats de base associ´es. Les r´esultats que nous avons ´etablis l’ont ´et´e avec une approche par trajectoire selon une analyse pire cas, offrant l’avantage d’un formalisme plus concret. Il serait int´eressant d’´etudier comment nos r´esultats pourraient ˆetre int´egr´es dans l’approche Network Calculus. En effet, le mod`ele sporadique peut ˆetre consid´er´e comme un cas particulier de courbe d’arriv´ee.

• Garanties probabilistes

La th´ematique de cette th`ese porte sur les garanties d´eterministes dans un r´eseau accord´ees `a des flux ayant des contraintes temporelles. Pour ce faire, nous avons r´ealis´e une analyse pire cas sur le temps de r´eponse de bout-en-bout. Un contrˆole d’admission a alors ´et´e d´eriv´e. Mais offrir une garan-tie d´eterministe peut coˆuter cher, surtout lorsque le pire cas ne se produit que tr`es rarement. Dans ces

Dans le document Maîtrise de la dimension temporelle de la qualité de service dans les réseaux (Page 173-199)