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