Pfe-Said El Kafhali

Universit Hassan 1
er
Facult des Sciences et Techniques
SETTAT
MEMOIRE
Prsent pour lobtention du diplme du
Master Sciences et Techniques
S p c i a l i t : I n g n i e r i e M a t h m a t i q u e s e t
I n f o r m a t i q u e
Sujet
Etude et comparaison des mcanismes de gestion active des
files dattente
Ralis Par
Said EL KAFHALI
Soutenu le 22 Juillet 2009 devant le jury compos de :
Mr Hassan Essoufi Pr. la FST de Settat Prsident
Mr Amine Berqia Pr. lENSIAS, Rabat Examinateur
Mr Driss El Ouadghiri Pr. la Facult des Sciences de Mekns Examinateur
Mr Abdelkrim HAQIQ Pr. la FST de Settat Encadrant
Anne Universitaire : 2008-2009
Ddicace
Sil ny avait pas dhiver, le printemps ne serait pas si agrable: Si nous ne gotions pas
ladversit, la russite ne serait pas tant apprcie.
Anne Bradstreet
Ddicace
ma mre & mon pre
Vous tes pour moi une source de vie car sans vos sacrifices, votre tendresse et votre
affection je ne pourrais arriver jusquau bout. Je me rjouis de cet amour filial. Que Dieu
vous garde afin que votre regard puisse suivre ma destine.
mes frres & mes surs
Mon amour votre gard est une grandeur non quantifiable.
tous les membres de ma famille
mes professeurs
mes amis
En leurs souhaitant le succs dans leur vie aussi bien professionnelle que familiale.
tous ceux qui me sont chres
tous ceux pour qui je compte et qui comptent pour moi
tous ceux qui se sentent participants dans ma russite
Que dieu vous garde
Je ddie ce travail, titre de reconnaissance
Remerciements
Remerciements
Ce projet est le fruit de travail entrepris sous la direction de Mr. Abdelkrim HAQIQ,
professeur la FST de Settat. Je tiens lui exprimer ma plus grande reconnaissance pour la
confiance, lcoute et le soutien quil ma accords tout au long de la ralisation de ce
projet. Je le remercie vivement pour les nombreuses discussions, pour la gentillesse dont il a
toujours fait preuve mon gard et notamment pour les encouragements quil na cess de
me faire tout au long de ce travail. Quil trouve ici mes vritables considrations.
Je suis trs sensible lhonneur que me fait Mr. Hassan Essoufi, professeur la
FST de Settat, davoir bien voulu accepter de prsider le jury de ma soutenance. Que ce
travail soit pour moi loccasion de lui exprimer ma grande estime.
Je tiens aussi remercier vivement Mr. Amine Berqia, professeur l'ENSIAS,
Rabat, et Mr. Driss El Ouadghiri, professeur la facult des Sciences de Mekns, davoir
accepts de siger mon jury de soutenance. Je considre leur prsence parmi le jury comme
un tmoignage de haute valeur et je suis heureux de leur exprimer ma profonde gratitude.
Je remercie vivement tous les professeurs qui ont enseign dans le programme du
Master Sciences et Techniques Ingnierie Mathmatiques et Informatique, et
particulirement Mr. Khalid Allali, Mr. Mohamed Bahaj, Mr. Abdelkrim Haqiq, Mr.
Bouchaib Radi et Mr. Hassan Essoufi.
Je remercie galement lquipe de recherche du professeur Abdelkrim Haqiq, et plus
particulirement Mr. Mohamed Hanini, qui m'a, plusieurs reprises, tmoign de son
soutien et son aide.
Je remercie sincrement tous mes camarades, tudiants la FST de Settat et
particulirement tous les tudiants du Master Ingnierie Mathmatique et Informatique
pour leur amicale et efficace collaboration tout le long de cette formation.
Je garde une place toute particulire ma famille : ma mre Aicha, mon pre Ali, et tous
mes frre et surs. Je voudrais leur exprimer toute ma profonde reconnaissance et je leur
remercie du fond de mon cur car ils mont constamment aid, par leur soutien moral et leur
encouragement pour achever ce projet.
Rsum
Rsum
Pour viter la congestion dans les rseaux Internet, due laccroissement du trafic qui
transite par ces rseaux, on utilise des buffers (files dattente) dans les routeurs pour absorber
lexcs du trafic lorsque le dbit offert dpasse la capacit de transmission. Mais lespace limit
de ces buffers, entrane la perte des paquets dinformations au cours du temps.
Les mcanismes de gestion des files dattente se sont avrs dune grande utilit pour viter
la congestion des buffers. Ces mcanismes se diffrent par la mthode de slection des
paquets rejets. On distingue alors deux catgories de mcanismes : les mcanismes passifs (PQM
: Passive Queue Management) et les mcanismes actifs (AQM: Active Queue Management).
Dans ce mmoire, on propose de faire une tude des diffrents mcanismes de gestion active
des files dattente, notamment le mcanisme RED (Random Early Detection) et ses variantes, et
de faire ensuite une comparaison des performances de ces mcanismes.
Pour montrer lutilit de ces mcanismes pour lamlioration de la qualit de service
dans les rseaux Internet, on prsente lvaluation des performances du protocole MAODV
(Multicast Ad hoc On-Demand Distance Vector) par lutilisation de certains mcanismes de
gestion active de files dattente dans les rseaux Ad hoc.
Mots cls: Rseaux Internet, Congestion, Files dattente, Rseaux Ad hoc, Gestion active des files
dattente, RED.
Abstract
Abstract
To avoid congestion in Internet networks, due to increased traffic which transits
among them, we use buffers (Queues) in routers to handle the excess of traffic when the debit
exceeds the transmission capacity. But the limited space of these buffers, cause the loss of
packets of information over time.
Management mechanisms queues have great utilities to avoid buffers congestion.
These mechanisms differ in the method of selection of discarded packets. We distinguish two
categories of mechanisms: passives mechanisms (PQM: Passive Queue Management) and
actives mechanisms (AQM: Active Queue Management).
In this work, we propose to make a study of different mechanisms for the active queues
management, including the RED mechanism (Random Early Detection) and its variants, and
to compare their performances.
In order to show the importance of these mecanisms to improve the quality of service
in the Internet networks, we present the performances of the protocol MAODV (Multicast Ad
hoc On-Demand Distance Vector) bay using some Active Queue Management mechanisms in
the Ad hoc networks.
Keywords: Internet Networks, Congestion, Queues, Ad hoc Networks, Active Queues
Management, RED.
Table des Matires
5
Table des Matires
GLOSSAIRE ......................................................................................................................................................... 7
CHAPITRE 1 : INTRODUCTION ET MOTIVATION ................................................................................. 10
CHAPITRE 2 : CONTROLE DE CONGESTION.......................................................................................... 14
1- INTRODUCTION ............................................................................................................................................. 15
2- LE PROBLEME DE CONGESTION ..................................................................................................................... 15
3- LE CONTROLE DE CONGESTION ..................................................................................................................... 16
4-CERTAINS PARAMETRES DE PERFORMANCE POUR LE CONTROLE DE CONGESTION ......................................... 19
4.1- Le taux de perte de paquets.................................................................................................................. 19
4.2- Le dbit................................................................................................................................................. 19
4.3-Le dlai dattente................................................................................................................................... 19
4.4- La taille moyenne de la file dattente ................................................................................................... 20
CHAPITRE 3 : ETAT DE LART DES MECANISMES DE GESTION ACTIVE DES FILES
DATTENTE (AQM) .......................................................................................................................................... 21
1- INTRODUCTION ............................................................................................................................................. 22
2- PRESENTATION DE CERTAINS MECANISMES DE LA GESTION ACTIVE DES FILES DATTENTE........................... 22
2.1- RED (Random Early Detection)........................................................................................................... 22
2.2- GRED (Gentle RED) ............................................................................................................................ 24
2.3- ARED (Adaptative RED) ...................................................................................................................... 25
2.4- BLUE.................................................................................................................................................... 26
2.5- Stabilized RED (SRED) ........................................................................................................................ 26
2.6- Random Exponential Marking (REM).................................................................................................. 29
2.7- Double Slope RED (DSRED) ............................................................................................................... 30
2.8- RED with In and Out ............................................................................................................................ 31
2.9- CHOKe................................................................................................................................................. 32
2.10- Weighted Random Early Detection (WRED)...................................................................................... 34
2.11- Dynamic-RED (DRED) ...................................................................................................................... 35
2.12- Flow Random Early Drop (FRED) .................................................................................................... 35
2.13- Selective Fair Early Detection (SFED) .............................................................................................. 36
2.14- Balanced RED (BRED) ...................................................................................................................... 37
2.15- Adaptive Virtual Queue (AVQ)........................................................................................................... 39
2.16- GREEN (Generalized Random Early Evasion Network).................................................................... 40
2.17- LRED (Loss Ratio based RED) .......................................................................................................... 42
2.18- Proportional Integral controller (PI controller) ............................................................................... 44
3- CONCLUSION................................................................................................................................................. 45
CHAPITRE 4 : COMPARAISON DES MECANISMES DE GESTION ACTIVE DES FILES
DATTENTE (AQM) .......................................................................................................................................... 46
1- COMPARAISON DES PERFORMANCES DE TD, RED ET REM.......................................................................... 47
2- COMPARAISON DES PERFORMANCES DE RED, ARED ET BLUE................................................................... 47
3- COMPARAISON DES PERFORMANCES DE TD, GREEN ET FRED ................................................................... 48
4- COMPARAISON DES PERFORMANCES DE RED, PI, AVQ ET REM.................................................................. 49
5- COMPARAISON DES PERFORMANCES DE DT, RED, BLUE, REM ET PI......................................................... 50
6- COMPARAISON DES PERFORMANCES DE CHOKE, FRED, RED ET SFED..................................................... 50
7- COMPARAISON DES PERFORMANCES DE DT, RED, REM ET AVQ................................................................ 50
CHAPITRE 5 : UTILISATION DE CERTAINS MECANISMES DE GESTION ACTIVE DES FILES
D'ATTENTE POUR LE ROUTAGE DANS LES RESEAUX AD HOC....................................................... 52
1- INTRODUCTION ............................................................................................................................................. 53
2- LES RESEAUX AD HOC (MOBILE AD HOC NETWORK) ................................................................................... 53
2.1- Les caractristiques des rseaux Ad hoc.............................................................................................. 53
2.2- Les protocoles de routage .................................................................................................................... 54
2.3- Communication dans les rseaux Ad hoc............................................................................................. 57
2.4- Gestion dnergie en mode Ad-hoc ...................................................................................................... 58
3- LEVOLUTION DES PERFORMANCES DU PROTOCOLE MAOVD PAR LUTILISATION DE CERTAINS MECANISMES
DE GESTION ACTIVE DES FILES DATTENTE DANS LES RESEAUX AD HOC ........................................................... 58
Table des Matires
6
3.1- Description du protocole MAODV....................................................................................................... 58
3.2- Amlioration des performances de MAODV par la gestion active des files dattente ......................... 59
CONCLUSION ET PERSPECTIVES .............................................................................................................. 63
ANNEXE A : RESULTATS DE SIMULATION ............................................................................................. 66
ANNEXE B : PRESENTATION DU SIMULATEUR NS-2 .......................................................................... 76
1- INTRODUCTION ............................................................................................................................................. 77
2- ORGANISATION DU SIMULATEUR NS-2 ......................................................................................................... 77
3- PRESENTATION DE TCL ................................................................................................................................. 78
4- PRESENTATION DE OTCL .............................................................................................................................. 79
5- ARCHITECTURE DU RESEAU .......................................................................................................................... 80
5.1-Nuds de rseau.................................................................................................................................... 80
5.2- Liens de communication entre les rseaux........................................................................................... 81
5.3- Agents de communication..................................................................................................................... 81
5.4- Applications.......................................................................................................................................... 82
6- PRINCIPE DUTILISATION............................................................................................................................... 82
BIBLIOGRAPHIE ET WEBOGRAPHIE........................................................................................................ 84
Glossaire
7
Glossaire
Glossaire
8
- AODV : Ad Hoc On-Demand Distance-Vector Protocol
- AQM : Active Queue Management
- ARED : Adaptative RED
- ATIM : Ad-Hoc Traffic Information Map
- ATM : Assynchrone Transfer Mode
- AVQ : Adaptive Virtual Queue
- BRED : Balanced Random Early Detection
- CBR : Constant Bit Rate
- CCDF : Cumulative Ccomplementary Distribution Function
- CHOKe : CHOose and Keep the responsitive flows, CHOose and Kill the
unresponsitive flows
- DiffServ: Differentiated Services
- DRED : Dynamic Random Early Detection
- DSDV : Destination-Sequenced Distance Vector Protocol
- DSR : Dynamic Source Routing
- DSRED : Double Slope RED
- ECN : Explicit Congestion Notification
- EWMA : Exponential Weighted Moving Average
- FQ : Fair Queuing
- FRED : Flow Random Early Drop
- FSR : Fish-eye State Routing
- FTP : File Transfert Protocol
- GRED : Gentle RED
- GREEN : Generalized Random Early Evasion Network
- HTML : Hyper Text Markup Language
- HTTP : Hyper Text Transfert Protocol
- IETF : Internet Engeneering Task Force
- IntServ : Integrated Services
- LRED : Loss Ratio based RED
- MANET : Mobile Ad hoc NETwork
- MAODV : Multicast Ad hoc On-Demand Distance Vector
- NAM : Network Animator
Glossaire
9
- NS : Network Simulator
- OLSR : Optimized Link State Routing Protocol
- OTcl : Object Tool Command Language
- PQM : Passive Queue Management
- QdS : Qualit de Service
- QoS : Quality of Service
- RED : Random Early Detection
- REM : Random Exponential Marking
- RERR : Route Error
- RIO : RED with In and Out
- RREP : Route Reply
- RREQ : Route Request
- RTT : Round Trip Time
- RTT : Round Trip Time
- SFED : Selective Fair Early Detection
- SMTP : Simple Mail Transfert Protocol
- SNMP : Simple Network Management Protocol
- SRED : Stabilized RED
- STARA: System and Traffic dependent Adaptive Routing Algorithm
- TBRPF : Topology Broadcast Based on Reverse-Path Forwarding
- TCP/IP : Transport Control Protocol / Internet Protocol
- TD : Tail Drop
- TO : Time Out
- TORA : Temporally Ordered Routing Algorithm
- WRED : Weighted Random Early Detection
- WWW : World Wide Web
- ZRP : Zone Routing Protocol
Chapitre 1 : Introduction et motivation
10
11
Aujourd'hui dans les rseaux Internet, la retransmission des paquets due une
expiration des horloges ou la perte de paquets ou encore la taille limite des files d'attente,
sont les diffrentes causes de la congestion au niveau des routeurs. Cette congestion sera par
la suite la cause de longs dlais de bout en bout. Et le service ne peut pas assurer une qualit
de service (Quality of Service : QoS) suffisante pour les applications temps rel. Pour ces
applications le dlai dattente, la perte des paquets et le dbit ont une importance pour garantir
la performance. Diverses approches ont t proposes dans la littrature pour garantir une
qualit de service aux applications ayant de telles contraintes de QoS. La plus encourageante
est une solution qui se base sur un marquage/suppression des paquets avant que la file
dattente soit pleine avec un traitement diffrenci. La complexit est carte dans les
extrmits du rseau. Le cur du rseau est laiss aussi simple que possible. L'architecture de
qualit de service DiffServ (Differentiated Services) s'appuie sur cette dernire approche pour
garantir une qualit de service aux applications temps rel.
Le contrle de congestion dans les files dattente, dsigne lensemble des actions du
rseau qui permettent de minimiser lintensit et les effets dun ventuel tat de congestion.
Pour raliser ce contrle plusieurs algorithmes ont t proposs dans la littrature, leur
rle commun est de dcider quand et comment liminer des paquets afin dviter la
congestion du rseau [66].
La performance dun tel algorithme peut tre value par sa capacit contrler le
trafic dune manire efficace garantissant une quantit de service acceptable pendant les
priodes de congestion. Tail Drop (TD) est le mcanisme classique pour grer les files
dattente, ce mcanisme nlimine les paquets que lorsque la taille maximale du buffer est
atteinte.
La technique TD permet dcouler en priorit les paquets qui arrivent en premier dans
la file dattente. Si la longueur de celle-ci atteigne la taille maximale, les nouveaux paquets
qui arrivent sont automatiquement limins. Ltat de saturation est, trivialement, d au
phnomne suivant : le dbit darrive des paquets dans la file est suprieur au dbit de sortie.
Cette mthode est utilise par dfaut, mais savre inadquate lorsque la charge sur le routeur
est intense car elle gnre une file dattente engorge ainsi que de grandes pertes de paquets.
En dpit de la simplicit dimplmentation de TD, ce mcanisme prsente quelques
inconvnients :
12
- Il ne permet pas de distinguer la priorit des trafics.
- Il entrane une diminution de lutilisation du rseau, due la synchronisation entre les
diffrentes connexions qui subissent des pertes au mme moment et ralentissent
simultanment leurs dbits.
- Il pnalise les flux qui envoient le trafic en rafles, et peut conduire une
monopolisation du lien par certaines connexions.
- Il entrane des dlais dattente relativement longs.
Pour remdier aux inconvnients du TD, les mcanismes de gestion active des files
dattente (AQM) adoptent une approche prventive en liminant les paquets avant la
saturation du buffer, et ceci avec une probabilit dpendant de la taille de la file. Ceci permet
dviter la saturation de la file dattente en avertissant lmetteur que la file est quasi-remplie
pour rduire son dbit et rejette des paquets avant que la file soit pleine.
Plusieurs AQM ont t proposs dans la littrature ; Floyd et Jacobson prsentaient
lalgorithme RED (Rondom Early Detection) [24], dont plusieurs variantes amliores ont t
ensuite proposes.
Le problme de congestion des paquets dans les rseaux Internet aura une influence
grave sur les performances de ces rseaux.
Les algorithmes de type AQM (Active Queue Management) sont inspirs de RED
(Random Early Detection), leur point commun est de provoquer des pertes anticipes pour
contrler les utilisateurs de TCP Reno qui forment le flux lastique des routeurs. Tous ces
algorithmes ont un problme en commun, cest quils sont trs difficiles rgler au vu de la
grande varit des situations possibles. De sorte que si RED est aujourdhui implment dans
tous les routeurs, il nest presque jamais activ. Rappelons de plus que sur le plan de la
conception des rseaux, lutilisation de RED a de nombreux opposants du fait que le rseau
pnalise indiffremment tous les utilisateurs en dtruisant des paquets pour contrler
uniquement certains dentre eux qui utilisent un protocole qui pourrait bien disparatre un
jour. Il convient donc de rserver les usages des AQM aux cas o la congestion savre aigue
et en diffrenciant le trafic lastique des autres types de donnes changes [39].
Lobjectif de ce travail est de faire une prsentation dtaille des diffrents
mcanismes de gestion active des files dattente ainsi quune tude comparative et critique de
ces mcanismes.
13
Certains de ces mcanismes ont t utiliss la fin de ce travail pour valuer les
performances du protocole MAODV (Multicast Ad hoc On-Demand Distance Vector) dans un
rseau Ad hoc.
Le reste de ce mmoire est organis comme suit : dans le chapitre 2 nous prsentons
une tude gnrale sur le contrle de congestion. Dans le chapitre 3 on prsente certains
mcanismes de gestion active des files dattente. Dans le chapitre 4, notre contribution porte
sur la comparaison des performances des mcanismes de gestion active des files dattente
tudis. Le chapitre 5 est consacr lutilisation de certains mcanismes de gestion active des
files d'attente pour le routage dans les rseaux Ad hoc. Ensuite, une conclusion gnrale et
des perspectives sont donnes. Enfin, on donne deux annexes, la premire prsente les
rsultats des simulations des diffrents mcanismes de gestion active des files dattente
prsents dans ce projet et la deuxime donne une brve prsentation du logiciel de simulation
NS (Network Simulator).
Chapitre 2 : Contrle de congestion
14
15
1- Introduction
Aujourdhui, la consommation de la bande passante sur Internet a explos, surtout par
limplantation des services audio et vido qui gnrent de trs hauts dbits, et galement par
le nombre dutilisateurs qui ne cesse daugmenter. Ceci ne peut quencombrer la bande
passante, engendrer des dlais trs importants de transfert et donc dgrader dangereusement la
qualit de service du rseau. Do la ncessit de contrler la congestion par des mcanismes
bien spcifis, afin dviter lcroulement des performances dun rseau lorsque la charge sur
celui-ci devient importante.
Le contrle de congestion dans les rseaux Internet est une action cruciale permettant
dassurer lacheminement optimal des paquets et de garantir la qualit de service du rseau.
Reposant sur le principe de bout en bout, TCP savre le protocole le plus fiable, capable de
pallier les inconvnients de la congestion par le biais de diffrents mcanismes. A savoir, la
technique la plus basique le fentrage et limplantation des diffrentes phases du transfert
TCP.
Les services avancs des rseaux Internet sont ncessaires pour transfrer des
informations prcises vers des destinations correctes, en temps rel. Donc il faut que ces
rseaux supportent des grandes quantits dinformations et permettent de les changer entre
les diffrents partenaires. Pour cela il est judicieux daugmenter la qualit de service (QoS)
qui garantie la performance et dmunie la perte dinformations entre le destinataire et
lmetteur.
2- Le problme de congestion
La congestion dun rseau correspond un phnomne de goulot dtranglement
lorsque des points de trafic dpassent la capacit du rseau. En particulier, la congestion du
rseau peut se produire lorsque la capacit de lien dentre est plus grande que la capacit de
lien de sortie. La congestion galement se produit lorsque de multiples flux dentre
parviennent un routeur dont la capacit de sortie est infrieure la somme des entres. Sil y
a n sources avec un dbit D pour un rseau ayant un lien offrant un dbit qui est infrieur
nD, une congestion du rseau se produit [37]. Et plus prcisment les problmes de
congestion arrivent lorsque les nuds dun rseau saturent leurs files dattente comme le
montre la figure ci-dessous.
16
Figure 1 : Problme de congestion dans un rseau
La congestion est dfinie comme l'tat des quipements du rseau, dans lequel le
rseau n'est pas en mesure de satisfaire les objectifs ngocis en matire de performance pour
les connexions dj tablies ou pour de nouvelles demandes d'tablissement de connexion. De
plus elle provoque des pertes de paquets, pertes qui peuvent s'avrer excessives vis--vis de
la qualit de service ( Quality of Service) ngocie avec les applications, et la saturation des
espaces de stockage des paquets, saturation qui peut entraner des temps de transfert des
paquets inacceptables vis--vis de la qualit de service ngocie avec les applications [9].
Lorsque le dbit diminue, il faut plus de temps pour tlcharger une page. Ce faisant la
proportion du temps que lon passe tlcharger par rapport au temps pendant lequel on lit
devient de plus en plus grande. Ceci explique le phnomne dauto-amplification de la
congestion. Dautre part la file dattente ne sert rien dans cet exemple part augmenter le
temps de transmission, ce qui permet des fentres plus grandes pour le mme dbit. Dans tous
les cas, on est ici face un problme de congestion svre, la seule solution pour lviter est
daugmenter le dbit disponible ou de diminuer le nombre dutilisateurs [39].
Les problmes de congestion entrainement des risques de rejet pour les paquets en
attente dacheminement : le routeur stocke et traite les paquets en cours de transit en fonction
de leur ordre darrive et des ressources disponibles. Les limites de capacits des mmoires
tampon et les dlais maximums de transmission dun paquet peuvent induire des rejets
dinformations, non pas parce que les paquets sont errons mais parce que les paquets nont
pas pu tre traits dans le temps imparti. Ces rejets, lis des problmes de capacit de
linfrastructure de communication, imposent de retransmettre linformation et peuvent donc
aggraver les problmes de congestion [37].
3- Le contrle de congestion
Le contrle de congestion est un mcanisme visant adapter les sources de trafic aux
conditions variables du rseau. Ainsi, lorsqu'une congestion se produit, suite une
17
augmentation de la charge du rseau, le contrle de congestion doit en aviser les sources pour
qu'elles adaptent leur trafic afin d'viter la congestion ou la rduire [66].
La gestion des congestions, lun des problmes cruciaux du travail en rseau, est
usuellement traite par le destinataire final des informations grce des algorithmes
appropris. Dans limplantation actuelle des rseaux Internet, le niveau transport,
particulirement le protocole TCP, est fortement pnalis du fait du fort taux de pertes de
paquets, pertes souvent lies lexpiration de leur dure de vie, notamment pendant les
priodes de congestion du rseau ce qui affecte le niveau de Qualit de service (QoS). Pour
rpondre ces problmes, une dmarche en deux temps a t propose [37]:
- Une modlisation du fonctionnement des quipements dinterconnexion et du trafic
gnr par des applications types qui doit permettre terme de mieux apprhender les
performances de linfrastructure de communication.
- Un algorithme de gestion de congestion implant sur des nuds nvralgiques peut
permettre, en quilibrant les charges, daugmenter le niveau de qualit de service global et
pnalisant le moins possible les flux peu agressifs.
Plusieurs techniques sont utilises pour le contrle de congestion, dont le feedback et
ladaptation :
Le feedback : est utilise pour contrler l'tat du rseau et en aviser l'metteur. Le
plus important signal de feedback est le signal de congestion par lequel une application
dtecte qu'un certain nombre de ses paquets ont t limins par le rseau. Ce mcanisme peut
tre implicite, lorsque le rseau limine simplement les paquets en excs, ou explicite, lorsque
le rseau notifie l'application la prsence d'une congestion. Le protocole TCP utilise un
feedback implicite. Le TCP metteur dtecte la prsence d'une congestion suite l'expiration
d'un temporisateur d'acquittement, ou suite la rception d'un double acquittement (duplicate
acknowledgement) envoye par le TCP rcepteur ayant dtect une perte de paquets [66].
Ladaptation : Le mcanisme d'adaptation est la suite logique du feedback.
Lorsqu'une situation anormale est dtecte dans le rseau, le mcanisme d'adaptation modifie
le trafic pour l'adapter aux nouvelles conditions du rseau. Les mcanismes slow-start et
congestion avoidance du protocole TCP sont des formes d'adaptation. Lorsqu'une congestion
est dtecte suite une perte de paquets, TCP modifie son dbit d'mission afin d'viter une
telle congestion. Ce mcanisme suppose que toutes les sources se comportent de la mme
18
faon pour maximiser l'utilit du rseau, ce qui n'est pas le cas. En effet, les applications
temps-rel n'adaptent pas leur dbit d'mission l'tat du rseau, et la congestion est contrle
grce aux sessions TCP qui rduisent leur dbit d'mission. Le rseau peut forcer l'adaptation
du trafic par l'intermdiaire de mcanismes mis en uvre dans les routeurs d'accs (edge
routers) tels le lissage de trafic (trafic shaping) ou la surveillance de trafic (trafic policing) qui
procdent par retardement, marquage ou limination de certains paquets. Ces mcanismes
sont efficaces puisqu'ils ne supposent pas que l'utilisateur adaptera son dbit d'mission de son
propre gr [66].
Deux objectifs opposs et contradictoires peuvent tre attribus au contrle de
congestion, le premier est relatif au service offert aux applications, le second est relatif
l'optimisation du rseau. Le premier objectif est de garantir pour chaque connexion la qualit
de la transmission des donnes en terme, par exemple, de taux de perte des paquets et de dlai
de transfert. Le deuxime objectif est de grer de manire optimale les ressources du rseau
afin de servir le plus d'applications possibles au mieux.
Les mcanismes mis en uvre pour assurer le contrle de congestion doivent possder
les proprits suivantes : la flexibilit, l'efficacit, la robustesse. La flexibilit permet au
contrle de congestion de s'adapter aux diffrents types de qualit de service demand par les
applications. L'efficacit, grce une utilisation de mcanismes de contrle de congestion
simples (peu complexes) et systmatiques (homognes), permet l'utilisation maximum des
ressources disponibles du rseau. La robustesse assure une conservation de l'offre des services
de transmission en toutes circonstances [9].
Deux grandes classes de mcanismes de contrle de congestion peuvent tre
discernes : la classe des mcanismes passifs (ractifs) et celle des mcanismes actifs
(prventifs).
Les mcanismes passifs: Ce sont des mcanismes qui ragissent aprs lapparition de la
congestion. Ils consistent rejeter les paquets quand les files dattente sont pleines. Lide de
base est dagir en fonction de l'volution de l'tat du rseau selon le degr de congestion
attient. La mesure de la congestion peut se faire de plusieurs manires (en mesurant les pertes,
les dlais, le remplissage des buffers, etc.) par le rseau ou par les quipements terminaux. Si
une congestion se dclare la source diminue son dbit. Le principe du contrle passif est de
pouvoir partager les ressources par le maximum de connexions pour optimiser l'utilisation du
rseau. De ce fait, ce type de contrle peut tre appropri aux connexions de donnes qui
19
peuvent s'adapter aux conditions du rseau. Cependant, il n'est pas adapt aux connexions qui
ncessitent une garantie de qualit de service tel que les services vido en temps rel.
Les mcanismes actifs : Ce sont des mcanismes qui permettent de prvenir la congestion.
Qui dterminent la raction des routeurs face au remplissage de leur file dattente. En effet ils
consistent prendre des mesures a priori, visant minimiser les chances de lapparition dune
congestion et de protger le rseau contre les rafales de donnes, et ce afin de pouvoir assurer
une qualit de service satisfaisante. Nous verrons ces mcanismes plus loin dans le chapitre 3.
4-Certains paramtres de performance pour le contrle de congestion
4.1- Le taux de perte de paquets
Le taux de perte de paquets reprsente la quantit dinformations rejete pour cause
derreur de transmission. les pertes sont gnralement dues soit au non-fiabilit des liens physiques
soit aux mcanismes de gestion des files dattente dans les routeurs intermdiaires qui se trouvent
souvent obligs dliminer des paquets pour faire face des situations de congestion. Ce facteur est
trs important. En effet, certaines applications ne tolrent pas des valeurs leves de ce facteur.
4.2- Le dbit
Le dbit dfinit le nombre maximum dinformations qui doit tre transport sur une
connexion de rseau dans un temps long. Cest la quantit dinformations transmise par unit
de temps. Les applications requrant un certain dbit dinformations verront leurs
performances seffondrer (temps dattente long entre laffichage de formulaire,) ou
deviendront incomprhensible. Cest en fait le taux de transfert maximum pouvant tre maintenu
entre deux points terminaux (un metteur et un rcepteur), ce facteur est influenc non seulement par
les capacits physiques des liens, mais aussi par les autres flux partageant ces liens.
4.3-Le dlai dattente
Le dlai dattente est le temps mis par un paquet pour aller de la machine mettrice
vers la machine rceptrice. Cest le temps coul entre lenvoi dun paquet par lmetteur et sa
rception par le destinataire, le dlai tient compte du dlai de propagation le long du chemin parcouru
par les paquets et du dlai de transmission induit par la mise en file dattente des paquets dans les
systmes intermdiaires (les routeurs). La plupart des applications et surtout les applications temps
rel sont trs sensibles aux valeurs leves de dlais et exigent un dlai limit pour quelles puissent
fonctionner correctement.
20
4.4- La taille moyenne de la file dattente
La taille moyenne de la file dattente est le nombre des paquets qui occupent le buffer
dattente lorsque linterface de sortie dun routeur est pleine.
Chapitre 3 : Etat de lart des mcanismes de gestion active des files dattente (AQM)
21
Chapitre 3 : Etat de lart des mcanismes de gestion
active des files dattente (AQM)
22
1- Introduction
La gestion active des files dattente est un axe de recherche dactualit qui prsente un
intrt croissant attirant de plus en plus dquipe de recherche.
La gestion active des files d'attente adoptent une approche prventive en liminant les
paquets avant la saturation du buffer, et ceci avec une probabilit dpendant de la taille de la
file. Sa performance peut tre value par sa capacit contrler le trafic de manire quitable
et efficace pendant les priodes de congestion contrairement au TCP qui permet dinforme
les sources dajuster leurs taux de transmission selon le degr de congestion. Les mcanismes
de gestion des files d'attente sont ncessaires dans les routeurs pour complter les mcanismes
de contrle de congestion.
2- Prsentation de certains mcanismes de la gestion active des files
dattente
2.1- RED (Random Early Detection)
Le RED a t propos par S. Floyd et V. Jacobson en 1993 [24]. Son objectif est,
dune part, de contrler la longueur de la file dattente dans les buffers et dautre part, dviter
les inconvnients du Drop Tail, pour lequel un buffer satur entrane la baisse des dbits de
toutes les sources qui lutilisant (problme de synchronisation).
Le mcanisme RED rejette les paquets entrants avec une certaine probabilit avant que
les buffers ne soient pleins [63]. Pour dtecter la congestion, RED maintient une moyenne
mouvante qui est pondre de manire exponentielle pour la longueur de la file dattente
laide de lalgorithme EWMA (Exponential Weighted Moving Average) [37].
Figure 2 : volution de la probabilit de perte de RED en fonction de la taille moyenne de la
file d'attente.
23
Le paramtre avg qui dsigne la taille moyenne de la file dattente est initialis 0, et
chaque arrive dun paquet, avg prend la valeur :
(1 )
q q
avg w avg w q = +
o q est la taille relle de la file dattente et
q
w est le poids de la file dattente, il intgre des
informations sur le nombre et la taille des paquets en attente.
Le RED fixe deux seuils
th
Min et
th
Max tels que
th th
Min Max < . Quand la taille de la
file dpasse le seuil
th
Min , le RED commence rejeter les paquets entrants avec la probabilit
P donne par la formule ci-dessous. Cette probabilit crot linairement en fonction de la
taille de la fille. Au-del du seuil
th
Max , tous les nouveaux paquets entrants sont rejets
comme le montre la figure 2.
th
0 si avg ,
si ;
1 si avg Max .
th
th
P th th
th th
Min
avg Min
P Max Min avg Max
Max Min
<

= s <
>
o
p
Max dsigne la probabilit maximale de rejet de paquet.
Lalgorithme simplifi de ce mcanisme est le suivant :
Pour chaque paquet reu
Calculer la taille moyenne de file avg
Si
th th
Min avg Max s < alors
Calculer la probabilit P
Marquer/Supprimer le paquet avec la probabilit P
Sinon si
th
avg Max >
Supprimer le paquet avec la probabilit P
Fin Si
Malgr sa politique de prvention de la congestion, lalgorithme RED prsente
quelques problmes, tels que :
- La taille de la file ne donne pas dindication sur le type de congestion.
- Problme du choix adapt des paramtres de configuration.
24
Le systme de gestion de la file RED est un exemple de modification du niveau rseau
seul (le systme Tail Drop est remplac par RED dans les routeurs). Les routeurs sont les
quipements qui subissent la congestion ; il n'y a qu'eux qui peuvent la voir venir
suffisamment tt et envoyer le signal. La mise en place de ce mcanisme, ou d'un mcanisme
similaire, a pour objectif de prvenir la congestion en la signalant par une perte, avant que
celle-ci se produise [8].
2.2- GRED (Gentle RED)
Le GRED propos dans [25] est une amlioration de RED, il adopte la mme approche
que RED mais attarde le rejet des paquets on ajoutant un autre intervalle dans le calcule de la
probabilit de rejet, il sen diffre par les points suivants :
- 100% de rejet des paquets est effectue seulement quand avg est deux fois gale
au
th
Max .
- Quand 2
th th
Min avg Max s < , le GRED commence rejeter alatoirement les paquets
entrants avec la probabilit Q donne ci-dessous. Cette probabilit augmente de manire
linaire par morceaux en fonction de la taille de la file.
0 si ,
si ;
(1 )( )
si 2
1
th
th
P th th
th th
P th
p th th
th
avg Min
avg Min
Max Min avg Max
Max Min
Q
Max avg Max
Max Max avg Max
Max
<
s <
=

+ s <
th
si 2 . avg Max
>
Figure 3 : volution de la probabilit de perte de GRED en fonction de la taille moyenne de la

file d'attente.
Cette version de RED prsente lavantage de ne pas introduire de discontinuit dans la
dynamique dvolution des pertes [39].
25
2.3- ARED (Adaptative RED)
Lide de base pour une solution rsolvant les problmes de RED repose sur le ARED
original propos par Feng et Al. en 2001 [26]. Ce mcanisme est conu comme une adaptation
de lalgorithme RED il permet damliorer les performances de RED en adaptant le paramtre
p
Max (la probabilit maximale de suppression) en fonction de la charge du trafic.
Si la taille moyenne de la file est proche de
th
Min , cela montre que la dtection
prcoce de la congestion est trop agressive. Dans ce cas, on faite dcrotre la valeur de
p
Max dun facteur constant . Dautre part, si la taille moyenne est proche de
th
Max , cela
signifie que la dtection prcoce est trop conservatrice. Dans ce cas, la valeur de
p
Max est
augmente dun facteur constant . Cependant, si la taille moyenne oscille bien
entre
th
Min et
th
Max , on ne change pas la valeur de
p
Max . Cette configuration de
p
Max fait en
sorte que la taille de la file dattente oscille entre
th
Min et
th
Max [60].
Lalgorithme ARED permet de rejeter prventivement des paquets pour offrir une
gestion proactive des congestions en fonction des besoins en bande passante des diffrentes
sources, et suppose que les quipements grent leur files de sortie selon une logique FIFO, ce
qui est le mode par dfaut dans la plupart des cas [37].
Lalgorithme de ce mcanisme est le suivant :
A chaque mise jour de avg :
Si (
th th
Min avg Max < s ) alors
statut= entre ;
Fin Si
Si( && !
th
avg Min statut entre < = ) alors
statut = dessous ;
/
p p
Max Max o = ;
Fin Si
Si ( && !
th
avg Max statut dessus > = ) alors
statut = dessus ;
*
p p
Max Max | = ;
Fin Si
oo et | sont deux facteurs tous suprieurs 1.
26
2.4- BLUE
Le BLUE a t propos par Feng et Al. en 1999 [22]. Cest le premier mcanisme de
gestion active des files dattente qui ne prend pas en compte la longueur de la file dattente
pour calculer la probabilit de suppression des paquets. Il est utilis pour amliorer les
performances de RED en termes destimation des paquets perdus et la taille du buffer du
rseau.
BLUE utilise la dure doccupation du lien pour indiquer la congestion. Il entretient
une probabilit P pour marquer/ supprimer les paquets entrants. La probabilit P est
incrmente par d1 quand le paquet est supprim due buffer overflow. Cette probabilit est
dcrment par d2 quand la file d'attente est vide. L'intervalle minimal pour augmenter ou
diminuer la probabilit de marquage est configur pour une _ freeze time un intervalle pour
viter de changer la probabilit de marquage de manire trop agressive.
Lalgorithme de ce mcanisme est le suivant [60]:
Pour chaque paquet perdu :
Si (( now-last_update) >freeze_time) alors
P=P+d1;
last_update = now;
Fin Si
Pour chaque lien disponible:
Si ((now-last_update) >freeze_time) alors
P=P-d2;
last_update = now;
Fin Si
Pour chaque paquet arriv :
Marquer ou supprimer le paquet avec la probabilit P.
- P : la probabilit utilise pour marquer ou supprimer les paquets.
- freeze_time : lintervalle du temps minimal entre deux mises jour successives de P.
- d1 : la valeur dincrmentation de P lorsque la file est pleine.
- d2 : la valeur de dcrmentation de P lorsque le lien est disponible.
- now : la date courante du systme.
- last_udpdate : la date de la dernire mise jour de P.
2.5- Stabilized RED (SRED)
SRED (Stabilized RED) cest un mcanisme propos par Ott et al. en 1999 [54]. Qui
permet de stabiliser la longueur de la file dattente. Les oscillations de la file d'attente de RED
27
dpendent souvent du nombre de flux, alors SRED utilise une technique statistique pour
estimer le nombre de flux actifs afin d'liminer cette dpendance.
SRED fonctionne comme suit: chaque fois qu'un nouveau paquet arrive, il est compar
au hasard un paquet qui a t reu avant. Si les deux paquets appartiennent au mme flux,
un hit est dclar, et le nombre de hit est utilis pour calculer l'estimation du nombre de
flux actifs. De plus, la file d'attente ne doit pas limiter la possibilit de remarquer que les
paquets vont ensemble, cette fonction n'est pas atteinte par le choix d'un paquet alatoire du
buffer, alors une zombie liste est conserve sa place.
Cela fonctionne comme suit: pour tous les paquets qui arrivent, un identificateur de
flux est ajout la liste avec un timestamp (temps d'arrive du paquet) et un "Count" qui est
initialement mis zro. Cela se poursuit jusqu' ce que la liste soit pleine, puis lidentifiant du
flux d'arrive des paquets est compar l'identifiant d'une entre choisis au hasard dans la
liste (ce qu'on appelle un zombie). Dans le cas d'un "hit", le "Count" du zombie est
augment de 1. Autrement, les zombies sont remplacs par lidentifiant du flux du nouveau
paquet arriv avec une probabilit P. Avec la probabilit 1 - P, il n'y a aucun changement de
la liste des zombies.
Les auteurs de [54] ont estim le nombre des flux actifs de moyenne "hit" comme
dcrit ci-dessous. Ils estiment en premier la frquence du "hit" P(t) au temps de l'arrive du t-
th paquets s'accorder la formule suivante: ( ) (1 ) ( 1) ( ) P t P t Hit t o o = + (2.5.1)
o o est une constante tel que 0 1 o < < , et
0 si aucun hit,
( )
1 si hit.
Hit t

=

(2.5.2)
Les auteurs montrent que 1/ ( ) P t est une bonne estimation pour le nombre N du flux
actifs jusqu' l'arrive du t - th paquets. Au lieu d'utiliser la longueur moyenne de la file
comme RED, SRED calcule la probabilit de suppression de paquet ( , )
cur
d avg N pour estimer
le nombre de flux actifs et la taille instantane de la file (
cur
avg ). La premire fonction
SRED
P
est dfinie comme suit :
cur
max cur
max cur
0 si 0 avg / 6,
1
( ) si B/6 avg / 3,
4
si B/3 avg ,
SRED cur
B
P avg P B
P B
s <
= s <
s <
(2.5.3)
28
o B est la capacit du Buffer de la file et
max
P est la probabilit maximale de suppression.
Noter que
SRED
P a seulement trois niveaux possibles de suppression
max max
(0, / 4 et ) P P ,
et ne dpend pas du comportement pass de la longueur instantane de la file, comme le
montre la figure 4 ci-dessous.
Figure 4 : La fonction de suppression de SRED.
Les auteurs ont propos dans [54] deux versions de SRED:
- le Simple SRED, o la probabilit de suppression ( , )
cur
d avg N dpend seulement de la
taille instantane du buffer et de lestimation P (t) :
2
( , ) ( ) min 1, .
2
256
N
d avg N P avg
cur cur
SRED
| |
|
|
\ .
= (2.5.4)
- Le Full SRED, o la probabilit de suppression ( , )
cur
d avg N dpend aussi du paquet
caus dun "hit" ou non, est calcul comme suit :
2
( , ) ( ) min 1, (1 ( ) ).
2
256
N
d avg N P avg Hit t N
cur cur
SRED
| |
|
|
\ .
= + (2.5.5)
Lalgorithme de ce mcanisme est le suivant [60] :
Calculer ( ) P t en utilisant la formule (2.5.1) ;
Calculer ( )
SRED cur
P avg en utilisant la formule (2.5.3) ;
Calculer ( )
cur
d avg en utilisant la formule (2.5.4) pour le
Simple SRED ou (2.5.5) pour le Full SRED ;
29
Marquer ou supprimer le paquet avec la probabilit ( )
cur
d avg ;
o P(t) : reprsente linverse du nombre estim du flux actifs, et ( ) d avg
cur
est la probabilit
de suppression du paquet.
2.6- Random Exponential Marking (REM)
Le REM (Random Exponential Marking) est propos par Athuraliya et al. en 2001 [6].
Son ide majeure est de stabiliser les dbits autour de la capacit du lien, et de garder la
longueur de la file petite autour dune valeur cible prdtermine.
Le mcanisme dfinit une variable cot en charge de lutilisateur, qui peut tre
considr comme un modle pour les utilisateurs pour facturer l'utilisation d'un lien. En
priode de congestion, la variable cot devrait tre leve.
La variable cot not C(t) est dfinie comme une somme pondre de deux variables.
- V1=taux dentre dans la file - capacit du lien.
- V2=La longueur de la file - la longueur cible prdtermine.
Pour stabiliser le cot, la somme pondre doit tre gale zro, c'est--dire la
longueur de la file d'attente doit tre exactement gale la longueur cible prdtermine et le
taux dentre dans la file doit tre le mme que la capacit du lien. Toutefois, si la longueur de
la file d'attente cible est plus grande que zro, il est galement possible de se prvenir de
contrler le taux et de n'utiliser que la longueur de la file d'attente comme un facteur du
contrle de la congestion. REM spare la file d'attente pour mesurer la congestion
diffremment RED qui exige que la dure moyenne de la file d'attente augmenter en vue
de dterminer des congestions, mais REM gre le tout en gardant la mme file d'attente stable.
Ce dernier point est important, car la mesure de la congestion qui est inscrite dans la fonction
de probabilit de RED, et la longueur de la file d'attente, automatiquement grandissent
proportionnellement au trafic. Le calcul de la moyenne (filtrage des fluctuations court
terme) ne peut pas changer le fait qu'il n'est pas possible de stabiliser la file d'attente une
faible valeur tandis que le volume de trafic augmente de faon significative avec RED. C'est
diffrent avec REM, qui utilise seulement la longueur instantane de la file d'attente pour
mettre jour explicitement la variable cot, mais il n'est pas ncessaire de la maintenir une
valeur leve afin de dtecter une croissance importante du trafic.
30
La probabilit dliminer/marquer un paquet est alors calcule comme suit :
( )
1
C t
P o = o o est une constante ( 0) o > et C(t) est le cot au temps t. La probabilit de
suppression de REM augmente de faon exponentielle en comparaison RED qui augmente
dune faon linaire par morceau. Cela est ncessaire pour la probabilit de suppression de
bout-en-bout pour augmenter la somme des cots de tous les liens congestionns le long du
chemin, en REM, elle est en fait gal la baisse de la fonction de probabilit donne ci-
dessus, avec C(t) tant la somme de toutes les probabilits de baisse par lien, qui est
approximativement proportionnelle la somme des cots de chaque lien dans le chemin. Cela
signifie implicitement que REM transmet des cots pour les utilisateurs finaux par
l'intermdiaire de son paquet de baisse de probabilit, qui est un autre aspect intressant de ce
mcanisme.
REM a t conu pour augmenter lutilisation du lien dans le routeur et maintient la
longueur de la file petite. Cependant, REM ne fournit pas dquit adquate quelle sacrifie au
cot de plus haute utilisation. Dailleurs, sous une lourde congestion ou avec une grande
probabilit de suppression, REM souffre d'un long temps de rponse. De plus, quand la taille
du buffer est petite, la sensibilit de REM devient pire [60].
2.7- Double Slope RED (DSRED)
Le Double Slope RED (DSRED) a t propos par Zheng et Atiquzzaman en 2000
[67], son but damliorer le taux de perte et le dlai dattente dans le mcanisme RED. Il
utilise deux segments de fonction de suppression permettant de fournir beaucoup plus
doprations flexibles de suppression que celles du RED comme le montre la figure 5.
Figure 5
31
DSRED introduit les variables additionnelles suivantes :
-
l
K : le seuil de la langueur moyenne de la file pour commencer la suppression des paquets
du buffer.
-
h
K : le seuil de la langueur moyenne de la file pour changer la fonction de suppression.
-
m
K : le seuil de la langueur moyenne de la file pour changer la fonction de suppression.
- o : la pente de la fonction de suppression du premier segment entre
l
K et
m
K .
- | : la pente de la fonction de suppression du deuxime segment entre
m
K et
h
K .
- : mode de slection pour ajuster les pentes de la fonction de suppression.
DSRED utilise une des fonctions de suppression exprimes comme suit :
m
h
0 si ,
( ) si ,
1- + ( ) si K ,
1 si K ,
l
l l m
b
m h
avg K
avg K K avg K
P
avg K avg K
avg N
o
|
<
s <
=

s <
s <
o et sont les pentes des deux segments calculs comme suit :

2(1 )
,
h l
K K
o

=
2
,
h l
K K
| =
Le paramtre adapte le mode de fonctionnement de DSRED. Le taux de suppression

peut tre augment ou diminu en ajustant .
Lalgorithme de ce mcanisme est le suivant [60] :
Calculer la longueur moyenne de la file avg ;
Calculer la probabilit de suppression du paquet
b
P ;
Marquer ou supprimer le paquet avec la probabilit
b
P ;
2.8- RED with In and Out
Le mcanisme de RIO (RED with In and Out) [14] se base sur le calcul de la longueur
moyenne de la file dattente, mais, par rapport RED, il adopte le principe de diffrenciation
de services [61]. Plus prcisment, les paquets sont marqus In "in profile" ou Out "out of
profile" l'entre du rseau selon leur degr de priorit ; en cas de congestion les paquets Out
sont rejets en premier, puis les paquets In le sont leur tour ds lors que la congestion
s'amplifie.
32
A l'arrive d'un paquet, le routeur vrifie si ce paquet est IN ou bien OUT. Si le paquet
est IN, alors le routeur calcule la longueur moyenne de la file
in
avg correspondant aux paquets
IN. De mme, si le paquet est OUT, alors le routeur calcule la longueur moyenne de la file
total
avg correspondant l'ensemble des paquets entrants IN et OUT. La probabilit d'limination
d'un paquet IN dpend de
in
avg , et la probabilit d'limination d'un paquet OUT dpend de
total
avg [66].
La probabilit de suppression de RIO est prsent figure 6 :
Figure 6 : La probabilit de suppression de RIO
2.9- CHOKe
Rang Pan et Al. Ont dfinit une variante de RED appele CHOKe (CHOose and Keep
the responsitive flows, CHOose and Kill the unresponsitive flows) en 2000 [55], qui protge
les flux adaptatifs contre les flux non adaptatifs. Cest un algorithme qui ne ncessite pas des
informations sur ltat de chaque flux [17, 51].
CHOKe marque aussi deux seuils pour la taille moyenne de la file. Dans le cas o
avg (calcul comme dans RED) est infrieure
th
Min les paquets qui arrivent la file sont
accepts. Si avg est compris entre les deux seuils, chaque paquet arriv est compar un
paquet tir alatoirement dans la file dattente. Si les deux paquets appartiennent un mme
flux, alors ils sont tous les deux rejets avec une probabilit calcule de la mme faon que
dans RED. Sinon, le paquet tir est gard dans la file (dans la mme position avant dtre
candidat au rejet) et le paquet arriv est limin avec la mme probabilit. Quand
avg dpasse
th
Max , chaque paquet arriv est compar un paquet tir alatoirement de la file.
33
Si les deux paquets font parti dun mme flux, ils sont tous les deux limins, sinon seulement
le paquet arriv est rejet et le paquet tir est rest dans la position qui occupe avant dtre tir
dans la file. Dans cette dernire phase, on peut tirer m (>l) paquets de la file qui seront ensuite
compars un par un avec le paquet arriv. Les paquets appartenant au mme flux que celui du
paquet arriv sont tous limins [51].
Ce raisonnement a conduit l'algorithme suivant qui est excut chaque fois qu'un
paquet arrive:
- Si la longueur moyenne de la file d'attente (tel que calcul avec RED) est infrieure
th
Min , le paquet est admis, et l'algorithme se termine.
- Sinon, un paquet est choisi au hasard de la file d'attente par rapport aux nouveaux
arrivants. Si les paquets appartiennent au mme flux, ils sont tous les deux rejets.
- Sinon, l'algorithme procde comme RED: si la taille moyenne la file d'attente est
suprieure ou gale
th
Max , le paquet est abandonn, et sinon, il est supprim avec une
probabilit qui est calcule comme en RED.
Il existe un moyen pour rduire lagressivit des flux non adaptatifs qui traversent le
routeur et donc maintenir la taille moyenne de la file infrieure
th
Max . Il suffit dintroduire
plusieurs seuils en partageant lintervalle entre
th
Min et
th
Max en plusieurs rgions R1,
R2,RK et choisir la valeur m de la rgion atteinte par la taille moyenne de la file dattente.
Par exemple, m=2*i (i=l,, K), quand avg atteint la rgion Ri. La valeur de m augmente
avec loccupation moyenne de la file [17].
CHOKe est un algorithme qui assure un partage quitable de la bande passante entre
tous les flux adaptatifs (flux TCP) contre les flux non adaptatifs et agressifs (flux UDP). Avec
les flux agressifs et non adaptatifs les paquets subissent souvent des pertes multiples alors que
les flux adaptatifs subissent des pertes simple et alatoire similaires celles de RED [51].
Selon (Pan et al. 2000) [55], ils donnent au plus un sens de comparer le nouveau
paquet avec non seulement un, mais un certain nombre de paquets partir du buffer et de
supprimer tous ceux qui appartiennent au mme flux, ce qui impose une plus grave forme de
punition sur les flux qui ne rpondent pas, mais exige plus d'efforts de calcul.
34
2.10- Weighted Random Early Detection (WRED)
Une extension de RIO plus de deux niveaux est WRED (Weighted RED). Elle se
base notamment sur la politique de RED, mais rsout le problme de priorit en assurant le
DiffServ. WRED utilis pour diffrencier la probabilit d'limination des paquets dans une
file d'attente unique. A l'entre de la file dattente, seffectue une classification des paquets
permettant de dterminer la provenance des paquets (IntServ, DiffServ). Lorsque la taille
moyenne de la file dpasse un seuil, qui varie selon la classe, les paquets sont limins
conformment la probabilit d'limination de leur classe.
WRED est un algorithme dynamique de gestion des files d'attente qui est capable de
fournir plusieurs niveaux de prcdence de rejet et associer chacun de ces niveaux une
fonction de probabilit de rejet diffrente en fonction de la taille moyenne de la file, et, selon
le type du paquet, de la priorit de ce dernier. Ainsi, nous bnficions pleinement des
ressources inutilises du rseau.
WRED est une mme technique que RED, mais permet en plus de dterminer quel
trafic on jette grce au champ IP Prcdence pour dcider de llimination des paquets. On
vite ainsi la monopolisation des ressources par certaines classes de trafic. Le flux de trafic
moins prioritaire sadaptera au trafic de priorit plus leve.
Pour chaque paquet entrant, lalgorithme suivant est appliqu [61] :
1. Calcul de la taille moyenne de la file selon la formule :
1 1
_ 1 _ _
2 2
n n
avg old avg current queue size
| | | | | |
= +
| | |
\ . \ . \ .
o n est un facteur de poids, configurable par lutilisateur.
2. Si la taille moyenne calcule est infrieure au seuil autoris, le paquet est mis en file
dattente ;
3. Si la taille moyenne de la file est comprise entre le minimum et le maximum du seuil
autoris, le paquet est soit limin, soit mis en file (tout est fonction de la probabilit
dlimination).
4. Enfin, si la taille moyenne de la file est suprieure au seuil maximum, le paquet est
automatiquement limin.
La figure 7 prsente un scnario de WRED agissant sur trois niveaux de priorit [61] :
les paquets de faible prcdence se voient rapidement limins, ds que la moyenne de la
35
taille de la file atteint un niveau relativement bas ; la probabilit dlimination des paquets de
plus haute priorit est moindre, et seffectue au moment o la moyenne de la taille de la file
est plus importante.
Figure 7 : Principe de fonctionnement de WRED
2.11- Dynamic-RED (DRED)
Dynamic-RED (DRED) est un mcanisme qui vise galement la stabilisation de la
file d'attente des routeurs, par le maintien de la longueur moyenne de la file d'attente prs d'un
seuil fixe, il parvient offrir des performances prvisibles, tout en permettant la transition du
trafic sans supprimer les paquets intitules. Le DRED est dcrit dans (Aweya et al. 2001), il
suit une approche de contrle strictement thorique, Le choix de contrleur qui surveille la
file d'attente et la probabilit de suppression de paquet qui utilise une technique du contrle
intgrante travaillera toujours contre une erreur (celle de la mesure de la sortie du systme, au
quel est affect par des perturbations dans l'environnement, moins la rfrence d'entre) d'une
manire qui soit proportionnelle au temps intgral de l'erreur, de faon ce que l'tat stable
d'erreur devient nul. Le signal d'erreur qui est utilise pour piloter le contrleur est filtr avec
le processus EWMA, qui a le mme effet que le filtrage (en moyenne) de la longueur de la
file d'attente comme RED, ce qui permet DRED dajuster un libre court trafic.
DRED une grande varit de paramtres qui peuvent tre adapts, sur la base des
analyses et des simulations, des recommandations pour les valeurs par dfaut sont donnes
dans (Aweya et al. 2001).
2.12- Flow Random Early Drop (FRED)
Flow RED (FRED) est un mcanisme propos par Lin et Morris en 1997 [46]. Qui est
une autre amlioration de RED, qui permet de rsoudre le problme des flux non sensibles
36
acceptant toujours les flux qui ont moins d'un seuil minimal (
q
Min ) des paquets dans le buffer
tant que la taille moyenne de la file d'attente est plus petite que
th
Max . FRED ne concerne que
les flux qui ont plus de
q
Min paquets dans la file dattente. Ce type de contrle exige que le
mcanisme permettant de stocker des flux par tat que pour les flux qui ont des paquets dans
la file d'attente et non pas pour tous les flux qui ne traversent jamais le lien, et donc, la
mmoire ncessaire est limite par la longueur maximale de la file d'attente.
FRED introduit les paramtres
q
Min et
q
Max qui sont respectivement le nombre
minimal et maximal que peux un flux contenir dans la zone mmoire.
FRED ne prend pas en compte les vnements de dpart lors du calcul de la dure
moyenne de la file d'attente. C'est dire, quand un paquet arrive et la file d'attente est trs
longue, et aucun paquet arrive pour une longue priode, le calcul l'arrive du prochain
paquet sera bas sur l'ancienne dure moyenne de la file d'attente, qui conduisant un trop
haut rsultat.
2.13- Selective Fair Early Detection (SFED)
Le SFED (Selective Fair Early Detection) propos dans [40], cest un mcanisme qui
permet le contrle du taux bas sur la gestion de la file qui assure une allocation de la bande
passante juste parmi les flux en concurrence gale dans la prsence du trafic non adaptif.
SFED peut tre utilis pour diviser la bande passante par rapport des poids pr-assigns et
bien assortis pour lallocation de la bande passante pour agrger les flux exigs dans les
services diffrencis. Il maintient un jeton port dans un seau pour chaque flux (ou tous les
flux) comme le montre la figure ci-dessous.
Figure 8 : Architecture pour le contrle de taux en utilisant les seaux de jeton.
37
Toutes les fois qu'un paquet est en file dattente, les jetons sont enlevs en
correspondance aux seaux. La dcision mettre en file dattente ou supprimer un paquet de
tout flux dpend de l'occupation de son seau dans le temps.
SFED assure la prvention de la dtection et la notification de la congestion la
source adaptative. En envoyant un taux plus haut que la bande passante autorise, qui rsulte
en un bas seau doccupation et ainsi une plus grande probabilit de suppression qui indique
donc le dbut de la congestion l'entre. Cela permet au flux adaptatif d'atteindre un tat
stable ce qui prvient dune svre pnalisation. Cependant, les flux non-adaptatifs
continueront envoyer les donnes au mme taux et donc ne souffrent plus de pertes.
Le taux auquel les jetons sont enlevs du seau d'un flux est gal au taux des nouveaux
paquets de ce flux. Seulement le taux d'addition de jetons dans un seau dpend de sa part
autorise de la bande passante et pas sur le taux auquel les paquets de ce flux particulier ne
sont pas en file dattente. Dans ce chemin un seau symbolique sert comme un contrle sur la
bande passante consomme par un flux.
2.14- Balanced RED (BRED)
Balanced RED est a t propos par Anjum et Tassiulas en 1999 [4, 5]. Est une
extension de FRED avec le but daccomplir la bande passante pour les trafics TCP et UDP. Le
principe de BRED est la rgulation de la bande passante dun flux en restant en compatibilit
avec le flux actif. Cela est fait en supprimant prventivement les paquets afin que le trafic non
adaptatif noccupe plus de la bande passante des flux adaptatifs.
Pour ce but, BRED introduit cinq variables globales qui sont utilises pour contrler
la bande passante :
-
m
W : le nombre maximal de paquets que chaque flux est permis d'avoir dans le buffer.
-
i
l : le nombre minimal de paquets du flux i quil peut avoir dans le buffer avant que ses
paquets commencez tre supprims avec la probabilit pi, pour i = 1, 2.
-
i
p : probabilit de suppression de paquet du flux i quand
i
l est atteint pour ce flux.
Ces paramtres sont donns comme suit :
38
1 2
l l | = ,
2
2
B
l
N
.
=

,
2
10
N
p
N
.
.
=
+
et
2
1
10
p
p = .
o | est une constante (0 1) | < s et N
.
est une estimation du nombre du flux actifs de
lentre. Il est calcul comme suit :
(1 )
active
N N N e e
. .
+ ;
et
active
N est la mesure du nombre de flux qui ont au moins un paquet dans le buffer. Le
paramtre e est mis 0.02.
La dcision de supprimer ou daccepter un nouveau paquet est base principalement
sur
i
qlen et
i
gap lesquels donnent le pas de la fonction de suppression. La variable
i
gap
empche des suppressions multiples conscutives qui sont malfaisants aux flux adaptatifs. Les
trois seuils
1
l ,
2
l et
m
W divise lespace de
i
qlen en quatre rgions :
1
(0, ) l ,
1 2
( , ) l l ,
2
( , )
m
l W ,
( , )
m
W pour chaque longueur de la file.
- Si ( , )
i m
qlen W e alors le paquet est dfinitivement supprim.
- Si
2
( , )
i m
qlen l W e et
2 i
gap l > , alors le paquet est supprim avec la probabilit
2
p .
- Si
1 2
( , )
i
qlen l l e et
1 i
gap l > , alors le paquet est supprim avec la probabilit
1
p .
- Si
1
(0, )
i
qlen l e , alors le paquet est accept.
i
qlen et
i
gap sont augments si le paquet est accept.
i
qlen est diminu pour chaque
dpart d'un paquet qui appartient au flux i.
Bien que BRED peut minimiser les diffrences dans la bande passante obtenue pour
chaque flux, il a besoin de maintenir les tats du flux, quel est difficile mette en uvre qui
est proportionnel la taille du buffer de retour.
A chaque paquet arriv du flux i :
Si c'est le premier paquet du flux i (i est le premier flux) alors
i
qlen = 0 ;
39
i
gap = 0 ;
active
N =
active
N +1 ;
Fin Si
Si
i
qlen >
n
W ou le buffer est plein alors
Supprimer le paquet ;
Sinon Si
2 m i
W qlen l > > et
2 i
gap l > alors
Supprimer le paquet avec la probabilit
2
P ;
Sinon Si
2 1 i
l qlen l > > et
1 i
gap l > alors
Supprimer le paquet avec la probabilit
1
P ;
Sinon Si
1
i
qlen l s alors
Accepter le paquet ;
1
i i
qlen qlen = + ;
1
i i
gap gap = + ;
Fin Si
A chaque dpart du paquet du flux i :
1
i i
qlen qlen = ;
Si 0
i
qlen = alors
1
active active
N N = ;
0
i
gap = ;
Fin Si
Pour chaque paquet du flux i supprim:
0
i
gap = ;
2.15- Adaptive Virtual Queue (AVQ)
Adaptive Virtual Queue (AVQ) a t propos par Kunniyur et Srikant en 2004 [43].
Cest un mcanisme bas sur le dbit et la haute utilisation du lien et qui a une base thorique
plus solide que RED. Cest un schma dAQM qui dtecte la congestion selon le taux darriv
des paquets au lien.
AQV utilise une file virtuelle avec une capacit du service virtuelle qui est moins que
la capacit relle du lien. La capacit virtuelle chaque lien est modifie tel que le flux total
entrant chaque excution du lien qui dsire lutilisation du lien. Il utilise aussi comme une
entre au modle, des paramtres du systme comme le maximal Round Trip Time (RTT), le
nombre minimal des connexions actives N pour trouver le taux le plus rapide auquel la
probabilit du marquage est adapte et par consquent accomplir la stabilit du systme. Le
taux de l'adaptation qui est destin maintenir la stabilit du systme, dnot paro , est
calcul donc comme un taux dutilisation du lien dsirable.
40
Les variables utilises par le mcanisme AVQ sont:
- : utilisation du lien dsir ( 1) s .
- o : facteur utilis pour dterminer comment la probabilit de marquage est adapte au
lien au changement des conditions du rseau.
- C : la capacit du lien.
- C
:
: la capacit virtuelle du lien.
- B : la taille du buffer.
- B
:
: la taille virtuelle du buffer.
- : Le taux darriv au lien.
Lalgorithme de ce mcanisme est le suivant :
t le temps courant ;
b le nombre de bytes ;
/* la mise jour de la taille de la file virtuelle*/
VQ max (VQ- C
:
(t-s), 0) ;
Si VQ +b > B alors
Marquer ou supprimer un paquet de la file relle ;
Sinon /* la mise jour de la taille de la file virtuelle*/
VQVQ +b ;
Fin Si
/* la mise jour de la capacit virtuelle*/
C
:
max (min ( C
:
+o * *C(t-s), C) -o *b, 0) ;
/* la mise jour de la capacit virtuelle*/
s t ;
o VQ est le nombre de bytes courants dans la file virtuelle, et s le temps darriv du paquet
prcdent.
2.16- GREEN (Generalized Random Early Evasion Network)
Le GREEN (Generalized Random Early Evasion Network) a t propos par Feng et
al. [21, 41]. Il permet dappliquer la connaissance du comportement d'tat stable pour les
connexions TCP pour router ou supprimer (ou marquer) dune manire intelligente les
paquets pour la notification de la congestion. En utilisant un tel mcanisme, A chaque
connexion toute route prend sa part de la bande passante en prvenant l'augmentation des
paquets dans la file. Le dbit d'une connexion TCP dpend, parmi autre acteurs, sur son temps
41
daller-retour (RTT) et la probabilit de suppression de ses paquets dans le rseau. Le dbit
dune connexion est donn par la formule suivante :
MSS c
BW
RTT p
(1)
o MSS est la taille maximale du segment, RTT est le temps daller-retour, p est la
probabilit de la perte du paquet, et c est une constante qui dpend de la stratgie de la
reconnaissance qui est utilise (par exemple, diffr ou chaque paquet) comme si les paquets
sont assums dtre priodiquement perdu.
Ce modle peut ne pas tre applicable la mise en ouvre de non-SACK TCP. Pour les
plus courtes connexions, qui n'atteignent jamais un tat stable, ou les connexions dont la taille
de la fentre artificielle est limite par rapport la fentre du contrle de flux du receveur.
Si L est la capacit du lien et N est le nombre du flux TCP actifs qui partagent
quitablement le lien de la bande passante, alors la part de la bande passante d'un flux est
gale L/N et la probabilit de perte dun paquet est dduite de lquation (1) par la formule
suivante :
2
N MSS c
P
L RTT
| |
=
|
\ .
(2)
Une amlioration de GREEN est propose dans [41], en ajoutant un paramtre
additionnel ( ) t dans la formule (2) pour adapter la fonction de suppression du paquet au taux
dutilisation du lien et au nombre de paquets perdu pendant le dernier intervalle du temps.
Donc cette probabilit devient comme suit :
2
( )
N MSS c
P
t L RTT
| |
=
|

\ .
(3)
Le paramtre ( ) t est adapt comme suit :
Si le lien est 100% utilis alors : ( 1) 2 ( ) t t + =
Si les paquets sont perdus pendant le dernier intervalle du temps alors : ( 1) 0.95 ( ) t t + =
Si le taux dutilisation du lien est moins que 98% alors :
1
( 1) ( )
2
currentUtil
t t
currentUtil

+
+ =
42
Lalgorithme de ce mcanisme est donn comme suit :
( ) RTT obtainRTT paquet ;
2
( )
N MSS c
P
t L RTT
| |
=
|

\ .
;
Marquer ou supprimer le paquet avec la probabilit P.
Si ( () currentTime - lastUpdate > window ) alors
Mettre a jour les variables currentUtil , N et queueDrops ;
() lastUpdate currentTime ;
Si ( 0 queueDrops > ) alors 0.95 ;
Sinon Si ( 0.98 currentUtil < ) alors
1
2
currentUtil
currentUtil

+
;
Fin Si
Fin si
o window est la fentre de temps utilis pour estimer le nombre de flux et pour estimer
lutilisation courant du lien, currentUtil est lutilisation courant du lien, et queueDrops est le
nombre de suppression dans la file d au dbordement.
2.17- LRED (Loss Ratio based RED)
LRED (Loss Ratio based RED) cest un schma de gestion active des files dattente
rcemment propos par Wang et al. en [62]. Qui permet destimer le degr de congestion de
lien en se basant sur le taux de perte des paquets et la longueur de la file. Le taux de perte des
paquets est utilis dans la grande chelle du temps qui rend le schma plus adaptatif et
robuste, pendant que la longueur de la file est utilise dans la petite chelle du temps qui rend
le schma plus sensible en rglant la longueur une valeur attendu
0
q . Dans la grande chelle
du temps, la rgle de base est de garantir que la probabilit de suppression du paquet soit le
plus possible comme le taux de perte du paquet. Le dessin gouvern dans la petite chelle du
temps montre que :
1) Quand la longueur de la file est gale
0
q , la probabilit de suppression du paquet sera
gale au taux de perte du paquet.
43
2) Quand la longueur de la file est plus grande (ou plus petite) que
0
q , la probabilit de la
suppression du paquet sera aussi plus grande (ou plus petite) que le taux de perte du
paquet.
Le taux de perte des paquets cest un indice important qui dsigne la gestion du buffer
depuis :
Quun taux de perte du paquet croissant est une indication claire quune congestion svre
a lieu, et la suppression agressive des paquets est exige.
Quune baisse de taux de perte du paquet peut servir comme un signal que la congestion
s'loigne et par consquent l'action de suppression des paquets est moins agressive.
LRED mesure le taux de perte du paquet dans la grande chelle du temps, et met jour
la probabilit de suppression du paquet dans la petite chelle du temps chaque arrive du
paquet. La probabilit de suppression du paquet P est calcul chaque mp (une dure qui doit
tre moins que RTT) comme suit:
0
( ) ( )( ) P l k l k q q | = +
o ( ) l k est le taux de perte du paquet, q est la taille de la file et | est une constante
prconfigure ( 0 | > ).
Le taux de perte du paquet ( ) l k est calcul comme tant le rapport du nombre de
paquets supprims et le nombre total des paquets arrives pendant une longue priode M.
lestimation ( ) l k est obtenu alors comme un EWMA de ( ) l k comme le montre la figure 8:
( ) ( 1) (1 ) ( ) l k l k mw mw l k = +
Avec
1
0
1
0
( )
( )
( )
M
d
i
M
a
i
N k i
l k
N k i
o mw est le facteur du poids mesur auquel est mis une petite valeur pour obliger le taux de
perte courant,
d
N est le nombre des paquets supprims dans une priode k th et
a
N est le
nombre des paquets arrivs dans une priode k th .
44
Figure 9 : La mesure du taux de perte des paquets par LRED
Mise jour de ( ) l k chaque mp secondes :
Calculez
1
0
1
0
( )
( )
( )
M
d
i
M
a
i
N k i
l k
N k i
;
Calculez ( ) ( 1) (1 ) ( ) l k l k mw mw l k = + ;
Calculez la probabilit de suppression
0
( ) ( )( ) P l k l k q q | = + ;
Marquer ou supprimer le paquet avec la probabilit P ;
o ( ) l k est le taux de perte du paquet pendant une longue priode M.
2.18- Proportional Integral controller (PI controller)
Propos par Hollot et al. en [34]. Il est conu pour augmenter lutilisation du lien en
maintenant une petite taille de la file. En effet PI permet dutiliser la longueur de la file et le
taux de l'entre comme une mesure de la congestion pour accomplir la meilleure stabilit de la
taille instantane de la file en essayant de rgler la longueur de file une valeur attendue
0
q ,
en utilisant la disparit de la longueur de la file et son intgrale.
Chaque paquet qui arrive est supprim par la probabilit suivante :
0 0
( ) ( )
cur prev old
P a q q b q q P = +
45
o
cur
q est la taille instantane actuelle de la file,
prev
q est la taille instantane prcdente de
la file et
old
P est la probabilit du marquage/suppression prcdent. La probabilit de
suppression P est mise jour chaque intervalle du temps INTERVAL .
A chaque intervalle du temps INTERVAL :
Calculer la probabilit de suppression du paquet P ;
Marquer ou supprimer le paquet avec la probabilit P ;
3- Conclusion
Les mcanismes dcrits dans ce chapitre sont un petit sous-ensemble d'AQM
existants dans la littrature, on peut dire que les mcanismes prsents dans ce chapitre
sont parmi les plus populaires. La classification de ces mcanismes sur la base de leur
nature n'est pas facile. Certains d'entre eux s'appuyer sur RED, tandis que d'autres suivent
une approche totalement diffrente, et il ya une transition sans percussion d'une extrmit
l'autre. En outre, certains mcanismes basent leurs dcisions sur la longueur de la file
d'attente tandis que d'autres mesurent les taux de perte ou de l'arrive des paquets.
Chapitre 4 : Comparaison des mcanismes de gestion active des files dattente (AQM)
46
Chapitre 4 : Comparaison des mcanismes de gestion
active des files dattente (AQM)
47
1- Comparaison des performances de TD, RED et REM
La comparaison entre les mcanismes TD et RED, tait sujet de plusieurs travaux de
recherche, les rsultats de simulation obtenus dans [64] et [65] (Tableaux 1 et 2), montrent
que RED rduit de manire trs claire (presque la moiti) la taille moyenne de la file dattente,
de mme RED diminue le dlai dattente des paquets par rapport TD. Cependant RED
prsente un taux de perte lev en comparaison avec TD.
RED TD
Taille moyenne de la file 4.3 9.0
Dlai moyenne (ms) 4.5 8.7
Taux de perte 22% 20%
Tableau 1 : Comparaison de TD et RED [64].
Le tableau 2, qui prsente des rsultats des simulations effectues dans [64], montre
que RED et REM ralisent des taux de perte des paquets relativement proches mais qui restent
suprieurs celui dans TD. La longueur moyenne de la file dattente pour REM est
relativement infrieure celle de RED ; au moment o le dbit pour REM est infrieur celui
de RED et de TD.
AQM Taux de perte Dbit (Paquets/s) Taille moyenne de la file
Drop Tail 11.8% 1249.2 92.7
RED 13.1% 1245.8 42.1
REM 13.6% 1237.0 40.1
Tableau 2 : Comparaison entre TD, RED et REM [65].
Le mcanisme REM se distingue de tous les autres algorithmes prsents par le fait de
prendre en considration le cot de la congestion qui dpend du nombre de sources utilisant le
lien [6]. Par ailleurs, la probabilit de marquage/rejet dans REM augmente dune manire
exponentielle selon le niveau de congestion au moment o celle-ci augmente de manire
linaire (pour RED) ou linaire par morceau (pour GRED) (figure A5).
2- Comparaison des performances de RED, ARED et BLUE
Les figures A1, qui explicitent des rsultats de simulation ralise dans [18], montre
quavec le mcanisme RED, le dlai dattente des paquets est nettement plus lev que celui
avec ARED. Alors que le taux de paquets rejets avec RED est infrieur celui de ARED. Par
ailleurs les deux mcanismes assurent le mme dbit.
48
En se rfrant aux rsultats obtenus dans [11] et [22] (figures A2), on peut remarquer
que lorsque le nombre de connexions augmente, le mcanisme BLUE garde toujours un dbit
meilleur et relativement stable que celui de RED. Et avec ce dernier, le taux de perte de
paquets est nettement plus lev quavec le mcanisme BLUE.
En se basant sur les simulations faites dans [30] (figures A3 et A4), on peut remarquer
que ARED prsente une fluctuation plus importante par rapport BLUE au niveau de la
longueur moyenne de la file dattente. On peut aussi observer que BLUE maximise
lutilisation des ressources, et par consquence il maximise le dbit sortant (en vitant toute
sous utilisation de la file dattente). ARED offre un dbit assez constant et moins performant
par rapport BLUE. En contre partie, cela induit un trs grand dlai de bout en bout, ce qui
est nuisible pour les applications temps rel et multimdia.
Dans [2] (figures A19 et A20) on trouve des rsultats de simulations qui illustrent la
comparaison entre le RED et ARED au niveau dbit et dlai dattente en changeant les valeurs
des seuils maximal et minimal. La figure A19 dmontre que la courbe RED reste toujours
suprieure celle de ARED au niveau dlai dattente lorsque le dbit augmente (seuil
minimal fix a 5 et seuil maximal fix a 15 et 0.002
q
w = ). Dans la figure A20 on voit presque
le mme changement mais la courbe de RED reste toujours au dessus de celle de ARED.
Pour comparer RED, GRED et Adaptative RED au niveau longueur de la file en
fonction du temps on prend les rsultats de simulations de [12] (figures A21 et A22). Dans les
figures A21, la longueur de la file de RED reste ascendante stable pour les trafics de 150 flux,
seulement pour 200 flux cela atteint, le seuil maximal et devient instable. Concernant celle de
GRED elle est capable de grer un chargement ascendant pour 200 flux. Pour RED-ECN,
GRED-ECN et ARED-ECN on prend les figures A22 ; la longueur moyenne de la file est
instable pour le chargement de 150 flux pour RED-ECN de plus elle est trs bnfique pour
GRED-ECN pour 200 flux.
3- Comparaison des performances de TD, GREEN et FRED
Pour comparer les mcanismes TD, GREEN et FRED on prend les rsultats de
simulation de [21, 41] (figures A6, A7, A8). Les figures A6 montrent que lorsque le nombre
du flux augmente, GREEN est plus performant en termes dutilisation du lien par rapport
FRED. Par contre TD atteint la plus haute utilisation du lien parce que les flux occupent le
49
lien pendant des petits RTTs et aucun paquet na t supprim volontairement. Concernant la
perte des paquets on voit quil y a des petites fluctuations entre les trois mcanismes, mais il
nya pas de grande diffrence. Les figures A7 et la figure A8 permettent de comparer ces
AQM au niveau doccupation de la taille de la file. Nous observons que le TD permet
daugmenter dramatiquement la taille moyenne de la file lorsque le nombre des flux
augmente. Par contre on peut constater que GREEN et FRED gardent la taille moyenne de la
file basse. FRED garde la taille de la file basse par le marquage des paquets partir dun
certain seuil et limite loccupation de lespace du buffer pour chaque flux.
4- Comparaison des performances de RED, PI, AVQ et REM
La comparaison de RED et PI tait sujet des rsultats de simulations ralises dans
[34] (figures A9, A10). Dans les figures A9 (a) on observe que pour une petite valeur de
0
q
lutilisation du lien est presque totale le cas des flux FTP. Concernant le dlai dattente, il est
illustr dans la figure A9 (b) qui indique quil est presque une fonction linaire soit pour les
flux FTP ou HTTP. La figure A10 donne le dlai dattente en fonction de lutilisation du lien.
Pour comparer les mcanismes RED, AVQ, REM et PI on se base sur les simulations
faites dans [43, 44] (figures A11, A12, A13, A14, A15, A16, A17 et A18). La figure A11
donne le nombre des paquets perdus pour chaque lien en fonction du nombre de connexion
FTP pour les mcanismes RED, AVQ, REM et PI. Le mcanisme AVQ est meilleur en
comparaison avec les autres mcanismes arrive aprs PI ensuite RED et la fin on trouve
REM qui induit la perte la plus leve des paquets lorsque le nombre de connexion FTP
augmente. La figure A12 montre que REM et PI utilisent 100% du lien et la file est toujours
non vide, le mcanisme AVQ utilise 98 % du lien, de plus une faible utilisation du lien par
RED par rapport au autres AQM. La figure A13 illustre que le RED et AVQ gardent une
petite taille de la file en comparaison avec les mcanismes REM et PI qui maintiennent une
haute moyenne de la longueur de la file lorsque le nombre de connexion FTP augmente. La
figure A14 prouve que le mcanisme AVQ ne supprime pas plus de paquets par rapport aux
RED, REM et PI. La figure A15 montre que les mcanismes REM et PI ont la mme
utilisation du lien qui est plus haute, et une faible utilisation par le RED, par contre AVQ
prsente une meilleure utilisation du lien mais reste basse par rapport a REM et PI. Les
figures A16 et A17 montrent que le mcanisme AVQ maintient une petite longueur de la file
pour le nombre des court-flux par rapport aux autres mcanismes qui dpendent du paramtre
Gama, lorsque ce paramtre augmente la longueur de la file augmente. Dans la figure A18 on
50
observe que Les mcanismes REM et PI gardent un dbit plus important par rapport aux
autres mcanismes. Le dbit prsent par AVQ dpend du paramtre Gama, lorsque ce
paramtre augmente le dbit augmente.
5- Comparaison des performances de DT, RED, BLUE, REM et PI
Les simulations de [42] (figures A23, A24 et A25) comparent les mcanismes DT,
RED, BLUE, REM et PI au niveau utilisation du lien, dlai moyen dattente et le taux de perte
des paquets.
Un des problmes les plus importants que pose lutilisation des mcanismes AQM est,
les paramtres de configurations de ces mcanismes influencent sur lanalyse de performance
des algorithmes de gestion active des files dattente pour les rseaux IP.
Le tableau 3 donne la classification de certains AQM.
Critres Congestion Seuils Etat dinformation
Schmas Contrle Aviodance Non Globale Par-
connexion
Globale Par-
connexion
TD * * *
RED * * *
BLUE * * *
REM * * *
PI * * *
Tableau 3 : La classification de certains AQM
6- Comparaison des performances de CHOKe, FRED, RED et SFED
Les rsultats de simulations ralises dans [40] (figures A26, A27, A28 et A29)
illustrent le dbit en fonction du temps des mcanismes CHOKe, FRED, RED et SFED pour
les flux TCP et CBR. On observe que SFED est meilleur en terme dquit de dbit pour les
flux TCP et CBR. Dans la figure B27 FRED pnalise les flux TCP durant un certain intervalle
de simulation, et le partage du dbit devient quitable pour les flux CBR et TCP aprs.
7- Comparaison des performances de DT, RED, REM et AVQ
Dans [59] (Tableau 4) se trouve une comparaison entre les mcanismes DT, RED,
REM et AVQ au niveau taux de perte de paquets, dbit, et la taille moyenne de la file. AVQ
est moins performant par rapport RED et REM au niveau de perte des paquets, le DT est le
51
meilleur. Concernant le dbit, on observe que DT prsente un dbit plus important par rapport
aux autres mcanismes, le AVQ prsente le plus petit dbit. La taille moyenne de la file
dattente avec RED et REM est la moiti de celle de DT, par contre celle de AVQ est le par
rapport REM et RED.
AQM Taux de perte Dbit Taille moyenne de la file
Drop Tail 11.8% 1249.2 92.7
RED 13.1% 1245.8 42.1
REM 13.6% 1237.0 42.1
AVQ 14% 1218.0 10.5
Tableau 4 : Comparaison des performances entre certains AQM.
Chapitre 5 : Utilisation de certains mcanismes de gestion active des files d'attente pour le
routage dans les rseaux Ad hoc
52
Chapitre 5 : Utilisation de certains mcanismes de
gestion active des files d'attente pour le routage dans
les rseaux Ad hoc
53
1- Introduction
LAQM pourrait amliorer la qualit de service dans les rseaux mobiles de nouvelles
gnrations. A titre dexemple, on peut citer les performances du protocole MAODV
(Multicast Ad hoc On-Demand Distance Vector) [1] qui pourraient tre amliores par
lutilisation des AQM dans un rseau Ad hoc.
Avant de prsenter ces performances, dj tudies dans larticle [1] et soulever des
questions auxquelles il faut apporter des rponses, on va prsenter brivement les rseaux Ad
hoc.
2- Les rseaux Ad Hoc (Mobile Ad hoc Network)
MANET (Mobile Ad-hoc NETwork) est le groupe de travail de lIETF qui se
proccupe de la normalisation des protocoles Ad hoc fonctionnant sous IP. Ce groupe sest
appuy sur les protocoles classiques dInternet et les a perfectionns pour quils puissent
fonctionner avec des routeurs mobiles.
Un rseau sans fil Ad hoc (Mobile Ad hoc Network i.e MANet) est une collection de
nuds mobiles qui communiquent les uns avec les autres sans avoir recours une
infrastructure prexistante. Les nuds tant mobiles et communicant sans fil, ils peuvent
tout moment quitter ou joindre le rseau. De fait, mesure que les connexions entre les nuds
se crent et se dtruisent, la topologie du rseau peut rapidement tre modifie.
Par labsence dinfrastructures dans de tels rseaux, les nuds se comportent comme
des routeurs de manire transfrer les donnes dune source une destination. Ils utilisent
pour cela des protocoles de routage qui peuvent tre de diffrentes natures.
2.1- Les caractristiques des rseaux Ad hoc
Les rseaux mobiles Ad hoc sont caractriss par ce qui suit :
Une topologie dynamique : Les units mobiles du rseau, se dplacent dune faon libre et
arbitraire. Par consquent la topologie du rseau peut changer, des instants imprvisibles,
dune manire rapide et alatoire. Les liens de la topologie peuvent tre unis ou
bidirectionnels.
54
Une bande passante limite : Une des caractristiques primordiales des rseaux bass sur la
communication sans fil est lutilisation dun mdium de communication partag. Ce partage
fait que la bande passante rserve un hte soit modeste.
Des contraintes dnergie : Les htes mobiles sont aliments par des sources dnergie
autonomes comme les batteries ou les autres sources consommables. Le paramtre dnergie
doit tre pris en considration dans tout contrle fait par le systme.
Une scurit physique limite : Les rseaux mobiles Ad hoc sont plus touchs par le
paramtre de scurit, que les rseaux filaires classiques. Cela se justifie par les contraintes et
limitations physiques qui font que le contrle des donnes transfres doit tre minimis.
Labsence dinfrastructure : Les rseaux Ad hoc se distinguent des autres rseaux mobiles
par la proprit dabsence dinfrastructure prexistante et de tout genre dadministration
centralise. Les htes mobiles sont responsables dtablir et de maintenir la connectivit du
rseau dune manire continue.
Equivalence des nuds du rseau : Dans un rseau classique, il existe une distinction nette
entre les nuds terminaux (stations, htes) qui supportent les applications et les nuds
internes (routeurs par exemple) du rseau, en charge de lacheminement des donnes. Cette
diffrence nexiste pas dans les rseaux Ad hoc car tous les nuds peuvent tre amens
assurer des fonctions de routage.
Communication par lien radio : Les communications entre les nuds se font par
lutilisation dune interface radio. Il est alors important dadopter un protocole daccs au
mdium qui permet de bien distribuer les ressources radio et ceci en vitant le plus possible
les collisions et en rduisant les interfrences. Les technologies de communication sans fil
sont alors indispensables la mise en place dun rseau Ad hoc.
Rapidit de dploiement : Les rseaux Ad hoc peuvent tre facilement installs dans les
endroits difficiles cbler, ce qui limine une bonne part du travail et du cot gnralement
lis l'installation et rduit d'autant le temps ncessaire la mise en route.
2.2- Les protocoles de routage
Le routage est une mthode dacheminement des informations la bonne destination
travers un rseau de connexion donn. Le problme de routage consiste pour un rseau dont les
55
arcs, les nuds et les capacits sur les arcs sont fixs dterminer un acheminement optimal des
paquets travers le rseau au sens dun certain critre de performance. Le problme consiste
trouver linvestissement de moindre cot en capacits nominales et de rserves qui assure le
routage du trafic nominal et garantit sa surveillance en cas de nimporte quelle panne darc ou de
nud.
Les protocoles de routage jouent un rle important si deux htes souhaitent changer des
paquets et qui sont incapables de communiquer directement. Tous les nuds sont mobiles et
peuvent tre connects dynamiquement de manire arbitraire. Tous les nuds de ces rseaux se
comportent comme des routeurs prenant part de la dcouverte et de lentretient des routes
dautres nuds du rseau. Cette situation devient plus complexe lorsque plusieurs nuds sont
ajouts au rseau Ad hoc.
Un protocole de routage doit tre en mesure de dterminer le meilleur chemin entre les
nuds, de minimiser les frais de bande passante pour permettre le routage, de rduire le temps
ncessaire la convergence, aprs changement de la topologie du rseau.
Il existe trois grandes classes de protocoles de routage [19] : les proactifs, les ractifs
et les hybrides.
Protocoles proactifs : Les nuds utilisant un protocole de routage proactif
changent priodiquement des messages de contrle entre nuds voisins. Cette transmission
volontaire de l'information est qualifie de proactive.
Les nuds disposent, aprs un certain temps, d'une connaissance fiable de la topologie
du rseau. Sur la base de cette carte du rseau, des chemins entre des nuds sont dtermins.
Les chemins peuvent tre calculs selon plusieurs critres tels que le nombre de sauts,
le dlai, la bande passante.
L'inconvnient majeur de cette approche est son cot important pour maintenir jour
toutes les informations lies la topologie de chaque nud, mme si aucun message utile
n'est chang.
Les principaux protocoles de routage proactifs :
- Destination-Sequenced Distance Vector Protocol (DSDV)
- Optimized Link State Routing (OLSR)
56
- Fish-eye State Routing (FSR)
- Topology Broadcast Based on Reverse-Path Forwarding (TBRPF)
Protocoles ractifs : Les protocoles de routage ractifs ne gardent que les routes en
cours d'utilisation pour le routage. Aucun message de contrle n'est mis pour maintenir les
tables de routage jour. Uniquement la demande, le protocole engage une procdure de
dcouverte de route. Tous les protocoles bass sur cette approche sont qualifis de protocoles
ractifs.
Cette dcouverte de route consiste inonder le rseau par des messages de dcouverte
de route. En plus de cet inconvnient majeur, cette classe de protocoles est trs sensible aux
changements de topologie. Les mcanismes de maintenance de route sont lourds en termes de
gestion et de bande passante utilise pour faire transiter le trafic de contrle.
Quelques protocoles de routage ractifs proposs dans MANET :
- Dynamic Source Routing (DSR)
- Ad Hoc On-Demand Distance-Vector Protocol (AODV)
Protocoles hybrides : Les protocoles hybrides sont une combinaison des approches
proactives et ractives. En gnral, ils utilisent une approche proactive dans un voisinage
immdiat ou proche, voisinage de quelques sauts, puis une approche ractive au del du
voisinage proche. Cette combinaison permet une grande ractivit et rapidit des
communications locales sans perturber la globalit du rseau. Cette approche hybride est
intressante car elle cumule tous les avantages des approches proactives et ractives, qualits
apprciables pour un grand rseau, mais elle en cumule galement les inconvnients : envois
priodiques de messages de contrle et le cot d'une dcouverte de route.
Quelques exemples des protocoles hybrides :
- Zone Routing Protocol (ZRP)
- Temporally Ordered Routing Algorithm (TORA)
- System and Traffic dependent Adaptive Routing Algorithm (STARA)
57
2.3- Communication dans les rseaux Ad hoc
Un rseau est dit sans fil lorsque les machines qui le composent ne sont pas relies entre
elles par des cbles, mais utilisent, pour communiquer, le mdium radio ou infrarouge. Comme les
signaux propags sur ces media sattnuent au fur et mesure quils sloignent de leur metteur,
un nud ne peut pas communiquer avec un autre sil est situ trop loin de lui. On dfinit alors
lensemble des voisins dun nud comme tant lensemble des nuds capables de recevoir et de
comprendre les signaux mis par celui-ci.
Les conditions suivantes doivent tre remplies pour quun paquet puisse tre reu [16]:
- La puissance du signal reu doit dpasser un certain seuil (seuil de communication).
- Le rapport signal sur bruit ambiant doit tre suffisamment grand (le signal doit tre clairement
identifi, et non noy dans le bruit).
Il existe un seuil de dtection de porteuse. Si la puissance du signal est comprise entre ce
seuil et le seuil de communication, alors le message nest pas compris mais lactivit sur le canal
est nanmoins dtecte. Si le modle de propagation radio utilis est two-ray ground (ou le
modle free-space), ces seuils dfinissent donc deux zones autour dun nud. Si le rcepteur est
plac au centre de la figure 10, alors un metteur plac dans la zone interne (zone de
communication) pourra lui envoyer des messages qui seront compris (en labsence dautres
interfrences). Si lmetteur est plac dans la zone externe (zone de dtection de porteuse), la
communication ne sera pas possible mais lautre mobile sera inform chaque fois que lmetteur
accdera au canal. Si le modle de propagation radio utilis est shadowing, les deux zones sont
galement dfinies, mais leurs frontires sont floues du fait du caractre probabiliste du modle.
Figure 10 : Zones de communication et de dtection de porteuse
58
2.4- Gestion dnergie en mode Ad-hoc
Les rseaux sans fil peuvent possder des terminaux fixes ou mobiles. Le problme
principal des terminaux mobiles concerne leur batterie, qui na gnralement que peu
dautonomie. Pour augmenter le temps dactivit de ces terminaux mobiles, le standard prvoit un
mode dconomie dnergie.
Il existe deux modes [16]:
Continuous Aware Mode : La station est tout le temps allume et coute constamment le
support (fonctionnement par dfaut).
Power Save Polling Mode : Permet une conomie dnergie. Les stations qui sont en mode
normal stockeront les paquets pour les stations en mode conomie dnergie et vont jouer le
rle de tampon pour ces stations. Lorsquune station reoit une trame pour une station qui est
en mode conomie dnergie et que celle-ci nest pas active, il la stocke. La station qui la
stocke doit tre en mode normal pour remplir cette fonctionnalit. Elle met ensuite des
trames ATIM (Ad-Hoc Traffic Information Map) qui informent les stations en mode conomie
dnergie, quil y a des paquets en attente pour elles. Lorsque, la station en mode conomie
dnergie acquitte lATIM, la station qui a mis cette trame, lui fait suivre le paquet quelle a
pour elle.
3- Lvolution des performances du protocole MAOVD par
lutilisation de certains mcanismes de gestion active des files
dattente dans les rseaux Ad hoc
3.1- Description du protocole MAODV
MAODV (Multicast Ad hoc On-Demand Distance Vector) tend AODV pour offrir
des possibilits de multicast. Il est capable de faire lunicast, le broadcast et le multicast. La
dcouverte de la route se fait sur demande sous forme de question/rponse, et les informations
obtenues par la demande de route (RREQ) et la rponse de route (RREP) sont maintenues
dans la table de routage des nuds. Si un message est de type RREQ, alors seuls les nuds
membres du groupe multicast peuvent rpondre. Chaque groupe multicast est identifi par une
adresse unique. Dans lopration de multicast, un nud leader du groupe maintient les
numros de squence du groupe multicast ; il met priodiquement jour le numro de
squence et lenvoi travers le rseau en employant des messages hellos du groupe (GRPHs).
59
Ce leader du groupe est habituellement le premier nud qui rejoint le groupe. Si un nud
veut joindre un groupe multicast qui nexiste pas, alors ce dernier devient le leader de ce
groupe et est alors responsable de la maintenance du groupe [1].
3.2- Amlioration des performances de MAODV par la gestion active des
files dattente
Dans un rseau ayant une limitation dnergie comme les rseaux MANETs, la perte
de paquets entrane la perte dnergie pour retransmettre les paquets qui ont t
ventuellement limins. LAQM a montr ses preuves comme solution au problme de
synchronisation globale dans un contexte de rseaux cbls. Selon les auteurs de larticle [1] il
existe peu dtudes sur lAQM dans les MANETs, et aucune pour le multicast. Ils ont
modliss un rseau sous forme de files dattente en choisissant trois files qui sont:
- Priority Queuing (PriQ) utilise un processus de classification qui aiguille les paquets
provenant de diffrents flux vers diffrentes files selon leur priorit. Les files de haute priorit
sont servies ds que le nud reoit des paquets.
- Drop Tail (DT) est la technique classique pour grer les files dattente dans les rseaux
mobiles et cbls. Pour plus de dtaille sur cette file voir le chapitre 1.
- Deficit Round Robin (DRR) veut rsoudre le problme de lquit pos par la diffrence des
tailles des paquets. Dans DRR, les files sont servies dans lordre round robin et chaque file est
autorise envoyer un nombre dtermin doctets lors de chaque passage de lOrdonnanceur.
Le modle de simulation utilis dans [1] bas sur NS. Lenvironnement de simulation
est le suivant :
1) Surface: 1500m x 300m
2) Nombre de nuds: 50
3) Dure simulation: 910 secondes
4) Physical/Mac Layer: IEEE 802.11 2Mbps, transmission 250m
5) Modle de mobilit: modle random waypoint sans temps de pause, vitesse des nuds
gale 1m/s.
6) Chaque rcepteur est membre du groupe multicast, mais chaque metteur nest pas
forcment membre du groupe multicast (except le cas avec 50 rcepteurs o tous les nuds
sont membres du groupe).
60
7) Tous les rcepteurs rejoignent un groupe multicast unique au dbut de la simulation, et les
metteurs dbutent lmission des donnes 30 secondes plus tard. Aprs 900 secondes, tous
les metteurs arrtent la transmission des donnes.
8) Flux de type CBR (Constant Bit Rate): taille dun paquet = 256 bytes, intervalle = 0,5
secondes, nombre maximum de paquets mis = 1740.
9) Seul le trafic multicast existe dans la simulation.
10) Tous les modles ont 1 metteur 10, 20, 30, 40, 50 rcepteurs; 2 metteurs 10, 20, 30, 40,
50 rcepteurs; 3 metteurs 10, 20, 30, 40, 50 rcepteurs et 5 metteurs 10, 20, 30, 40, 50
rcepteurs.
A. Rsultats de simulation :
Les rsultats de simulations sont prsents ci-dessous.
A. Le taux de dlivrance de paquet
Figure 11 : PDR MAODV, 1 metteur,
vitesse 1m/s.
Figure 12 : PDR MAODV, 2
metteurs, vitesse 1m/s.
61
B. Latence
B. Rsum des rsultats :
Les rsultats obtenus aprs ces sries de simulations sont les suivants [1] :
A. Le taux de dlivrance de paquet
Quand on croit le nombre dmetteurs, les valeurs de PDR dcroissent, ceci est d
laugmentation du trafic sur le rseau entranant une perte de paquets mis.
Quand on croit le nombre de rcepteurs, les valeurs de PDR varient alatoirement.
Figure 15 : Latence MAODV, 1
metteur, vitesse 1m/s.
62
B. Latence
Quand on croit le nombre dmetteurs, les latences pour PriQ et DT sont proches, et ont une
valeur moyenne de 0,03 secondes.
Quand on croit le nombre de rcepteurs, la latence varie alatoirement.
C. Conclusion :
Daprs le travail est les rsultats de simulations faites dans [1] on peut conclure que
avec MAODV, les valeurs de PDR sont meilleures avec les files dattente Drop Tail dans tous
les exemples, alors mme que la latence moyenne est gale celle de Priority Queuing.
Deficit Round Robin aussi donne de meilleurs PDR, mais dans deux cas, sa latence est
suprieure celle de Priority Queuing. Entre un et cinq metteurs, le PDR de Priority Queuing
a chut de 9,9% contre 8,8% pour Drop Tail illustrant ainsi sa plus forte stabilit et 10,3%
pour Deficit Round Robin. Les simulations montrent que les performances du protocole
MAODV original, utilisant lalgorithme Priority Queuing, peuvent tre amliores par
lutilisation des AQMs, dans un rseau MANET.
Conclusion et perspectives
63
64
Dans ce travail, on sest intress ltude et la comparaison de certains mcanismes
de gestion active des files dattente dans les rseaux Internet, tels que RED, et ces variantes.
On sest intress aussi une tude critique de ces mcanismes.
On a prsente aussi lvaluation des performances du protocole MAODV par
lutilisation de certains mcanismes de gestion active de files dattente dans les rseaux Ad
hoc.
La comparaison sest base sur certains paramtres de performance tels que le dbit, la
perte des paquets, le dlai dattente et la taille moyenne de la file dattente.
Cette investigation nous a conduit a remarqu que chacun de mcanismes tudis
prsente des inconvnients et des avantages, tout dpend du paramtre de performance
valu.
Parmi ces remarques nous pouvons citer :
- Lorsque le mcanisme BLUE tente de maximiser le dbit, il fait accrotre, normment, le
dlai de bout en bout.
- Lorsque le mcanisme ARED tente de stabiliser la longueur de la file dattente, il fait
dcrotre le dbit dentre.
- Sensibilit des AQM en fonction des paramtres de lalgorithme.
- Le mcanisme REM prsente un avantage par rapport aux autres AQM, il permet de
calculer la probabilit de rejet sur le lien tout entier (la probabilit de rejet augmente dune
manire exponentielle).
- Quand la taille du buffer est petite, REM prsente une mauvaise sensibilit.
- Le mcanisme AVQ est bas sur le dbit et la haute utilisation du lien et a une base
thorique plus solide que RED. Il se base sur le taux darriv des paquets au lien pour
dtecter la congestion.
- Le mcanisme PI permet daugmenter lutilisation du lien en maintenant une petite taille
de la file.
- Le mcanisme RIO par rapport RED, adopte le principe de diffrenciation de services.
Comme perspectives, nous comptons tudier, travers des simulations, le choix des
meilleurs paramtres de performance de ces mcanismes.
65
Nous comptons aussi de simuler des rseaux Ad hoc dans lesquels circulent des trafics
qui ne sont pas de type CBR (Constant Bit Rate) afin de rguler la consommation de la bande
passante entre ces trafics et de permettre aux applications dtre adaptatives et changer leur
dbit en fonction de ltat du rseau. Ainsi de raliser des simulations qui permettent
dillustrer linfluence de laugmentation de la surface, du nombre de nuds ainsi que de la
vitesse moyenne des nuds sur ltat des rseaux Ad hoc. Et finalement dvaluer les
performances des rseaux Ad hoc o circulent diffrents types de trafics (unicast et multicast).
Annexe A : Rsultats de simulation
66
Annexe A: Rsultats de simulation
67
(a) RED (b) ARED
Figures A1 : Comparaison des performances de RED et ARED.
Figures A2 : Comparaison des performances de RED et BLUE.
(a) ARED (b) BLUE
Figures A3 : Longueur moyenne de la file dattente au niveau du routeur utilisant ARED,
BLUE.
68
Figure A4 : Dbit sortant du routeur utilisant ARED, BLUE.
Figure A5 : Probabilit de marquage pour GRED et REM.
69
Figures A6 : Utilisation du lien et la perte des paquets en fonction du nombre du flux
(a) Tail Drop (b) GREEN
Figures A7: Occupation de la taille de la file par TD et GREEN
Figure A8 : Occupation de la taille de la file par FRED
70
Figures A9 : Utilisation du lien et le dlai dattente pour le mcanisme PI.
Figure A10 : Dlai dattente en fonction de lutilisation du lien du mcanisme PI.
(a) Utilisation du lien (b) Dlai dattente
Figure A11 : La perte des paquets dans le lien
en fonction du nombre de connexion FTP pour
les mcanismes AVQ, RED, REM et PI.
Figure A12 : Lutilisation du lien
par les mcanismes AVQ, RED,
REM et PI.
71
Figure A13 : La longueur moyenne de la file dans le lien en fonction du nombre de
connexions FTP pour les mcanismes AVQ, RED, REM et PI.
Figure A14 : La perte des paquets dans le lien
pour les mcanismes AVQ, RED, REM et PI.
Packet losses at the link for various AQM
Figure A15 : Utilisation du lien par les
mcanismes AVQ, RED, REM et PI.
72
Figures A16 : La longueur de la file dattente dans le lien pour les mcanismes RED, REM,
AVQ et PI.
Figure A17 : Utilisation du lien pour
RED, REM, AVQ et PI.
Figure A18 : Le dbit total pour RED,
REM, AVQ et PI.
73
Figures A21 : La taille de la file : RED (gauche), GRED (centre) et ARED (droit)
Figures A22 : La taille de la file: REDECN (gauche), GREDECN (centre) et Adaptative
REDECN (droit)
Figure A19 : Le dbit en fonction de dlai
dattente pour RED, Adaptive RED.
Figure A20 : Le taux moyenne darriv en
fonction de la longueur moyenne de la file pour
RED et Adaptative RED.
74
Figure A23 : Lutilisation du lien pour les mcanismes DT, RED, REM, BLUE et PI.
Figure A24: Dlai moyenne pour les mcanismes DT, RED, REM, BLUE et PI.
Figure A25 : Le taux de perte pour les mcanismes DT, RED, REM, BLUE et PI.
75
Figure A26 : Le dbit en fonction du temps
pour lalgorithme CHOKe.
Figure A27: Le dbit en fonction du temps
pour lalgorithme FRED.
pour lalgorithme RED.
pour lalgorithme SFED.
Annexe B : Prsentation du simulateur NS-2
76
77
1- Introduction
NS est un logiciel qui permet de faire des simulations trs avances sur les diffrents
types de rseaux. Il est principalement bas sur la conception par objets, la rutilisabilit du
code et la modularit. Il devient aujourd'hui un standard de rfrence en ce domaine. C'est un
logiciel libre disponible sur ladresse suivante http://www.isi.edu/nsnam/. Son utilisation est
gratuite pour les travaux de recherche. Le logiciel est excutable tant sous Linux que sous
Windows. Il est bien adapt aux rseaux commutation de paquets et la ralisation de
simulations de petite taille. Il contient les fonctionnalits ncessaires l'tude des algorithmes
de routage, des protocoles de transport, de session, de rservation, des services intgrs, des
protocoles d'application comme HTTP. De plus le simulateur possde une palette de systmes
de transmission, d'ordonnanceurs et de politiques de gestion de files d'attente pour effectuer
des tudes de contrle de congestion. Ainsi, le NS a pris en charge les communications sans
fil (rseaux Ad hoc et rseaux mobile en gnrale). Depuis, et aprs les mises jours qua
connus NS (NS2.26, NS2.28, NS2.33etc.) plusieurs protocoles de routages ont vu le jour
dont : AODV, DSR, DSDV, TORA, OLSR, TBRPFetc.
Au dpart, NS a t dvelopp au Laboratoire National de Lawrence Berkeley (LBNL)
par le groupe de recherche rseau. Son dveloppement fait maintenant partie du projet VINT
(Virtual InterNetwork Testbed) qui a pour but la construction dun simulateur rseau offrant
des outils et des mthodes novatrices, dans un environnement proche de la ralit [20]. Ce
simulateur utilise un utilitaire NAM (Network Animator) qui rcupre les donnes textuelles
fournies en sortie et offre une visualisation graphique de la topologie et dautres utilitaires qui
permettent la conversion vers d'autres outils (comme par exemple xgraph pour dessiner des
courbes).
2- Organisation du simulateur NS-2
NS-2 est crit en C++ et en OTcl (Object Tool Command Language) et ces deux
langages sont troitement lis [20]. Quand lutilisateur cre un nouvel objet via linterprteur
OTcl (qui est la version objet de tcl), un objet correspondant est aussi cre dans la hirarchie
C++. Bien entendu, les objets peuvent tre manipuls aussi bien en OTcl quen C++, grce
la mise en place de procdures de liaison entre les deux langages. La partie code en C++ est
rapide excuter mais plus lente modifier et est utilise pour ce qui concerne le
fonctionnement interne des composants du rseau. Celle en OTcl est, quant elle, plus lente
78
lexcution quelle ne lest modifier, ce qui la rend optimale pour la configuration des
simulations. Lutilisation de NS-2 se fait en trois tapes comme le montre la figure B1 :
1. Lutilisateur crit un script OTcl pour dfinir la topologie du rseau, pour instancier les
diffrents modules du rseau, pour dcrire des scnarios du trafic.
2. NS-2 interprte le script et excute la simulation. Les rsultats sont stocks dans des
fichiers en fonction des commandes du simulateur utilises.
3. Une fois la simulation termine, les rsultats peuvent tre analyses directement avec
loutil de visualisation NAM ou avec des autres outils.
Figure B1 : Flot de simulation avec NS-2
3- Prsentation de Tcl
Tcl (Tool Command Language) a t developp en 1988 par John K. Ousterhout.
Cest un langage de scripts comme le shell UNIX mais qui sert contrler les applications. Il
offre des structures de programmation telles que les boucles, les procdures ou les notions de
variables. Il y a deux principales faons de se servir de Tcl: comme un langage autonome
interprt ou comme une interface applicative d'un programme classique crit en C ou C++.
En pratique, l'interprteur Tcl se prsente sous la forme d'une bibliothque de procdures C
qui peut tre facilement incorpore dans une application. Cette application peut alors utiliser
les fonctions standards du langage Tcl mais galement ajouter des commandes l'interprteur
[3].
La _n de ligne est le dlimiteur d'instructions. Les commentaires commencent par un #
et finissent la fin de ligne. Les variables ont toujours le type chane de caractres (ou liste de
chanes). La valeur de la variable de nom a est $a. Les variables sont toujours instancies
avant l'excution d'une instruction, mme l'intrieur d'une chane de caractres.
Le tableau suivant dcrit les principales instructions.
79
Commentaires les commentaires sont introduits par le caractre #
set a 10 affecter la chane de caractres 10 la variable a
set a "une chane de car" Autre affectation
set b $a affecter le contenu de la variable a la variable b
puts $b Imprimer le contenu de la variable b
puts "B vaut $b" Idem, mais l'intrieur d'une chane de caractres. B est value
set a(couleur) "red" les tableaux ont des indices qui sont des chanes de caractres
[fonc par1 par2] appeler la fonction fonc avec des paramtres
set obj [new Class1/Class2] Crer une instance d'un objet
[$obj meth par1 par2] invoquer la mthode meth de l'objet obj
$obj set field val Instancier une variable de l'objet obj
set a [$obj set field] Rcuprer la valeur d'une variable de l'objet obj
[expr $a + 6 * $b] valuer l'expression arithmtique
set f [open "File" w] ouvrir le fichier de nom File en criture, et mettre le descripteur dans f
puts $f "truc" crire une chane dans le fichier de descripteur f
exec xemacs & Excuter un processus systme (en arrire plan avec &)
if { $a = $b } { # code if }
else { # code else }
les structures de contrle sont : pour les tests
for { set i 0 } { $i < 10 } {
incr i} { # code de la boucle }
les structures de contrle sont : pour les boucles
proc fonc {par1 par2} {
global var1 var2 # code
return $quelquechose}
dfinition des fonctions. o l'instruction globale permet de faire
rfrence des variables globales du script tcl.
4- Prsentation de OTcl
OTcl (Object Tool Command Language), est la version objet de tcl. Les classes sont
galement des objets avec des possibilits d'hritage. Il est facilement possible dtablir une
analogie entre OTcl et le C++ comme le montre le tableau suivant :
C++ OTcl
Unique dclaration de classe Les mthodes sont attaches un objet ou
une classe
Mthodes appeles lobjet en prfixe
Constructeur/Destructeur init{}/destroy{}
L'identification de l'objet lui-mme this en
C++
$self en OTcl
Les mthodes sont tout le temps virtual
dtermination de la mthode appeler
effectue lexcution
80
Les mthodes non dfinies dans la classe
appeles explicitement avec loperateur de
porte ::
Appel de mthode de mme nom de classe
parant
Mthodes implicitement appeles dans
larbre dhritage par $self next
Lhritage multiple possible Lhritage multiple possible
Attributs
Mthodes
Void XTP : Send(Char* data)
Dclaration de variable dinstance : instvar
Dclaration mthode de classe : instproc
XTP : instproc Send {data}
5- Architecture du rseau
Larchitecture rseau de NS-2 est base sur le modle des couches OSI. NS2 est un
simulateur vnements discrets, chaque activit physique sur le rseau est traduite en un
vnement qui est mis en file dattente. A chaque vnement est attribu un instant de
traitement, permettant dordonnancer cette file. Un modle de rseau en NS-2 est constitu de:
5.1-Nuds de rseau
Endroit o est gnr le trafic, ou nuds de routage. Chaque nud (classe OTcl :
Node) est compos de Classifiers et dAgents. Les Classifiers dmultiplexent les flux des
paquets. Les Agents grent le protocole. Ils sont les producteurs et les consommateurs de
paquets. Lorsquun paquet arrive dans le nud, il est orient vers un des liens raccords au
nud en fonction de son adresse de destination.
Chaque nud possde une adresse (id_). Si ladresse est celle du nud, le paquet est
reu par lAgent dont le port correspond. Il ny a pas de dure modlise pour ces traitements
au niveau du nud. Les noms suivis du caractre _ correspondent des variables internes
de la classe Node. Entry_ pointe sur le premier Classifier lentre du nud. Cette entre est
utilise la fois par les paquets venant dun autre nud et par les Agents raccords au nud
comme le montre la figure B2.
81
Figure B2 : Composant dun nud unicast NS-2.
5.2- Liens de communication entre les rseaux
Qui servent raccorder les nuds entre eux. Les caractristiques principales dun lien
sont la bande passante et le dlai de propagation (gr par llment link_). Un lien contient
galement une file dattente (queue_) avec diffrentes politiques de gestion possible, un
lment pour grer les pertes de paquets (dropphead_) en fonction de ltat de la file dattente
et un lment pour grer la dure de vie des paquets (ttl_) figure B3.
Figure B3 : Composant dun lien NS-2
5.3- Agents de communication
Reprsentant les protocoles de niveau transport (TCP, UDP) ; ces agents sont attachs
aux nuds et connects l'un l'autre, ce qui reprsente un change de donnes (connexion
TCP, flux UDP).
82
5.4- Applications
Qui gnrent le trafic de donnes selon certaines lois, et se servent des agents de
transport.
6- Principe dutilisation
Pour terminer et illustrer bien cette prsentation du simulateur NS-2, nous allons
prsenter un exemple simple de modlisation dun rseau. Lobjectif est de montrer comment
partir dun script OTcl, il est possible de dfinir un rseau, de gnrer un trafic et de lancer
une simulation. travers ce langage, l'utilisateur dcrit les conditions de la simulation :
topologie du rseau, caractristiques des liens physiques telles que le dbit, le dlai, les
protocoles utiliss, communications...etc.
La simulation doit d'abord tre saisie sous forme de fichier texte que NS utilise pour
produire un fichier trace contenant les rsultats. Donc la premire des choses il faut que nous
programmions un fichier avec l'extension .tcl dont on mettra des instructions spciales pour
mettre en uvre notre simulation.
Notre premier programme consistera en deux nuds relis par un lien quon compilera
et on verra lanimation (figure B4), pour cela il faut suivre les tapes suivantes :
- Ouvrez un fichier texte et enregistrez le sous le nom "premier_exemple.tcl"
- La premire instruction mettre dedans c'est :
set ns [new Simulator]
- Par la suite nous mettrons deux instructions qui permettrons de crer un fichier .nam qui
servira pour un fichier d'animation :
set nf [open anim.nam w]
$ns namtrace-all $nf
Comme vous pouvez le constater notre fichier animation se nomme "anim.nam", la deuxime
ligne ordonne NS mettre toute la trace du notre programme dans notre fichier.
- Nous allons maintenant dclarer nos deux nuds n0 et n1 :
set n0 [$ns node]
set n1 [$ns node]
83
- Maintenant on cre le lien entre ces deux nuds avec une bande passante 1Mb et un dlai
de 10ms et une queue de type Droptail :
$ns duplex-link $n0 $n1 1Mb 10ms DropTail
- Chaque programme de simulation doit contenir une procdure de fin, dont voici la
structure pour notre petit programme qui ne fait rien :) (Juste deux nuds et un lien) :
proc finish {} {
global ns nf
$ns flush-trace
close $nf
exec nam anim.nam &
exit 0
}
Cette procdure va appeler notre fichier animation et l'ouvrir en fin de l'excution de notre
simulation.
- On va ajouter une instruction qui permettra d'appellerai la procdure fininsh aprs 6
secondes du lancement de la simulation :
$ns at 6.0 "finish"
- En fin on mettra l'instruction qui permettra NS d'excuter le programme de simulation :
$ns run
Figure B4: Capture dcran NAM
Bibliographie et Webographie
84
85
[1] P. Alberto de Barros et M. El Koutbi, Enhancing MAODV performance using Active
Queue Management, NGNS09, Rabat, Maroc, 4-6 juin 2009.
[2] F. AL-Raddady, M. Woodward, A new active congestion control mechanism for the
Internet, 2008. Online at: http://www.comp.brad.ac.uk/het-net/tutorials/WP06.pdf
[3] P. Anelli & E. Horlait, NS-2: Principes de conception et d'utilisation, UPMC - LIP6
: Laboratoire d'Informatique de Paris VI 8, Rue du Capitaine Scott 75015 paris France.
[4] F. Anjum and L. Tassiulas, Fair bandwidth sharing among adaptive and non-
adaptive flows in the Internet, In Proc. IEEE INFOCOM99, New York, NY, March
1999.
[5] F. M. Anjum and L. Tassiulas, Balenced-RED: An Algorithme to achieve Faireness in
the Internet, University of Maryland at College Park, March 8, 1999.
[6] S. Athuraliya, V. H. Li, S. H. Low, and Q. Yin, REM: Active Queue Management,
IEEE Network, May 2001.
[7] J. Aweya, M. Ouellette and D.Y. Montuno, A control theoretic approach to active
queue management, Computer Networks 36 (2001), pp. 203235, 2001.
[8] G. Benjamin, Traitement diffrenci et marquage adaptatif de paquets pour le
transport des flux htrognes dans l'Internet, These de doctorat, l'Universit Claude
Bernard -Lyon 1, pp.12-13, 18 dcembre 2003.
[9] C. Bernard, Les mcanismes de contrle de congestion dans ATM, Laboratoire
IRISA Universit de Rennes-1, Campus universitaire de Beaulieu 35042 RENNES.
[10] C. Brandauer, G. Iannaccone, C. Diot, T. Ziegler, M. May and S. Fdida, Comparison
of Tail Drop and Active Queue Management Performance forbulk-data and Web-
like Internet Traffic, in Proceedings of the Sixth IEEE Symposium on Computers and
Communications, IEEE ISCC 2001.
[11] P.K Chong, S.W. Tan and S.W. Lee, A Performance Comparison of BLUE and
RED AQM using ECN and non-ECN Traffic, Conference Paper, MMU, 2002.
86
[12] J. Chung and M. Claypool, "Analysis of active queue management," In Proceedings
of the 2nd IEEE International Symposium on Network Computing and Applications
(NCA), Cambridge, Massachusetts, USA, April 2003. Online at:
http://www.cs.wpi.edu/~claypool/papers/queue-law/
[13] J. Chung and M. Claypool, Aggregate Rate Control for Efficient and Practical
Congestion Management, Online at: ftp://ftp.cs.wpi.edu/pub/techreports/pdf/04-03.pdf
[14] D. Clarkand W. Fang, Explicit allocation of best-effort packet delivery service,
IEEE/ACM Transactions on Networking, 6(4):362373, August 1998.
[15] A. Dada et A. Bennia, Algorithme de contrle ractif de la congestion sur un
nud ATM, RIST Vol.14 n02 Anne 2004.
[16] M. Dawoud, Analyse du protocole AODV, DEA d'Informatique, Universit
libanaise, Facult des sciences, N
o
d'ordre: 6/2006, Universit Paul Sabatier I.R.I.T,
2005/2006.
[17] D. El Ouadghiri et K. El Yassini, Les mcanismes de gestion active des files
dattente: RED et ses variantes, 1
er
Workshop International sur lInformatique Mobile
et Applications, Htel Kenzi Farah, Marrakech, Maroc, Lundi 4 juin 2007.
[18] L. Emmanuel and T. Bruno, Managing network congestion with a Kohonen-based
RED queue, IEEE, International Conference on Communications, Beijing, China, 19- 23
May 2008.
[19] M. Erwan ERMEL, Localisation et Routage gographique dans les rseaux sans
fil htrognes, Thse de Doctorat, Universit Paris VI Pierre et Marie CURIE, 21 Juin
2004.
[20] K. Fall and K. Varadhan, The ns Manual (formerly ns Notes and
Documentation), The VINT ProjectA Collaboration between researchers at UC
Berkeley, LBL, USC/ISI, and Xerox PARC, January 6, 2009.
[21] W.-C. Feng, A. Kapadia, and S. Thulasidasan, GREEN: proactive queue
management over a best-effort network, In Proc. IEEE GLOBECOM02, Taipei,
Taiwan, November 2002.
87
[22] W.C. Feng, D.D. Kandlur, D. Saha and K.G. Shin BLUE: A New Class of Active
Queue Management Algorithms, Technical Report CSE-TR-387-99, Department of
EECS, University of Michigan, April 1999.
[23] S. Floyd and K. Fall, Ns Simulator Tests for Random Early Detection (RED)
Queue Management , Online at: http://www.aciri.org/floyd/red.html
[24] S. Floyd and V. Jacobson, "Random Early Detection Gateways for Congestion
Avoidance," ACM/IEEE Transaction on Networking, Vol. 1, pp 397-413, August 1993.
[25] S. Floyd, Recommendations on using the gentle variant of RED, March, 2000.
[Online]. Available: http://www.aciri.org/floyd/red/gentle.html
[26] S. Floyd, R. Gummadi, and S. Shenker, Adaptive RED: An algorithm for
increasing the robustness of REDs Active Queue Management, technical report,
international computer science institute, August 1, 2001. [Online]. Available:
http://www.icir.org/floyd/red/gentle.html.
[27] V. V. Govindaswamy, G. Zruba and G. Balasekaran, Receiver-Window Modified
Random Early Detection (RED-RWM) Active Queue Management Scheme:
Modeling and Analysis, in the IEEE ICC 2006 proceedings.
[28] U-K. Guillaume, De la qualit de service lanalyse de trafic, Thse
dhabilitation diriger des recherches, 11 dcembre 2006.
[29] L. Guy et K. Ludovic, Spcification formelle des mcanismes de support des
qualits de service dans l'Internet, Dans louvrage de CAVALLI Ana: Ingnierie des
protocoles et qualit de service, chapitre 3. Ed. Lavoisier 2000.
[30] Y. Hadjadj Aoul, A. Mehaoua, Gestion active des files dattente pour les flux
sensibles aux dlais dans le rseau Internet, In Proc. of GRES 2005, The International
Congress on Networks Management, Luchon, France, February 28th, 2005.
[31] A. Haider, H. Sirisena, K. Pawlikowski, & M.J. Ferguson, Congestion Control
Algorithms in High Speed Telecommunication Networks, Thanks to PA Consulting
Group, Charles River Associates, and Jade Corp. for supporting Conference, November
30, 2001.
88
[32] Go Hasegawa, and Masayuki Murata, Analysis of dynamic behaviors of many
TCP connections sharing Tail-Drop/RED routers, IEEE GLOBECOM 2001,
November 2001.
[33] S. HOCEINI, Techniques dApprentissage par Renforcement pour le Routage
Adaptatif dans les Rseaux de Tlcommunication Trafic Irrgulier, Thse de
doctorat, Universit Paris Xii Val De Marne, 23 Novembre 2004.
[34] C. Hollot, V. Misra, D. Towsley, and W. Gong, Analysis and design of controllers
for AQM routers supporting TCP flows, IEEE Transactions on Automatic Control,
47(6):945959, June 2002.
[35] C.V. Hollot, V. Misra, D. Towlsey, and W. Gong, A control theoretic analysis of
RED, in Proceedings of INFOCOM, Alaska, Anchorage, April 2001.
[36] T. Hutschenreuther and A. Schill, Content based discarding in IP router, In Proc.
IC3N00, pages 122126, Las Vegas, Nevada, October 2000.
[37] K. II-Won, Les tic pour lentreprise communicante: contribution a la
modlisation de linfrastructure de communication et gestion de la qualit de
service," Thse de doctorat, lInstitut National des Sciences Appliques de Lyon, pp. 63-
73, 94-108, 17 octobre 2002.
[38] V. Jacobson, K. Nichols and K. Poduri, RED in a Different Light, Draft of
September 30, 1999.
[39] R. Julien, Modlisation mathmatique et simulation de TCP par des mthodes
de champ moyen, These de doctorat, Ecole Doctorale de l'Ecole Polytechnique -
Palaiseau, INRIA, 15 septembre 2006.
[40] A. Kamra, S. Kapila, V. Khurana, V. Yadav, R. Shorey, H. Saran and S. Juneja.,
SFED: A Rate Control Based Active Queue Management Discipline, IBM India
research laboratory Research Report ,available online from :
http://www.cse.iitd.ernet.in/srajeev/publications.htm
89
[41] A. Kapadia, W.-C. Feng, and R. Campbell, GREEN: a TCP equation-based
approach to active queue management, Technical report, University of Illinois,
February 2004.
[42] J. Koo, S. Ahn, and J. Chung, Performance Analysis of Active Queue
Management Schemes for IP Network, ICCS 2004, LNCS 3036, pp. 349356, 2004.
Springer-Verlag Berlin Heidelberg 2004.
[43] S. Kunniyur and R. Srikant, An adaptive virtual queue (AVQ) algorithm for
active queue management, IEEE Transactions on Networking, pages 286299, April
2004.
[44] S. Kunniyur and R. Srikant, Analysis and design of an adaptive virtual queue
(AVQ) algorithm for active queue management, in Proceedings of SIGCOMM, San
Diego, CA, August 2001.
[45] L. Le, J. Aikat, K. Jeffay and F. D. Smith, The Effects of Active Queue
Management and Explicit Congestion Notification on Web Performance, In proc.
IEEE/ACM Transactions on Networking, 2005.
[46] D. Lin and R. Morris, Dynamics of Random Early Detection, Computer
Communication Review, Proceedings of ACM SIGCOMM 1997, vol.27 No.4, pp. 127-
137, 1997.
[47] C.N. Long, B. Zhao, X.P. Guan, SAVQ: stabilized Adaptive Virtual Queue
Management Algorithm, IEEE Communications Letters, VOL. 9, NO. 1, January 2005.
[48] R. Mahajan and S. Floyd, Controlling High-Bandwidth Flows at the Congested
Router, IEEE Computer Society Washington, DC, USA, November 20, 2000.
[49] M. Martin, Evaluation quantitative des nouveaux mcanismes de gestion de la
qualit de service dans Internet, Thse de doctorat, Universit de Nice-Sophia
Antipolis, pp. 106-115, 8 octobre 1999.
[50] M. May, T. Bonald and J. Bolot, Analytical evaluation of RED performance, in
IEEE INFOCOM, 2000, Vol. 3 pp. 1415-1424.
90
[51] W. Michael, Network Congestion Control Managing Internet Traffic, John
Wiley & Sons, Ltd, pp. 129-138, 2005.
[52] S. Mikovi, G. Petrovi, and L. Trajkovi, Implementation and Performance
Analysis of Active Queue Management Mechanisms, in: Telecommunications in
Modern Satellite, Cable and Broadcasting Services, 2005. 7th International Conference
on, IEEE.
[53] V. Misra, W. Gong, and D. Towlsey, A fluid-based analysis of a network of AQM
routers supporting TCP flows with an application to RED, in Proceedings of
SIGCOMM, Stockholm, Sweden, September 2000.
[54] T.J. Ott, T.V. Lakshman and L. Wong, SRED: Stabilized RED, Proceedings of
IEEE INFOCOM 1999, pp. 1346-1355, March 1999.
[55] R. Pan, B. Prabhakar and K. Psounis, CHOKe: A stateless active queue
management scheme for approximating fair bandwidth allocation, IEEE INFOCOM
2000.
[56] Q. X. Pang, S. C. Liew, W. Wang, and V. O.K. Li, Performance Study of TCP
Veno over WLAN and RED Router, IEEE Globecom 2003, Dec 2003.
[57] J. Prabhu Balakrishna, Markov chains and decision processes for congestion
avoidance and power control, These de doctorat, Universit de Nice- Sophia Antipolis,
INRIA, pp. 93-110, 4 octobre 2004.
[58] S. Ryu, C. Rump and C. Qiao, Advances in internet congestion control, In proc.
IEEE Communications Surveys & Tutorials Third Quarter 2003.
[59] G. Thiruchelvi and J. Raja, A Survey On Active Queue Management
Mechanisms, IJCSNS International Journal of Computer Science and Network Security,
VOL.8 No.12, December 2008.
[60] A. Tigist, Evaluation des Performances des Mcanismes de Qualit de Service
dans lInternet, Thse de doctorat, Universit de Montpellier II, 13 dcembre 2004.
91
[61] L. Toumi, Algorithmes et mcanismes pour la qualit de service dans des rseaux
htrognes, Thse de doctorat, Institut National Polytechnique de Grenoble, pp.72-75,
20 dcembre 2002.
[62] C. G. Wang, B. Li, T. Y. Hou, K. Sohraby, and Y. Lin, LRED: a robust active
queue management scheme based on packet loss ratio, In Proc. INFOCOM04,
March 2004.
[63] B.P.Wydrowski, Techniques in Internet Congestion Control, Thse de doctorat,
Electrical and Electronic Engineering Department the University of Melbourne, February
2003.
[64] D. Xidong, Network queue management and congestion control in internet and
wireless networks, These de doctorat, The Pennsylvania State University the Graduate
School College of Engineering, August 2004.
[65] S. Ye-Qiong, Garantir la Qualit de Service Temps Rel: Ordonnancement et
Gestion de Files dAttente, ERT, 7 septembre 2007.
[66] T. Zahratahdi, Algorithmes pour la diffrenciation proportionnelle de dlai dans
Internet, Thse de doctorat, Universit Mohammed V Agdal, pp. 71-75, Rabat,
Maroc, 1
er
novembre 2008.
[67] B. Zheng and M. Atiquzzaman, DSRED: an active queue management scheme for
next generation networks, In Proc. LCN00, pages 242251, Tampa, Florida,
November 2000. Mentioned on page(s) 35, 52.

Pfe-Said El Kafhali

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Pfe-Said El Kafhali

Enviado por

Direitos autorais:

Formatos disponíveis

Universit Hassan 1

Figure 3 : volution de la probabilit de perte de GRED en fonction de la taille moyenne de la

o et sont les pentes des deux segments calculs comme suit :

Le paramtre adapte le mode de fonctionnement de DSRED. Le taux de suppression

Você também pode gostar