Garantir la qualité de service temps réel: ordonnancement et gestion de files d’attente

Garantir la qualité de service temps réel:

ordonnancement et

gestion de files d’attente

YeQiong SONG, LORIA – INPL – Nancy Université

http://www.nancy-universite.fr/

ETR’2007, Nantes, 7 sept. 2007 Y.Q. Song 2

Plan

1. Mécanismes de gestion de la QdS

2. Gestion de files d’attente

3. Ordonnancement de messages

4. Remarques sur des méthodes d’évaluation des bornes de temps de réponse


1 - Gestion de la QdS dans un nœud de réseaux à commutation de paquets

...

Serveur de capacité c

1

2

N

.

.

.

interarrivé sources

paquets

- Borner les flux d’arrivée: Leaky bucket

- Gérer la saturation de buffers: RED

- Ordonnancer les paquets: WFQ

Contrôle d’admission pour la garantie


2 - Mécanismes de gestion de files d’attente

• TD (Tail Drop)

• RED (Random Early Detection)

• DLB (Double Leaks Bucket)


TDRejet quand file pleine

Simulation TD avec flux d’arrivée Poissonnien =1, taille file = 9, C = 0,8

101101111100001100011111111111111111111111111011101010010111111111011111101001111101010010100001111100111111111111111111111111111111111111110111011001101000111111101111110111111110


RED (rejet avec probabilité)

1

Maxp

min

max

Longueur moyenne de file

Ne rienrejeter

Rejet avecProba P

Rejetertout

P


RED

Lg_moy = (1-Wq)*Lg_moy + Wq*lg_inst

Longueur de file

Temps

Lg_moy

Lg_inst


Simulation RED avec flux d’arrivée Poissonnien =1, taille file = 9, C = 0,8, wq = 0,2, max_p = 0,34, minth = 3, maxth = 6

111010010000111111111111111111111111111111010111111111100110011111011111111111111111111111111111110110010111011111011111111111111111110100001111000110001010111111111111111111101010

RED

Simulation TD 101101111100001100011111111111111111111111111011101010010111111111011111101001111101010010100001111100111111111111111111111111111111111111110111011001101000111111101111110111111110

DLB RED TD

Taille moyenne de file 4.7 4.3 9.0

Délai moyen (ms) 4.8 4.5 8.7

Taux de perte 22% 22% 20%

Pertes consécutives max. 1 4 4

Pertes consécutives moy. 1 1.64 1.54


ObservationsConsidérons un exemple de transmission de paquets de voix pour une session de téléphonie IPCongestion rejet de paquets dégradation de QdS

Problème: seul taux de pertes ne permet pas de mesurer la dégradation. Pour un même taux, une longue séquence de pertes consécutives impacte plus la QdS

Nouveaux modèles pour mieux spécifier la tolérance à la dégradation de QdS?Nouveaux mécanismes pour éviter de longues séquences de pertes?

Modèle (m,k)-firm

Double Leaks Bucket


Modèle (m,k)-firm

• Temps réel dur: non respect d’une échéance entraîne des conséquences catastrophiques

• Temps réel souple: non respect des échéances entraîne une diminution de performances (QdS dégradée)– Temps réel « firm »: temps réel souple mais avec le

non traitement des paquets ne pouvant pas respecter leur échéances (paquets rejetés)

– (m,k)-firm: respect des échéances d’au moins m parmi k paquets consécutifs quelconques [Hamdaoui95]


(m,k)-firm et états du system

• Exemple de (2,3)-firm

• k-séquence

1111

1100

101

100

1

0

011

010

001

000

0

1

0

1

0

1

0 11

0

10


k-séquence et expression de contraintes

(3,5)-firm

- k-séquence fixe = k-pattern

1 0 0 1 1 1 0 0 1 1 1 0 0 1 1 . . .

1 0 0 1 1 1 0 1 0 1 1 1 0 1 0 ...

- k-séquence dynamique


Exemple d’une application acceptant la contrainte (m,k)-firm

• Flux vidéo MPEG

I

B B BP

B BP

B BP

B

I

B B BP

B BP

B BP

B

1 0 0 1 0 0 1 0 0 1 0 0 1 0 0 1 0 0 1 0 0 1 0 0

GOP (Groupe Of Pictures)


Maquette de tests

Routeur ClickCommutateur

LAN 1Commutateur

LAN 2

LAN 1 100 Mbits/s

Netmask = 255.0.0.0

LAN 210 Mbits/s

Netmask = 255.255.255.0

Lien 1 100 Mbits/s

Lien 2 10 Mbits/s

Serveur 1 @IP : 10.0.0.2

Serveur 2@IP : 10.0.0.3

Client 1 @IP : 192.168.1.2

Client 2@IP : 192.168.1.3

VideoLan : générateur de trafic MPEG


Test sur maquette

• Vidéo initiale:


• Test 1: rejet de tous les paquets de type I

Image fixe

Test sur maquette


• Test 2: rejet de tous les paquets de type P

Test sur maquette


• Test 3: rejet de tous les paquets de type B

Test sur maquette


Modèle R-(m,k)-firm

R-(m,k)-firm est une relaxation du modèle (m,k)-firm afin d’augmenter le taux d’utilisation du serveur – un problème bien connu de l’ordonnancement est non préemptif [Thèse J. Li 07]

Source side

Destination side

s t

t+

s

time

time

Facteur (m,k) : pour un groupe quelconque de k paquets consécutifs, au moins m sont transmis avant un facteur de délai

Facteur délai: à l’instant t, k paquets sont émis par la source. Alors, m parmi eux doivent être transmis à la destination avant t+. une échéance par groupe de paquets au lieu d’une par paquet.


DLB (Double Leaks Bucket)

Un simple lavabo avec une évacuation de trop plein

qq2q1

open

close

Switch state

ServingLeak C1

DiscardingLeak C2

q1

q2

Sw itch

TVB

q1

q2

q2

C1

C1+

C2

C1 +

C2

C1

tint t1 t2

Courbed'arriv ée

Courbe deserv ice

http://jlhuss.blog.lemonde.fr/photos/uncategorized/robinet.gif


DLBSimulation DLB (q1=3, q2 = 6, taille de file = 9, C1 = 0,8, C2 = 0,4)

011011011011011011011011011011011011011111111111111111101101101101101101101101111111110110110110110110110110110110111111111111111111111111111101101101101101101101101101101101101101

DLB RED TD

Taille moyenne de file 4.7 4.3 9.0

Délai moyen (ms) 4.8 4.5 8.7

Taux de perte 22% 22% 20%

Pertes consécutives max. 1 4 4

Pertes consécutives moy. 1 1.64 1.54

Propriété 1: non pertes consécutives


DLBProperty 2: Garantie déterministe R-(m,k)-firm pour flux (,)-borné

Theorem: Pour un flux (,)-borné, si DLB est configuré selon les conditions suivantes, la contrainte R-(m,k)-firm sera respectée de façon déterministe

• Condition (1) : C1+C2> ;

• Condition (2): si >q2, alors

sinon

11

2

C mq

C k m

q1

q2

q2

C1

C1+

C2

C1 +

C2

C1

tint t1 t2

Courbed'arriv ée

Courbe deserv ice

2 2 1 1

1 1 2 1

1max ,

q q q qS S

C C C C

2 1 1

1 1 2 1

1max ,

q q qS S

C C C C


3 - Ordonnancement de message


WFQ

P21 P22 P23 P24 P25

WFQ

3

1

P11 P12 P13 P14 P15 P16

Flux 1 : 3 Mbit/s

Flux 2 : 1 Mbit/s

P11 P12 P13 P21 P14 P15 P16 P22

P17 P18 P19

P23 P24 P25

D2

D1

1max , ( )k

k k j

j j

j

LF F V t

Temps Virtuel de DépartTemps Virtuel de Départ


WFQ et temps de réponse borné

• WFQ garantit à chaque source de flux i

– une portion de bande passante gi proportionnelle à son coefficient de partage i

– un délai maximal ssi le trafic du flux est borné par une courbe d’arrivée (i,i)-borné et avec

i gi :max

,maxi

ii

LD

g c


Problème de WFQ pour temps réel• WFQ est initialement conçue pour garantir la bande

passante mais pas le délai !• Pour un flux donné, plus le coefficient de partage

est petit, plus le délai est grand Problème : flux temps-réel de faible besoin en bande

passante, mais nécessitant un délai étroit (Voix sur IP avec Débit=64Kb/s)

• Sous-utilisation de ressources pour garantir le délai– Borne sur le délai = f(Bande passante réservée, Rafale)

max,max

ii

i

LD

g c


(m,k)-WFQ [thèse A. Koubâa 04]

• Objectifs de (m,k)-WFQ:– Prise en compte de (m,k)-firm– Utilisation plus efficace de la bande passante

pour réduire Dmax

• Principe de (m,k)-WFQ:– Marquage des paquets par la source selon -

pattern (introduction de deux priorités)– Estampillage des paquets selon le temps virtuel

de départ de WFQ


Algorithme (m,k)-WFQ

Paquet Critique Paquet Optionnel

Echéance RatéeEchéance Respectée

Envoyer le paquet Rejet du paquet

Sélection min(Fik)

parmi les paquets critiquesSinon parmi les paquets optionnel


Un exemple


(m,k) Débit Trafic -pattern Echéance Voix (4,5) 64 kb/s ON/OFF (500/755/50)ms 11011 10 ms

Vidéo (3,5) 2Mb/s Pseudo Périodique ~2Mb/s 10110 4 ms FTP (0,1) 7,936 Mb/s Pseudo Périodique ~7.936 Mb/s 0 Infinie

Performances de (m,k)-WFQ

Taille de paquet constante = 1 Ko

(m,k)-WFQ WFQ (m,k)-FIFO FIFOVoix 9,769 4776,83 20,529 48,031Vidéo 3,999 41,084 21,086 49,031FTP 3,837 18,048 21,442 49,083

Temps de réponse maximal simulé :

Taux de rejet (m,k)-WFQ: Voix: 6,8%Vidéo: 5,5%


Garantie de temps de réponse de (m,k)-WFQ

S

t

bits

(()-Shaper)-Shaper

(m, k)-Filtre(m, k)-Filtre

Flux CritiqueFlux Critique

(k-m,k)-Filtre(k-m,k)-Filtre (b,(b,)-Shaper)-Shaperk-mk-mkk

Flux OptionnelFlux Optionnel

*R (t)MUXMUX

*( ) , m k mR t bk k

R(t)

Le nombre maximum de paquets optionnels transmis par le serveur est l’ensemble des paquets ayant un délai inférieur à l’échéance désirée Dop : b = Dop (supposons que la bande passante du serveur g = )


Borne de temps de réponse de (m,k)-WFQ

• Les deux systèmes suivants sont équivalents• servi par un serveur WFQ

• servi par un serveur (m,k)-WFQ

• Borne sur le délai d’un flux ()-borné servi par (m,k)-WFQ

*( ) , m k mR t bk k

( ) , R t

** maxmax

LDC

* maxmax

Lm k mbDCk k


Borne de temps de réponse de (m,k)-WFQ

• Si aucun paquet optionnel n’est servi:

• Pour garantir un temps de réponse entre D*min et D*max, on peut ajuster Dop qui détermine b = Dop

* max

minLmDCk


Délai Garanti par (m,k)-WFQDélai Garanti par (m,k)-WFQ

*( , )

*max

max

m k WFQ LDC

( , ) maxmax

M Om k WFQ LbD

C

WFQ

maxmax

WFQ LD

C

Temps (sec)

Arrivées (bits)

DWFQ R

T= Lmax/c

Courbe de Service

Courbe d’arrivée

Le flux est ()-borné

(m,k)-WFQ

Temps (sec)

Arrivées (bits)

DWFQ R

T= Lmax/c

Courbe de ServiceCourbe

d’arrivée

D(m,k)-WFQ

*

*

Le flux est (**)-borné


4 – Remarques sur méthodes d’évaluation de bornes des temps de réponse

• Flux périodique et son enveloppe majorante (,)

t

6 5 4 3 2 1

Bornes pour majorer les flux d’entrée

F(t) périodique

F(t) périodique avec gigues

0 1 2 3 4 5 6 7

J


L’analyse de la trajectoire du « pire cas » vs. l’analyse de l’enveloppe majorante (,)

Serveur de capacité c

S1

S2

SN

.

.

.

ordonnancement

interarrivée

Exemple de priorité fixe

11

1

1

max ( ) ( 1)i

ni i j N j j

j

ni j

jI C C

I J

T

i i iR C I (si Ri < Ti)

1

1max 1

1

maxi

j i j N j

ji i

j

j

W

D

c

.i iW c Cavec


Questions?

Garantir la qualité de service temps réel: ordonnancement et gestion de files d’attente

Documents

Transcript of Garantir la qualité de service temps réel: ordonnancement et gestion de files d’attente