Analyse de Performance des Protocoles de Contrôle de Congestion

SETIT 2009
5th International Conference: Sciences of Electronic,
Technologies of Information and Telecommunications
March 22-26, 2009 – TUNISIA
Analyse de Performance des Protocoles de Contrôle de
Congestion pour les Centres de Données Sous
Ethernet
Héla MLIKI*, Lamia CHAARI * et Lotfi KAMOUN*
Laboratoire d’Electronique et de Technologie de L’Information (L.E.T.I)
Ecole National d’Ingénieur de Sfax, 3038 Sfax TUNISIE
[email protected]
[email protected]
[email protected]
Résumé: Les évolutions récentes des applications réseaux ont imposé de nouvelles contraintes sur les commutateurs
Métro-Ethernet ; d’abord en raison d’un nombre plus élevées de stations à interconnecter, et ensuite en raison des
exigences de services et de performances. Ces contraintes ont contribué à mettre en évidence des limites des réseaux
Ethernet commutés relatives au contrôle. C’est pourquoi récemment, de nombreux travaux ont été consacrés au
contrôle de congestion au niveau des commutateurs Métro-Ethernet et divers algorithmes ont été proposés. Ces
algorithmes diffèrent principalement par le trafic supplémentaire générer ainsi que le temps de réaction vis-à-vis du
gradient du trafic. Nous proposons dans cet article une étude des mécanismes de contrôle de congestion de type BNC
(Backward Notification Congestion Management) pour Ethernet métropolitain. Les principaux mécanismes de contrôle
de congestion doivent être conformes aux spécifications définies par le standard IEEE 802.1Qau. Dans notre analyse
Nous intéressons particulièrement aux deux techniques ECM (Ethernet Congestion Manager) et QCN (Quantification
Congestion Notification). Nous étudions le mécanisme de chacun de ces deux protocoles et les algorithmes qu’ils
mettent en œuvre ainsi que les principales contraintes qui ont guidé leur conception concernent la complexité, le
contrôle et les performances.
Mots clés: ECM, Métro-Ethernet, QCN, Congestion , Analyse de performance, OMNeT++.
protocoles et procédures qui supportent la gestion de
congestion. Il est réalisé pour les flux à long vie de
données dans un domaine réseau de bande passante
limité.
INTRODUCTION
Les réseaux Ethernet possèdent de nombreuses
caractéristiques qui ont contribué à leur succès actuel.
S’agissant des fonctionnalités, la transparence et
l’auto-configuration facilitent le déploiement et la
maintenance, et améliorent l’´evolutivit´e des réseaux
Ethernet. Ses évolutions récentes démontrent que
Ethernet est une technologie qui s’adapte `a des
environnements aux contraintes diverses. Mais pour
cela, il est parfois nécessaire d’y implémenter de
nouvelles techniques visant à combler les faiblesses
héritées de sa conception initiale.
Ceci est réalisé en permettant aux nœuds du cœur
de réseau de signaler une information de congestion
aux stations de bords, afin de limiter leur débit pour
éviter la perte des trames. Ce mécanisme permet de
supporter les protocoles de couche supérieure qui ont
un taux élevés de perte ou bien qui sont sensible à la
latence.
Ce standard permet donc d’améliorer la
performance du réseau Ethernet métropolitain et
d’éviter la perte des trames et de réduire la latence
[NAT 07].
L'IEEE 802.1Qau a travaillé sur les mécanismes de
contrôle de congestion pour Ethernet depuis l’année
(2007). L'étendue de l'activité de la gestion de
congestion à l'IEEE 802.1 est limitée aux centres de
données qui génèrent un flot de données important à
l’issu duquel la probabilité de l’occurrence d’une
congestion est importante. Ce standard spécifie les
Les composants de base d’une architecture qui
intègre un système de contrôle de congestion sont le
point de congestion, le point de réaction et le point de
réflexion. Cette architecture est illustrée par la figure1.
-1-
SETIT2009
•Point de congestion: c’est l'entité qui exécute
l'algorithme de la détection de congestion et propage
cette information aux autres entités. Elle est
implémentée au niveau du commutateur.
-Le point de la réflexion réside à la destination, on
parle alors d’un contrôle de congestion de type FNC
(Forward Notification congestion management). On
considère alors le chemin de bout en bout. Toutefois,
on aura un plus long délai de la réaction (2xRTT) a
•Point de réaction : c’est l'entité qu'agit suite au
message de l'indication de congestion (congestion
indication message) et ajuste le débit (augmentation
ou réduction). Elle est habituellement implémenter au
niveau de la source et pourrait résider aussi au
commutateur d’extrémité.
comparé à notification de type BNC.
Dans le présent article, nous étions amenés à
mettre l’accent sur les techniques de contrôle de
congestion de type BCN (Backward Notification
congestion management). La section 2 sera consacrée
à l’étude et l’analyse du fonctionnement
du
mécanisme de contrôle de congestion ECM.
La
section 3 traitera le mécanisme QCN. La section 4
réservée pour l’analyse de performance ainsi que
l’interprétation des résultats. La dernière section est
consacrée pour conclure cet article suggérer certaines
perspectives à ce travail.
Point de réflexion : c’est l'entité qui reflète
l'information de contrôle de congestion au point de la
réaction.
1. ECM : Ethernet Congestion Manager
Connu aussi comme BCN Backward Congestion
Notification. ECM est un mécanisme de gestion de
congestion de la couche deux. Son principe consiste
à pousser la congestion du centre du réseau vers les
bords, utilise des limiteurs de débit au bord du réseau
pour reformuler les flux qui cause la congestion et
contrôler le débit en se basant sur la rétroaction venant
des points de congestion [JIA 06].
Figure 1 : Composants de contrôle de congestion.
1.1. Détection
Selon l'emplacement du point de la réflexion, deux
variétés du contrôle de congestion peuvent être
définies :
Pour détecter une congestion, il faut contrôler
l’utilisation de la file d’attente à un point de
congestion possible comme le commutateur du réseau
cœur. Ainsi il faut vérifier que les seuils de la file ne
sont pas dépassés [DAV 07] [NIC 03].
-Le point de la réflexion réside au point de
congestion (commutateur), on parle alors d’un
contrôle de congestion de type BNC (Backward
Notification congestion management). Son avantage
est un délai faible de la réaction. Cependant, il ne tient
pas du chemin de bout en bout, il est alors risqué pour
l’augmentation du débit.
La spécification des différents seuils de la file est
illustrée à la figure 2.
Figure 2 : File d'attente au niveau du commutateur du réseau cœur
-2-
SETIT2009
Handle_bcn_frame( rate_lim, bcn_frame)
{
Fb= calc_feedback(bcn_frame);
If (Fb < 0)
{
rate_lim R= rate_lim R* (1- min (Gd*Fb, alpha | );
rate_lim CPID= bcn_frameCPID;
}
Else
{
if (bcn_frame.CPID = = rate_lim CPID)
{
rate_lim R= rate_lim R+ min
(Gi*Fb, beta | );
}
}
}
La signification des différents seuils ainsi que les
indicateurs d’états de la file d’attente du commutateur
du réseau cœur est donné par le tableau 1.
Tableau 1 : Paramètres de la file d'attente.
PARAMÈTRES
ETAT
QLEN=Longueur
courante de la file.
QOLD=Longueur
de la file à un
échantillon
précédent.
CONFIGURATION
QEQ=Seuil d’équilibre
QMC=Seuil moyen de
congestion
QSEC=Seuil sévère de
congestion : ECM(0,0)
Si le feedback est négative (Fb<0) alors il y aura
une diminution de débit sinon on augmente le débit
1.2. Signalisation
La signalisation est définie par un message envoyé
du point de la congestion vers les stations de bord
émettrices de flux. Ce message ECM contient les
statuts et les variations de la file [DAV 07].
[GUE 07a]
Pour une congestion sévère on prend la réaction
suivante :
Le débit courant est mis à 0 et une horloge
aléatoire T est déclenchée tel que T∈[0,Tmax]; a
l’expiration de cette horloge le débit prend une valeur
minimale
Le principe de la signalisation par le feedback
positive et négative est illustré à la figure 3.
R
Rmin. Pour les prochains feedback négative
on aura des diminutions exponentielles pour le temps
de l’horloge maximale et le débit minimum :
Tmax
Tmax*2 et Rmin
Rmin/2. Pour le
prochain feedback positive Tmax et Rmin sont remis
aux valeurs initiales.
Il est à noter qu’aux absences de message ECM de
la part du point de congestion la station émettrice qui
défini le point de réaction augmente doucement sont
débit. Le bénéfique de cette augmentation
exponentielle se manifeste par une exploitation douce
d’une extra bande passante et de prendre en
considération le cas d’une perte du message du
feedback positive. L’augmentation individuelle du
débit est réalisée à un intervalle régulier Td, taux
courant R
R+Rd.
Figure 3 : Signalisation de congestion par les
feedback positive et négative.
On peut calculer aussi la valeur du RTT (Round
Trip Time) selon l’équation (1):
1.3. Réaction
(1)
La réaction est prise au niveau de la station
émettrice, celle-ci réduit son débit en se basant sur les
données du message de signalisation envoyé par le
point de congestion. L’ajustement du débit de la
source est défini selon l’algorithme Additive Increase
Multiplicative Decrease (AIMD) [DAV 07].
La figure 4 illustre un exemple d’augmentation et
de diminution de débit selon le feedback [DAV 07].
Dans le tableau 2 nous avons regroupé les
différents paramètres d’état et de configuration au
niveau du point de réaction.
Pour une congestion non sévère l’ajustement de
débit est défini par l’algorithme suivant :
-3-
SETIT2009
passante disponible. Toutefois, nous ne pouvons pas
augmenter le débit en se basant sur une valeur
instantané de Fb<0 ou de Qoff ou Qdelta parce qu’ils
vont tous changé de valeurs positives en négatives à
l’augmentation de RTT (Temps de cycle).
Pour exploiter donc un chemin d’une bande
passante disponible nous avons utilisé la méthode
SONAR au niveau de Point de Réaction (RP: Reaction
point) qui définie les étapes suivantes [ABU 97]:
• Réduction
decrease ».
multiplicative
« Multiplicative
• Recouvrement rapide « Fast Recovery (FR) ».
• Augmentation active « Active Increase (AI) ».
Figure 4 : Augmentation et diminution de débit
selon le feedback.
Tableau 2 : Paramètres définie au niveau du point de
ETAT
La figure 5 illustre le recouvrement rapide ainsi
que l’augmentation active.
PARAMÈTRES
CONFIGURATION
W=poids de composant
dérivé.
R= débit courant.
CPID= le courant
Congestion Point ID.
Gd=le gain de diminution
RTTavg=la dernière
mesure de RTT (Round
Trip time).
Rmin=le débit courant
minimum.
Tmax=Temps courant
maximale.
Gi=le gain
d’augmentation.
α= le débit maximum de
diminution.
β=le débit maximum
d’augmentation.
Figure 5 : Fast Recovery and Active Increase.
Wrtt=poids de filtre RTT.
1.4. Principe de la méthode SONAR
Td=horloge
d’augmentation
individuelle.
Le limiteur de débit RL (Rate Limiter) représente
dans la méthode SONAR le point de réaction (RP)
c'est-à-dire la machine émettrice.
Rd=somme
d’augmentation
individuelle.
Le RL envoie un ping périodique pour exploiter
une extra bande passante. Le comutateur qui ne
possède pas d’une extra bande passante répond en
indiquant cela, sinon pas de réponse.
A l’absence d’une réponse de la part du comutateur
le RL conclu que le chemin possède une extra bande
passante, le RL déduit cela à chaque fois qu’un ping
n’obtient pas d’ « echo ».
Rmin=débit minimum.
Tmax=temps maximum.
réaction.
1. QCN :
Quantification
Notification
1.5. L’algorithme en Rate Limiter (RL)
Congestion
RL passe à l’état WP à chaque fois qu’il reçoit un
signal Fb<0 ;
Lors d’une congestion sévère nous avons besoin de
s’assurer que la source trouve vite un débit plus faible.
A la disparition de ce problème de congestion et la
disposition d’une extra bande passante, il faut
permettre à la source de saisir une extra bande
passante. Pour cela il faut assurer un recouvrement
stable d’une bande passante disponible en se basant
sur une indication stable de l’existence d’une bande
Si l’horloge WP s’achève, le prochain paquet
envoyé par RL est un Paquet spéciale « special paket
».
Le paquet spécial représente un paquet de données
avec 1 bit remis pour indiquer qu’il est spécial.
Après que le paquet spécial est lancé, RL passe à
-4-
SETIT2009
un état d’attente d’écho WE (Waiting for echo).
envoyé par cycle, ensuite effectué un cycle de AI de
par exemple 75Kb envoyé.
Si RL entend un écho pour son SP « special paket
» alors le Ping Timer retourne à WP (Waiting to
probe) et le RL contenu l’opération (FR ou AI) [ABU
02].
A chaque instant la source est en FR ou bien en AI,
nous avons alors un boucle infinie de FR et AI.
A l’absence d’une bande passante disponible un
boucle de FR et de AI est effectué comme c’est décrit
dans la figure 8.
Si le WE temps s’achève alors le Ping Timer passe
à SF (Shortfuse) et le RL passe à HAI.
Le principe de l’algorithme Sonar au niveau du
limiteur de débit est illustré par la figure 6.
Figure 8 : Boucle infinie de FR et AI.
1.7. Loi de changement de débit courant (CR) et de
débit cible (TR)
A l’arrivé d’un feedback négative (Fb<0) :
Figure 6 : Algorithme de SONAR en RL.
Pendant le premier cycle de FR : Le débit courant
CR (Current Rate) diminue pour chaque signale de
Fb<0, et le débit cible (TR : Target Rate) reste
inchangé.
En HAI, RL augmente le débit grâce aux valeurs
byte_ctr et le ping Timer.
Pendant les cycles suivants : TR←CR (avant le
ping) ; CR← CR*(1-GD|FB|).
Le fonctionnement de l’horloge de valeurs byte_ctr
et le ping Timer est donné par la figure 7.
A la fin de chaque cycle FR : CR← (CR+TR)/2 (CR← Rd/2); TR ne change pas.
A la fin de chaque cycle AI ou HAI : TR←TR+RI
(pour AI) et TR← RI*Cycle_counter (pour HAI).
A la fin du premier cycle FR, si TR<10*CR alors
TR← TR/8 et CR← (TR+CR)/2.
Opération au niveau de Switch
Nous utilisons une horloge qui définie la période
de non congestion.
Soit : Q_eq= seuil de l’équilibre de la file
d’attente.
Figure 7 : Les horloges de RL : Byte-Ctr et ping
Timer.
Q_len= la longueur courante de la file.
Nous supposons que Q_eq=6 paquets.
Nous allons maintenir une estimation de feedback
pour chaque Rate Limiter (RL).
Nous supposons aussi que la bande passante est
disponible pour une file de longueur inférieure à 6
paquets.
Nous trouvons le Ping Timer dans un des trois
états : Waiting to probe (WP), Waiting for echo(WE),
Shortfuse (SF).
Si nous aurons Q_len < Q_eq cela veut dire que le
débit d’entrés dans la file est inférieur au débit sortant
1.6. Compteur d’Octet (Byte counter)
A chaque fois que le Q_len est inférieur à 6
paquets, le switch met son horloge de congestion. Si
l’horloge expire alors la bande passante est disponible
sinon l’horloge sera remit de nouveau pour Q_len
inférieur à 6 paquets. Si le Q_len devient à un moment
donné supérieur à 6, l’horloge sera interrompue et un
feedback négative est envoyé à la source avec une
probabilité P proportionnelle à Fb.
C’est pour calculer le nombre de cycle de FR (Fast
recovery) et de AI (Active Increase).
A l’arrivé d’un feedback négative le ping Timer se
déclenche et on effectue un recouvrement rapide
« Fast Recovery » FR.
Le compteur d’octet (Byte counter) calcule cinq
cycles de Fast Recovery pour par exemple 150 Kb
-5-
SETIT2009
Qsc=8
Qmc=5
Qeq=3
Les statistiques du débit minimal, maximal et
moyen du point de réaction sont données par la figure
10.
2. Résultats
Les résultats de simulation pour différentes
paramètres d’exécution de l’algorithme d’ECM sont
représentés par des diagrammes qui représentent
l’évolution du débit et la longueur courante de la file
au cours de la simulation. Nous avons utilisé
OMNeT++ comme outil de simulation [AND 05]
[GAB].
OMNeT ++ fourni une architecture à composant
pour les modèles; Les composants (modules) sont
programmés avec C++, puis assemblés dans des larges
composants en utilisant un langage de description de
haut niveau NED (NEtwork Description), elle peu
s’exécuter sur les systèmes d’exploitation Linux,
Unix, Windows.
L’algorithme
implémenté
ECM
(Ethernet
Congestion Manager) consiste à ajuster le débit de la
source selon l’état de la bande passante (disponible ou
non).
Le scénario utilisé à l’implémentation de
l’algorithme d’ECM contient une station qui émet des
messages, une file d’attente où les messages attendent
avant d’être servi pour le Core switch, et une station
réceptrice des messages.
Figure 10 : Les statistiques du débit minimal,
maximal et moyen du point de réaction.
Les statistiques de la longueur minimale,
maximale et moyenne de la file du point de congestion
sont données par la figure 11.
Figure 9: Topologie du réseau utilisé pour
l'implémentation d'ECM.
L’exécution de l’algorithme d’ECM dans un réseau
qui souffre de la congestion nous a fourni des
différents résultats selon les paramètres donnés dans le
fichier omnetpp.ini.
Pour les mêmes variables d’états et de
configurations du point de réaction qui sont inspirés
des expériences de Guenter Roeck en juillet 2007
[GUE 07b], nous avons effectué des variables d’états
et de configurations différentes pour le point de
congestion.
Figure 11: Les statistiques de la longueur
minimale, maximale et moyenne de la file du point de
congestion.
La variation du débit au cours de la simulation au
niveau du point de réaction est donnée par la figure
12.
Les paramètres d’états et de configurations de
point de réaction sont :
W=2
alpha=0.5
beta=0.5
CR=1000000 bit/s
Rmin=1000000 bit/s
Gd=0.00026667
Gi=0.53333
Tmax=1ms
Rd=100 bit/s
Td=1ms
les paramètres de configurations de point de
congestion sont :
-6-
SETIT2009
à celui d’ECM (Ethernet Congestion Manager). Les
efforts futurs devront aussi prendre en considération
une topologie de réseau plus compliqué avec plusieurs
nœuds. En outre, on peut envisager un Core Switch
qui dispose de plusieurs files d’attentes.
RÉFÉRENCES
[ABU 02] Abdu Kabbani,Rong Pan, Balaji Prabhaker and
Mick Seaman, “QCN : Algorithm for P-code”.
[ABU 97] Abdu Kabbani,Ashvin Lakshmikantha, Rong
Pan, Balaji Prabhkar, Mick seaman, “QCN: Transience,
Equilibrium,
Implementation”,
Telecom
Center
Workshop, 4 Septembre 1997.
Figure 12 : La variation du débit au cours de la
simulation au niveau du point de réaction.
[AND 05] Andrs Varga, “ OMNeT++ Descret Event
Simulation System version 3.2 User Manual », 29 Mars
2005.
La variation de la longueur de la file au cours de la
simulation au niveau du point de congestion est
donnée par la figure 13.
[DAV 07] David Bergamasco, « Ethernet Congestion
Manager (ECM) », IEEE 802 Plenary Meeting, 13 Mars
2007.
[GAB] Gabor Tabi, “Get into GNED, An introduction to the
GNED editor of OMNEST/OMNeT++”.
[GUE 07a] Guenter Roeck, « Cngestion Management
Protocols Addressing Concerns with Closed Loop,
Congestion Management Protocols », Teak Technologies
IEEE 802.1Qau, Stockholm Interim Meeting, September
2007.
[GUE
07b]
Guenter
Roeck,
Teak
Technologies, « Congestion Management Protocols
Simulation Results and Protocol Variations », Juin 2007
[JIA 06] J.Jiang and Raj Jain, “Simulation Modelling of
BCN V2.0 Phase 1: Model Validation”, IEEE
Congestion group Meeting, Denver, 8 Mars 2006.
Figure 13 : La variation de la longueur de la file
au cours de la simulation au niveau du point de
congestion.
[NAT 07]Natalie Giroux, Ken Young, “802.1Qau Design
Criteria Throughts”, juin 2007.
[NIC 03] Nicky Van Foreest, “Simulation Queueing
Network with ONeT++”, 24 Janvier 2003.
3. Conclusion
Nous proposant dans cet article une étude de
protocoles de contrôle de congestion ECM (Ethernet
Congestion Manager) et QCN (Quantification
Congestion Notification). Ce travail se place dans la
problématique de l’explosion de charge des réseaux et
le besoin sérieux de gérer et d’éviter les congestions.
Le mécanisme d’ECM et de QCN se base sur la
détection d’une congestion au cœur du réseau puis la
signalée aux stations émettrices pour que celles-ci
prend la réaction adéquate à la suite de l’information
de notification de congestion.
Pour exploiter un chemin d’une bande passante
disponible, avec ECM nous utilisons l’algorithme
Additive Increase Multiplicative Decrease (AIMD).
Cependant, avec QCN nous servons de la méthode
SONAR au niveau de Point de Réaction (RP :
Reaction point).
Nous souhaitons améliorer notre travaille, en
ajoutant l’implémentation de l’algorithme de QCN
(Quantification Congestion Notification) et le comparé
-7-