1

GRES'2001: Gestion de REseau et de Service

Marrakech, MAROC

La différentiation de service basée sur des

mesures

Abed-Ellatif Samhat, Tijani Chahed

Institut National des Télécommunications{abedellatif.samhat, tijani.chahed}@int-evry.fr

2

Plan • Introduction

• But

• Contenu

• Conclusions et perspectives

3

Introduction

• Internet Best effort : pas de garantie de QoS• IntServ: garantie de QoS , mais scalability

4

Introduction

• Le modèle DiffServ:• A l ’edge :Régulation, agrégation et marquage des flots en classes (EF, AF)

• Dans le core : Prioritisation relative entre les classes

routeur d’entrée

cœur du réseau

5

• But : - Proposer une architecture de différentiation de services dans le contexte des applications multimédia qui nécessitent une QoS- Implémentation du service EF

• Cette architecture, basée sur le modèle DiffServ, est proposée au niveau théorique et au niveau de sa mise en œuvre sur un testbed DiffServ

• Les fonctionnalités essentielles de cette architecture :- Agrégation des flots conditionnés par Token-Bucket à l ’edge en classes

- Dans le core une prioritisation relative selon le niveau de priorité de la classe

6

Testbed DiffServ

Fonctionalités EDGE

Fonctionalités CORE

7

Contenu

• A l ’edge, régulation par TB et agrégation des flots régulés

• La prioritisation dans le core

• Service EF

8

Régulation par TB • La régulation du trafic par un Token Bucket (TB) permet de contrôler

le volume entrant dans le réseau et le débit avec lequel il est transmis

• Le TB limite le nombre de paquets qui peuvent être transmis dans un intervalle de temps

• Il est caractérisé par deux paramètres: le débit moyen r et la taille du seau (bucket-size) b jetons (bits) qui implicite le débit crête

Trafic entrant

r,b

Trafic régulé

Régulation du trafic UDP par TB: efficace Régulation du trafic TCP par TB: non efficace

9

Régulation de TCP par TB

TCP : débit moyen 6M, différent bucket size

-2

0

2

4

6

8

10

0 5 10 15 20 25 30 35

temps en seconde

dé

bit

en

Mb

ps

bucket-size 6K bucket-size 64K

bucket-size 200K bucket-size 300K

Dans l’architecture proposée, pas de régulation de TCP par TB

10

Agrégation des flots

• Agrégation de N flots

• Un flot est caractérisé par: débit moyen r et burst-size b. Pour l’agrégat R et B

• Approche déterministe: R= ; B=

• Approche stochastique ( N sources ON/OFF identiques): R=N.r= ; B=b. K avec K: nb moyen des sources qui émet simultanément

N

ii r

1

N

iib

1

N

ii r

1

11

Agrégation par mesures

• Agrégation de deux flots identiques (r, b)

• Les folts sont contrôlés par TB

Trafic UDP

Trafic UDP

r,b

Flot1

r,b

Flot2

Flot agrégé

R= ? B= ?

12

• Résultats : - Pour le débit moyen: R= 2r

- Pour le burst size: b<= B <= 2b

• Gain de l ’agrégation en terme de burst-size : g= Σburst/burst mesuré

• Dans ces cas : g= 2b/burst mesuré

Agrégation de 2 flots

0

0,5

1

1,5

2

0 20 40 60 80 100 120

Burst size d'un flot en kbytes

Gain

en

te

rme

de

bu

rst

siz

e

Agrégation par mesures

13

Prioritisation• PQ

Ordonnanceur File haute priorité

File basse priorité

• UDP : résultats prévus

• TCP : pas de priorité stricte

14

Prioritisation

• CBQ non Conservative par classe• CBQ Conservative par classe

40%

Lien

Org.B

Org.C

50% 40% 10%

Org.A

Vidéo mail

10%

…….Audio

…….

10% 1%

telnet

• Réservation dans un nœud

• Solution pour la présence TCP-UDP

15

Offre de service EF (Expedited Forwarding) • Application nécessitant faible délai, faible perte, faible gigue• Emulation de circuit• Régulation du trafic en entrée ( policing), le trafic en excès est jeté• La majorité de ces applications utilisent UDP comme protocole de transport• Garantie à l ’échelle paquet ( PSRG)

t

Bits C

R

16

Implémentation du service EF

• Régulation du trafic EF par Token-bucket à l ’edge

• Dans le core

-Priority Queueing (PQ)

-CBQ non-conservative

-CBQ conservative

• Théoriquement, PQ est préférable pour la mise en œuvre de EF. Mais à noter que le trafic non-EF subit une forte fluctuation à cause de sa dépendance avec la présence de EF. Soit une disparition totale si EF est agréssif. D’où l’importance de la régulation.

17

Expérimentations

TB (2M,30bytes)

• Bande passante 10M.

•PQ

•CBQ non conservative

•CBQ conservative

5%95%

74%

lien

default

Non-EF

contrôle

21%

EF

18

Résultats par mesure

• Perte : aucune perte de paquets EF pour les trois cas

• Délai : taille de la file d ’attente EF, 0 et 1 pour PQ; 0 , 1 et 2 pour les autres

-2

0

2

4

6

8

10

12

0 20 40 60 80 100

EF: PQ,CBQ21%

non EF:CBQ 74% Con

nonEF:CBQ74%nonCon non EF : PQ

19

Résultats par mesure

0

0,5

1

1,5

2

2,5

3

0 10 20 30 40 50 60

temps en s

gigu

e en

ms

EF: PQ EF:CBQ 21% EF:CBQ 21%, non EF borrow

• Gigue :celle de PQ est plus petite

• PQ assure mieux dans le core la prioritisation du trafic EF régulé à l ’edge

20

Conclusion et perspectives• Proposition d’une architecture à différentiation de service ( théorique et pratique)

• Etude de l’agrégation des flots contrôlés par des token-buckets, en termes de débit moyen et burst size

• Dans cette architecture la régulation par TB est employée pour le trafic UDP

• Perspectives : La distribution du délai et de la perte subit par un agrégat entre les flots qui le constituant

• Démonstration de la capacité de l’architecture proposée à offrir le service EF. Le trafic EF est régulé à l’edge par TB. La discipline PQ assure le traitement différentié dans le core

• Autres types de service ( AF) : Les perspectives dans le contexte de DiffServ consistent à analyser les fonctionnalités :

• La quantification de l’impact de la prioritisation sur les agrégats et sur les flots qui les constituent

• La vision de bout-en-bout

- A l'edge : conditionneurs (trtcm), attribution de la priorité , RED, RIO…….. - Dans le core, disciplines de services …..

21

FIN

MERCI