SlideShare une entreprise Scribd logo
Atelier Logiciel Libre
Mécanisme de gestion de la file d'attente
TRT3 TD2 TP3 | Nouri Anis
Ministère de l’Enseignement Supérieur et de la Recherche Scientifique
Faculté des Sciences dz Bizerte
Département de l’Informatique
1
Sommaire
I. INTRODUCTION .........................................................................................................................................................2
a) Verrouillage................................................................................................................................................... 2
b) Files d'attente pleines................................................................................................................................... 2
II. EXEMPLE DE FILE D’ATTENTE .................................................................................................................................3
II.1 RED RANDOM EARLYDETECTION...........................................................................................................................3
II.2 DROP TAILEN........................................................................................................................................................4
II.3 TBF TOKEN BUKETFILTER......................................................................................................................................5
III. CONCLUSION ........................................................................................................................................................8
a) Réduire le nombre de paquets abandonnés dans les routeurs ................................................................... 8
b) Fournirun service interactif à plus faible délai ............................................................................................ 8
c) Éviter le comportement de verrouillage ...................................................................................................... 8
2
I. Introduction
La théorie des files d’attente consiste en l’étude de systèmes ou des clients se présentent à
un dispositif de service, appelé serveur. Puisqu’un client occupe le serveur pendant un certain
temps, les autres clients doivent attendre avant d’être servis, formant ainsi une file d’attente.
Quelques exemples d’application :
 Réseaux informatiques : serveur = routeur, client = paquet.
 Ateliers (job shop) : serveur = machine, client = tâche. En ingénierie,
On s’intéresse à des métriques de performance des files d’attente, par exemple :
 Taille moyenne de la file d’attente.
 Taux d’utilisation du serveur.
 Temps moyen d’attente d’un client
 Le besoin d'une gestion active de file d'attente
La technique traditionnelle pour la gestion des longueurs de file d'attente chez un routeur
est d'établir une longueur maximum (en termes de paquets) pour chaque file d'attente,
d'accepter ces paquets pour la file d'attente jusque à ce que la longueur maximum soit atteinte,
puis de rejeter (abandonner) les paquets entrants suivants jusque à ce que la file d'attente
diminue à cause de la transmission d'un paquet de la file d'attente. Cette technique est connue
sous le nom de "abandon du bout de la queue" (tail drop), car le paquet arrivé le plus
récemment (c'est-à-dire, celui qui est au bout de la queue) est abandonné lorsque la file
d'attente est pleine. Cette méthode a bien servi l'Internet pendant des années, mais elle
présente deux inconvénients importants.
a) Verrouillage
Dans certaines situations, l'exclusion du bout de la queue permet à une seule connexion ou
à quelques flux de monopoliser l'espace de file d'attente, empêchant ainsi les autres
connexions d'obtenir de l'espace dans la file d'attente. Ce phénomène de "verrouillage" est
souvent le résultat d'effets de synchronisation ou autres effets temporels.
b) Files d'attente pleines
La discipline de l'abandon du bout de la queue permet aux files d'attente de conserver un
statut de file d'attente complète (ou presque complète) pendant de longues périodes car
l'abandon du bout de la queue ne signale l'encombrement (via un abandon de paquet) que si la
file d'attente est devenue pleine. Il est important de réduire la taille de la file d'attente en
régime permanent, et c'est peut-être l'objectif le plus important de la gestion de file d'attente.
L'objet de la mise en mémoire tampon sur le réseau est d'absorber les salves de données et
de les transmettre durant les salves de silence qui (on l'espère) vont suivre. Cela est essentiel
pour permettre la transmission de salves de données. La raison pour laquelle on veut avoir des
files d'attente normalement petites dans les routeurs devrait être claire : on veut avoir la
capacité de file d'attente pour absorber les salves. Le résultat contraire à l'intuition est que
d'entretenir des files d'attente normalement petites peut déboucher sur un débit supérieur ainsi
que sur un plus petit délai de bout en bout. En bref, les limites des files d'attente ne devraient
3
pas refléter les files d'attente d'état permanent qu'on veut conserver dans le réseau ; elles
devraient plutôt refléter la taille des salves qu'on a besoin d'absorber.
II. Exemple de file d’attente
II.1 RED random early detection
Le comportement normal des files d'attente de routeurs est appelé "tail-drop" (NdT :
élimine le reste). Le "tail-drop" consiste à mettre en file d'attente un certain volume de trafic
et à éliminer tout ce qui déborde. Ce n'est pas du tout équitable et cela conduit à des
retransmissions de synchronisation. Quand une retransmission de synchronisation a lieu, la
brusque rafale de rejet d'un routeur qui a atteint sa limite entraînera une rafale de
retransmissions retardée qui inondera à nouveau le routeur congestionné.
Dans le but d'en finir avec les congestions occasionnelles des liens, les routeurs de dorsales
intègrent souvent des files d'attente de grande taille. Malheureusement, bien que ces files
d'attente offrent un bon débit, elles peuvent augmenter sensiblement les temps de latence et
entraîner un comportement très saccadé des connexions TCP pendant la congestion.
Ces problèmes avec le "tail-drop" deviennent de plus en plus préoccupants avec
l'augmentation de l'utilisation d'applications hostiles au réseau. Le noyau Linux nous offre la
technique RED, abréviation de Random Early Detect ou détection précoce directe.
RED n'est pas la solution miracle à tous ces problèmes. Les applications qui n'intègrent pas
correctement la technique de "l'exponentiel back off" obtiennent toujours une part trop grande
de bande passante. Cependant, avec la technique RED elles ne provoquent pas trop de dégâts
sur le débit et les temps de latence des autres connexions.
RED élimine statistiquement des paquets du flux avant qu'il n'atteigne sa limite "dure"
(hard). Sur une dorsale congestionnée, cela entraîne un ralentissement en douceur de la liaison
et évite les retransmissions de synchronisation. La technique RED aide aussi TCP à trouver
une vitesse "équitable" plus rapidement : en permettant d'éliminer des paquets plus tôt, il
conserve une file d'attente plus courte et des temps de latence mieux contrôlés. La probabilité
qu'un paquet soit éliminé d'une connexion particulière est proportionnelle à la bande passante
utilisée par cette connexion plutôt qu'au nombre de paquets qu'elle envoie.
La technique RED est une bonne gestion de file d'attente pour les dorsales, où vous ne
pouvez pas vous permettre le coût d'une mémorisation d'état par session qui est nécessaire
pour une mise en file d'attente vraiment équitable.
Pour utiliser RED, vous devez régler trois paramètres : Min, Max et burst. Min est la taille
minimum de la file d'attente en octets avant que les rejets n'aient lieu, Max est le maximum
"doux" (soft) en dessous duquel l'algorithme s'efforcera de rester, et burst est le nombre
maximum de paquets envoyés "en rafale".
Vous devriez configurer Min en calculant le plus grand temps de latence acceptable pour la
mise en file d'attente, multiplié par votre bande passante. Par exemple, sur mon lien ISDN à
64 Kbits/s, je voudrais avoir un temps de latence de base de mise en file d'attente de 200 ms.
Je configure donc Min à 1600 octets (= 0,2 x 64000 / 8). Imposer une valeur Min trop petite
va dégrader le débit et une valeur Min trop grande va dégrader le temps de latence. Sur une
4
liaison lente, choisir un coefficient Min petit ne peut pas remplacer une réduction du MTU
pour améliorer les temps de réponse.
Vous devriez configurer Max à au moins deux fois Min pour éviter les synchronisations.
Sur des liens lents avec de petites valeurs de Min, il peut être prudent d'avoir Max quatre fois
plus grand que Min ou plus.
Burst contrôle la réponse de l'algorithme RED aux rafales. Burst doit être choisi plus grand
que min/avpkt (paquet moyen). Expérimentalement, j'ai trouvé que
(min+min+max)/(3*avpkt) marche bien.
De plus, vous devez configurer limit et avpkt. Limit est une valeur de sécurité : s'il y a plus
de Limit octets dans la file, RED reprend la technique "tail-drop". Je choisis une valeur
typique égale à 8 fois Max. Avpkt devrait être fixé à la taille moyenne d'un paquet. 1000
fonctionne correctement sur des liaisons Internet haut débit ayant un MTU de 1500 octets.
II.2 drop tailen
Le comportement le plus utilisé pour la gestion des files d’attente des routeurs sur Internet
est appelé Drop Tail ou Tail Drop (traduction : « élimine le reste »). La politique Drop Tail
consiste `a mettre en file d’attente les paquets qui arrivent, et à rejeter tous les paquets quand
la taille de la file d’attente dépasse la taille du tampon. La probabilité de rejet assez simple de
Drop Tail d(k) est donnée par l’équation suivante :
d(k) = {0 si k ≤ K
1 si k>K
où k est la taille de la file d’attente et K la taille du tampon. Cela conduit `à des
phénomènes de retransmissions de synchronisation pour les flux TCP par exemple. Quand
une retransmission de synchronisation a lieu, la brusque rafale de rejets d’un routeur qui a
atteint sa limite entraınera une rafale de retransmissions retardée qui inondera nouveau le
routeur congestionné. Dans le but de régler les problèmes de congestion due `a des rafales de
paquets, les routeurs intègrent souvent des files d’attente de grande taille. Malheureusement,
bien que ces files d’attente
1.3. La gestion classique des files d’attente offrent un bon débit, elles peuvent augmenter
sensiblement les temps de latence et entraıner un comportement très saccadé des connexions
TCP pendant la congestion. Les files Drop Tail sont monopolisées par certains types de flux
et empêchent ainsi les autres transmissions de trouver une place dans la file. C’est le problème
du lock-out de Drop Tail : tous les flux n’ont pas la même chance d’entrer dans la file
d’attente. Les problèmes avec DropTail deviennent de plus en plus préoccupants avec
l’augmentation de l’utilisation d’applications« hostiles »au réseau comme les applications de
diffusion vidéo. Il existe plusieurs autres techniques, côté routeur, pour obtenir une utilisation
optimale des ressources et/ou adapter les applications aux conditions dynamiques du réseau.
5
II.3 TBF token buket filter
Le Token Bucket Filter (TBF) est un gestionnaire de mise en file d'attente simple. Il ne fait
que laisser passer les paquets entrants avec un débit n'excédant pas une limite fixée
administrativement. L'envoi de courtes rafales de données avec un débit dépassant cette limite
est cependant possible.
TBF est très précis, et peu gourmand du point de vue réseau et processeur. Considérez-le
en premier si vous voulez simplement ralentir une interface !
L'implémentation TBF consiste en un tampon (seau), constamment rempli par des éléments
virtuels d'information appelés jetons, avec un débit spécifique (débit de jeton). Le paramètre
le plus important du tampon est sa taille, qui correspond au nombre de jetons qu'il peut
stocker.
Chaque jeton entrant laisse sortir un paquet de données de la file d'attente de données et ce
jeton est alors supprimé du seau. L'association de cet algorithme avec les deux flux de jetons
et de données, nous conduit à trois scénarios possibles :
Les données arrivent dans TBF avec un débit EGAL au débit des jetons entrants. Dans ce
cas, chaque paquet entrant a son jeton correspondant et passe la file d'attente sans délai.
Les données arrivent dans TBF avec un débit PLUS PETIT que le débit des jetons. Seule
une partie des jetons est supprimée au moment où les paquets de données sortent de la file
d'attente, de sorte que les jetons s'accumulent jusqu'à atteindre la taille du tampon. Les jetons
libres peuvent être utilisés pour envoyer des données avec un débit supérieur au débit des
jetons standard, si de courtes rafales de données arrivent.
Les données arrivent dans TBF avec un débit PLUS GRAND que le débit des jetons. Ceci
signifie que le seau sera bientôt dépourvu de jetons, ce qui provoque l'arrêt de TBF pendant
un moment. Ceci s'appelle << une situation de dépassement de limite >> (overlimit situation).
Si les paquets continuent à arriver, ils commenceront à être éliminés.
Le dernier scénario est très important, car il autorise la mise en forme administrative de la
bande passante disponible pour les données traversant le filtre.
L'accumulation de jetons autorise l'émission de courtes rafales de données sans perte en
situation de dépassement de limite, mais toute surcharge prolongée causera systématiquement
le retard des paquets, puis leur rejet.
Notez que, dans l'implémentation réelle, les jetons correspondent à des octets, et non des
paquets.
 Paramètres & usage
Même si vous n'aurez probablement pas besoin de les changer, TBF a des paramètres.
D'abord, ceux toujours disponibles sont :
 limit or latency
Limit est le nombre d'octets qui peuvent être mis en file d'attente en attendant la
disponibilité de jetons. Vous pouvez également indiquer ceci d'une autre manière en
6
configurant le paramètre latency, qui spécifie le temps maximal pendant lequel un paquet peut
rester dans TBF. Ce dernier paramètre prend en compte la taille du seau, le débit, et s'il est
configuré, le débit de crête (peakrate).
 burst/buffer/maxburst
Taille du seau, en octets. C'est la quantité maximale, en octets, de jetons dont on disposera
simultanément. En général, plus les débits de mise en forme sont importants, plus le tampon
doit être grand. Pour 10 Mbit/s sur plateforme Intel, vous avez besoin d'un tampon d'au moins
10 kilo-octets si vous voulez atteindre la limitation configurée !
Si votre tampon est trop petit, les paquets pourront être rejetés car il arrive plus de jetons
par top d'horloge que ne peut en contenir le tampon.
 mpu
Un paquet de taille nulle n'utilise pas une bande passante nulle. Pour ethernet, la taille
minimale d'un paquet est de 64 octets. L'Unité Minimale de Paquet (Minimun Packet Unit)
détermine le nombre minimal de jetons à utiliser pour un paquet.
 rate
Le paramètre de la vitesse. Voir les remarques au-dessus à propos des limites !
Si le seau contient des jetons et qu'il est autorisé à se vider, alors il le fait par défaut avec
une vitesse infinie. Si ceci vous semble inacceptable, utilisez les paramètres suivants :
 peakrate
Si des jetons sont disponibles et que des paquets arrivent, ils sont immédiatement envoyés
par défaut ; et pour ainsi dire à << la vitesse de la lumière >>. Cela peut ne pas vous convenir,
spécialement si vous avez un grand seau.
Le débit de crête (peak rate) peut être utilisé pour spécifier la vitesse à laquelle le seau est
autorisé à se vider. Si tout se passe comme écrit dans les livres, ceci est réalisé en libérant un
paquet, puis en attendant suffisamment longtemps, pour libérer le paquet suivant. Le temps
d'attente est calculé de manière à obtenir un débit égal au débit de crête.
Cependant, étant donné que la résolution du minuteur (timer) d'UNIX est de 10 ms et que
les paquets ont une taille moyenne de 10 000 bits, nous sommes limités à un débit de crête de
1mbit/s !
 mtu/minburst
Le débit de crête de 1Mb/s ne sert pas à grand chose si votre débit habituel est supérieur à
cette valeur. Un débit de crête plus élevé peut être atteint en émettant davantage de paquets
par top du minuteur, ce qui a pour effet de créer un second seau.
Ce second bucket ne prend par défaut qu'un seul paquet, et n'est donc en aucun cas un seau.
Pour calculer le débit de crête maximum, multipliez le mtu que vous avez configuré par
100 (ou plus exactement par HZ, qui est égal à 100 sur Intel et à 1024 sur Alpha).
 Configuration simple
7
Voici une configuration simple, mais très utile :
# tc qdisc add dev ppp0 root tbf rate 220kbit latency 50ms burst 1540
Pourquoi est-ce utile ? Si vous avez un périphérique réseau avec une grande file d'attente,
comme un modem DSL ou un modem câble, et que le dialogue se fasse à travers une interface
rapide, comme une interface ethernet, vous observerez que télécharger vers l'amont
(uploading) dégrade complètement l'interactivité.
[NdT : uploading désigne une opération qui consiste à transférer des données ou des
programmes stockés dans un ordinateur local vers un ordinateur distant à travers un réseau. La
traduction officielle pour ce terme est << téléchargement vers l'amont >>. On parle alors de
voie montante. Le downloading désigne l'opération inverse (transfert d'un hôte distant vers
l'ordinateur local) et est traduit par << téléchargement >> ou << téléchargement vers l'aval
>>. On parle alors de la voie descendante.]
Le téléchargement vers l'amont va en effet remplir la file d'attente du modem. Celle-ci est
probablement ENORME car cela aide vraiment à obtenir de bon débit de téléchargement vers
l'amont. Cependant, ceci n'est pas forcément ce que voulez. Vous ne voulez pas forcément
avoir une file d'attente importante de manière à garder l'interactivité et pouvoir encore faire
des choses pendant que vous envoyez des données.
La ligne de commande au-dessus ralentit l'envoi de données à un débit qui ne conduit pas à
une mise en file d'attente dans le modem. La file d'attente réside dans le noyau Linux, où nous
pouvons lui imposer une taille limite.
Modifier la valeur 220kbit avec votre vitesse de lien REELLE moins un petit pourcentage.
Si vous avez un modem vraiment rapide, augmenter un peu le paramètre burst.
8
III. Conclusion
En résumé, un mécanisme de gestion active de file d'attente peut fournir les avantages
suivants pour les flux qui "répondent".
a) Réduire le nombre de paquets abandonnés dans les routeurs
Les salves de paquet sont un aspect inévitable des réseaux par paquet [Willinger95]. Si tout
l'espace de file d'attente dans un routeur est déjà affecté au trafic "d'état permanent" ou si
l'espace de mémoire tampon est inadéquat, le routeur n'aura alors aucune capacité pour mettre
les salves en mémoire tampon. En maintenant petite la taille moyenne de file d'attente, la
gestion active de file d'attente donne une plus grande capacité d'absorption des salves qui
surviennent naturellement sans abandonner de paquets.
De plus, sans une gestion active de file d'attente, plus de paquets seront abandonnés
lorsqu’une file d'attente déborde. Cela n'est pas souhaitable pour plusieurs raisons. Tout
d'abord, avec une file d'attente partagée et la discipline d'abandon du bout de la file d'attente,
une synchronisation globale inutile du ralentissement des flux peut résulter en une diminution
de l'utilisation moyenne de la liaison, et donc en une diminution du débit du réseau. Ensuite,
TCP récupère plus difficilement d'une salve d'abandons de paquets que de l'abandon d'un seul
paquet. Troisièmement, des abandons inutiles de paquet représentent un gâchis possible de
bande passante sur le chemin vers le point d'abandon.
b) Fournir un service interactif à plus faible délai
En conservant petite la taille moyenne de la file d'attente, la gestion de file d'attente va
réduire les délais subis par les flux. Ceci est particulièrement important pour les applications
interactives telles que les courts transferts sur la Toile, le trafic Telnet, ou les sessions audio-
vidéo interactives, dont les performances subjectives (et objectives) sont meilleures lorsque le
délai de bout en bout est faible.
c) Éviter le comportement de verrouillage
La gestion active de file d'attente peut empêcher le comportement de verrouillage en
s'assurant qu'il y aura presque toujours une mémoire tampon disponible pour un paquet
entrant. Pour la même raison, la gestion active de file d'attente peut empêcher un biais du
routeur à l'encontre des flux à faible bande passante mais très saccadés.
Il est clair que le verrouillage est indésirable parce qu'il constitue une injustice criante entre
les groupes de flux. Cependant, on ne va pas appeler cet avantage "égalité accrue", parce que
l'égalité parfaite entre les flux nécessite un état par flux, ce qui n'est pas fourni par la gestion
de file d'attente. Par exemple, dans un routeur qui utilise la gestion de file d'attente mais
seulement la programmation FIFO, deux flux TCP peuvent recevoir des bandes passantes très
différentes simplement parce qu’ils ont des délais d'aller-retour différents [Floyd91], et un
flux qui n'utilise pas le contrôle d'encombrement reçoit plus de bande passante qu'un flux qui
9
l'utilise. L'état flux par flux pour réaliser l'égalité parfaite pourrait être entretenu par un
algorithme de programmation flux par flux tel que la mise en file d'attente équitable (FQ, Fair
Queueing) [Demers90], ou un algorithme de programmation fondé sur la classe tel que CBQ
[Floyd95], par exemple.
D'un autre côté, la gestion active de file d'attente est nécessaire même pour les routeurs qui
utilisent des algorithmes de programmation flux par flux tels que FQ ou des algorithmes de
programmation fondés sur la classe tels que CBQ. La raison en est que par eux-mêmes les
algorithmes de programmation flux par flux ne font rien pour contrôler la taille globale de file
d'attente des queues individuelles. La gestion active de file d'attente est nécessaire pour
contrôler les tailles moyennes globales de file d'attente, de telle sorte que les salves arrivantes
puissent être traitées sans abandon de paquet. De plus, la gestion active de file d'attente
devrait être utilisée pour contrôler la taille de la file d'attente pour chaque flux ou classe
individuel, de façon à ce qu'ils ne subissent pas de forts retards inutiles. Donc, la gestion
active de file d'attente devrait être appliquée entre classes ou flux aussi bien qu'au sein de
chaque classe ou flux.

Contenu connexe

Tendances

Réseaux mobiles
Réseaux mobiles Réseaux mobiles
Réseaux mobiles
Hibatallah Aouadni
 
Methodes d'accès dans les réseaux locaux
Methodes d'accès dans les réseaux locauxMethodes d'accès dans les réseaux locaux
Methodes d'accès dans les réseaux locaux
Ines Kechiche
 
Protocole RIP1, RIP2, RIPng
Protocole RIP1, RIP2, RIPngProtocole RIP1, RIP2, RIPng
Protocole RIP1, RIP2, RIPngMax Benana
 
Umts
UmtsUmts
Gsm Protocoles & ProcéDures
Gsm   Protocoles & ProcéDuresGsm   Protocoles & ProcéDures
Gsm Protocoles & ProcéDures
Anouar Loukili
 
Présentation Cdma, Multiplexage CDMA, principes de Code et cas d'exemple
Présentation Cdma, Multiplexage CDMA, principes de Code et cas d'exemplePrésentation Cdma, Multiplexage CDMA, principes de Code et cas d'exemple
Présentation Cdma, Multiplexage CDMA, principes de Code et cas d'exemple
Max Benana
 
Introduction aux réseaux locaux
 Introduction aux réseaux locaux Introduction aux réseaux locaux
Introduction aux réseaux locaux
Ines Kechiche
 
Architecture d'un réseau GSM 2G (Téléphonie Mobile)
Architecture d'un réseau GSM 2G (Téléphonie Mobile)Architecture d'un réseau GSM 2G (Téléphonie Mobile)
Architecture d'un réseau GSM 2G (Téléphonie Mobile)
Assia Mounir
 
td_devoirs_2013.pdf
td_devoirs_2013.pdftd_devoirs_2013.pdf
td_devoirs_2013.pdf
MeryemH2
 
Le model OSI.pptx
Le model OSI.pptxLe model OSI.pptx
Le model OSI.pptx
xxBMAxx1
 
Architecture reseau mobile
Architecture reseau mobileArchitecture reseau mobile
Architecture reseau mobileGilles Samba
 
chap1 transmission-generalités
chap1 transmission-generalitéschap1 transmission-generalités
chap1 transmission-generalités
BAKKOURY Jamila
 
Simulation d'un réseau Ad-Hoc sous NS2
Simulation d'un réseau Ad-Hoc sous NS2Simulation d'un réseau Ad-Hoc sous NS2
Simulation d'un réseau Ad-Hoc sous NS2
Rihab Chebbah
 
Chap2 physique
Chap2 physiqueChap2 physique
Chap2 physiqueEns Kouba
 
Cour simulation ns2
Cour simulation ns2Cour simulation ns2
Cour simulation ns2Gilles Samba
 
Cours systèmes temps réel partie 1 Prof. Khalifa MANSOURI
Cours  systèmes temps réel partie 1 Prof. Khalifa MANSOURICours  systèmes temps réel partie 1 Prof. Khalifa MANSOURI
Cours systèmes temps réel partie 1 Prof. Khalifa MANSOURI
Mansouri Khalifa
 
Réseau lora
Réseau loraRéseau lora
Réseau lora
IoT Tunisia
 
Chap3 liaison de données
Chap3 liaison de donnéesChap3 liaison de données
Chap3 liaison de donnéesEns Kouba
 
Commutation
CommutationCommutation
Commutation
Ines Kechiche
 

Tendances (20)

Réseaux mobiles
Réseaux mobiles Réseaux mobiles
Réseaux mobiles
 
Methodes d'accès dans les réseaux locaux
Methodes d'accès dans les réseaux locauxMethodes d'accès dans les réseaux locaux
Methodes d'accès dans les réseaux locaux
 
Protocole RIP1, RIP2, RIPng
Protocole RIP1, RIP2, RIPngProtocole RIP1, RIP2, RIPng
Protocole RIP1, RIP2, RIPng
 
Umts
UmtsUmts
Umts
 
Gsm Protocoles & ProcéDures
Gsm   Protocoles & ProcéDuresGsm   Protocoles & ProcéDures
Gsm Protocoles & ProcéDures
 
Présentation Cdma, Multiplexage CDMA, principes de Code et cas d'exemple
Présentation Cdma, Multiplexage CDMA, principes de Code et cas d'exemplePrésentation Cdma, Multiplexage CDMA, principes de Code et cas d'exemple
Présentation Cdma, Multiplexage CDMA, principes de Code et cas d'exemple
 
Introduction aux réseaux locaux
 Introduction aux réseaux locaux Introduction aux réseaux locaux
Introduction aux réseaux locaux
 
Architecture d'un réseau GSM 2G (Téléphonie Mobile)
Architecture d'un réseau GSM 2G (Téléphonie Mobile)Architecture d'un réseau GSM 2G (Téléphonie Mobile)
Architecture d'un réseau GSM 2G (Téléphonie Mobile)
 
td_devoirs_2013.pdf
td_devoirs_2013.pdftd_devoirs_2013.pdf
td_devoirs_2013.pdf
 
Le model OSI.pptx
Le model OSI.pptxLe model OSI.pptx
Le model OSI.pptx
 
Architecture reseau mobile
Architecture reseau mobileArchitecture reseau mobile
Architecture reseau mobile
 
chap1 transmission-generalités
chap1 transmission-generalitéschap1 transmission-generalités
chap1 transmission-generalités
 
50868690 rapport-lte
50868690 rapport-lte50868690 rapport-lte
50868690 rapport-lte
 
Simulation d'un réseau Ad-Hoc sous NS2
Simulation d'un réseau Ad-Hoc sous NS2Simulation d'un réseau Ad-Hoc sous NS2
Simulation d'un réseau Ad-Hoc sous NS2
 
Chap2 physique
Chap2 physiqueChap2 physique
Chap2 physique
 
Cour simulation ns2
Cour simulation ns2Cour simulation ns2
Cour simulation ns2
 
Cours systèmes temps réel partie 1 Prof. Khalifa MANSOURI
Cours  systèmes temps réel partie 1 Prof. Khalifa MANSOURICours  systèmes temps réel partie 1 Prof. Khalifa MANSOURI
Cours systèmes temps réel partie 1 Prof. Khalifa MANSOURI
 
Réseau lora
Réseau loraRéseau lora
Réseau lora
 
Chap3 liaison de données
Chap3 liaison de donnéesChap3 liaison de données
Chap3 liaison de données
 
Commutation
CommutationCommutation
Commutation
 

En vedette

Marketing Plan for Apps (Digital queue management system)
Marketing Plan for Apps (Digital queue management system)Marketing Plan for Apps (Digital queue management system)
Marketing Plan for Apps (Digital queue management system)
Conn Yee Woon
 
Expressqueue queue management system - anglais
Expressqueue queue management system - anglaisExpressqueue queue management system - anglais
Expressqueue queue management system - anglais
ExpressInformatique
 
Efficient Digital Signage With Queue Management System
Efficient Digital Signage With Queue Management SystemEfficient Digital Signage With Queue Management System
Efficient Digital Signage With Queue Management System
ONLINET Group
 
The Psychology of Waiting Lines
The Psychology of Waiting LinesThe Psychology of Waiting Lines
The Psychology of Waiting Lines
Hristo Borislavov Kolev
 
Système de gestion de tickets
Système de gestion de ticketsSystème de gestion de tickets
Système de gestion de ticketsraymen87
 
jeu pilotage des flux et files d'attente
jeu pilotage des flux et files d'attentejeu pilotage des flux et files d'attente
jeu pilotage des flux et files d'attente
CIPE
 
Customers Waiting in Lines - Service Operations - Yolanda Williams
Customers Waiting in Lines - Service Operations - Yolanda WilliamsCustomers Waiting in Lines - Service Operations - Yolanda Williams
Customers Waiting in Lines - Service Operations - Yolanda Williams
Yolanda Williams
 
Queue Management System
Queue Management SystemQueue Management System
Queue Management System
Rahul Barot
 
Waiting Line Management Problem Solution, Writer Jacobs (1-15)
Waiting Line Management Problem Solution, Writer Jacobs (1-15)Waiting Line Management Problem Solution, Writer Jacobs (1-15)
Waiting Line Management Problem Solution, Writer Jacobs (1-15)
Imran Hossain
 
Waiting line
Waiting lineWaiting line
Waiting line
E P John
 
Managing demand and capacity and waiting line strategies
Managing demand and capacity and waiting line strategiesManaging demand and capacity and waiting line strategies
Managing demand and capacity and waiting line strategies
Dr. Sneha Sharma
 
Waiting Line Management
Waiting Line Management Waiting Line Management
Waiting Line Management
Joshua Miranda
 
File management
File managementFile management
File management
Mohd Arif
 
Le Réseau GSM
Le Réseau GSMLe Réseau GSM
Le Réseau GSM
Tahraoui Samir
 
File management ppt
File management pptFile management ppt
File management ppt
marotti
 
ExpressQueue systeme de gestion de file d'attente
ExpressQueue systeme de gestion de file d'attenteExpressQueue systeme de gestion de file d'attente
ExpressQueue systeme de gestion de file d'attente
ExpressInformatique
 
Réseau GSM, installation de BTS (DBS3900)
Réseau GSM, installation de BTS (DBS3900)Réseau GSM, installation de BTS (DBS3900)
Réseau GSM, installation de BTS (DBS3900)Vicheka Phor
 
Geografia
GeografiaGeografia

En vedette (20)

Marketing Plan for Apps (Digital queue management system)
Marketing Plan for Apps (Digital queue management system)Marketing Plan for Apps (Digital queue management system)
Marketing Plan for Apps (Digital queue management system)
 
Expressqueue queue management system - anglais
Expressqueue queue management system - anglaisExpressqueue queue management system - anglais
Expressqueue queue management system - anglais
 
Efficient Digital Signage With Queue Management System
Efficient Digital Signage With Queue Management SystemEfficient Digital Signage With Queue Management System
Efficient Digital Signage With Queue Management System
 
The Psychology of Waiting Lines
The Psychology of Waiting LinesThe Psychology of Waiting Lines
The Psychology of Waiting Lines
 
Système de gestion de tickets
Système de gestion de ticketsSystème de gestion de tickets
Système de gestion de tickets
 
jeu pilotage des flux et files d'attente
jeu pilotage des flux et files d'attentejeu pilotage des flux et files d'attente
jeu pilotage des flux et files d'attente
 
Customers Waiting in Lines - Service Operations - Yolanda Williams
Customers Waiting in Lines - Service Operations - Yolanda WilliamsCustomers Waiting in Lines - Service Operations - Yolanda Williams
Customers Waiting in Lines - Service Operations - Yolanda Williams
 
Queue Management System
Queue Management SystemQueue Management System
Queue Management System
 
Waiting Line Management Problem Solution, Writer Jacobs (1-15)
Waiting Line Management Problem Solution, Writer Jacobs (1-15)Waiting Line Management Problem Solution, Writer Jacobs (1-15)
Waiting Line Management Problem Solution, Writer Jacobs (1-15)
 
Waiting line
Waiting lineWaiting line
Waiting line
 
Managing demand and capacity and waiting line strategies
Managing demand and capacity and waiting line strategiesManaging demand and capacity and waiting line strategies
Managing demand and capacity and waiting line strategies
 
Waiting Line Management
Waiting Line Management Waiting Line Management
Waiting Line Management
 
File management
File managementFile management
File management
 
Le Réseau GSM
Le Réseau GSMLe Réseau GSM
Le Réseau GSM
 
File management ppt
File management pptFile management ppt
File management ppt
 
ExpressQueue systeme de gestion de file d'attente
ExpressQueue systeme de gestion de file d'attenteExpressQueue systeme de gestion de file d'attente
ExpressQueue systeme de gestion de file d'attente
 
Réseau GSM, installation de BTS (DBS3900)
Réseau GSM, installation de BTS (DBS3900)Réseau GSM, installation de BTS (DBS3900)
Réseau GSM, installation de BTS (DBS3900)
 
Test mise en ligne 2
Test mise en ligne   2Test mise en ligne   2
Test mise en ligne 2
 
Geografia
GeografiaGeografia
Geografia
 
Creuse meninges
Creuse meningesCreuse meninges
Creuse meninges
 

Similaire à Mécanisme de gestion de la file d'attente

wireshark.pdf
wireshark.pdfwireshark.pdf
wireshark.pdf
Drm/Bss Gueda
 
Initiation à l’analyse réseau avec Wireshark.pdf
Initiation à l’analyse réseau avec Wireshark.pdfInitiation à l’analyse réseau avec Wireshark.pdf
Initiation à l’analyse réseau avec Wireshark.pdf
Drm/Bss Gueda
 
ccna 4 frame relay exposée.docx
ccna 4 frame relay exposée.docxccna 4 frame relay exposée.docx
ccna 4 frame relay exposée.docx
AlexLissom
 
Cours 7 congestion
Cours 7 congestionCours 7 congestion
Cours 7 congestion
ALIOUNEGAYE5
 
éTude des techno de stockage
éTude des techno de stockageéTude des techno de stockage
éTude des techno de stockagekhech123
 
Présentation de l'article &quot;taming tcp incast throughput collapse in dat...
Présentation de l'article &quot;taming tcp incast throughput collapse in dat...Présentation de l'article &quot;taming tcp incast throughput collapse in dat...
Présentation de l'article &quot;taming tcp incast throughput collapse in dat...
Wiem louhichi
 
Apache Storm - Introduction au traitement temps-réel avec Storm
Apache Storm - Introduction au traitement temps-réel avec StormApache Storm - Introduction au traitement temps-réel avec Storm
Apache Storm - Introduction au traitement temps-réel avec Storm
Paris_Storm_UG
 
Paris stormusergroup intrudocution
Paris stormusergroup intrudocutionParis stormusergroup intrudocution
Paris stormusergroup intrudocutionParis_Storm_UG
 
Protocoles d'acces aleatoires
Protocoles d'acces aleatoiresProtocoles d'acces aleatoires
Protocoles d'acces aleatoires
KONAN MARTIAL
 
Les secrets de la JVM pour les algos à haute fréquence
Les secrets de la JVM pour les algos à haute fréquenceLes secrets de la JVM pour les algos à haute fréquence
Les secrets de la JVM pour les algos à haute fréquence
OCTO Technology
 
Noyau temps réel freertos cheriet mohammed el amine
Noyau temps réel freertos cheriet mohammed el amineNoyau temps réel freertos cheriet mohammed el amine
Noyau temps réel freertos cheriet mohammed el amine
CHERIET Mohammed El Amine
 
Généralités sur le routeur
Généralités sur le routeurGénéralités sur le routeur
Généralités sur le routeur
Stany Mwamba
 
Étude de Qualité de service d’un serveur Web
Étude de Qualité de service d’un serveur WebÉtude de Qualité de service d’un serveur Web
Étude de Qualité de service d’un serveur Web
Amina Ch
 
Présentation algo
Présentation algoPrésentation algo
Présentation algo
Mustapha bouadaine
 
66051496 lte-9
66051496 lte-966051496 lte-9
66051496 lte-9mwara1
 
Technologies & Systèmes
Technologies & SystèmesTechnologies & Systèmes
Technologies & SystèmesPaulin CHOUDJA
 
CoAP master presentaion
CoAP master presentaionCoAP master presentaion
CoAP master presentaionTarik Sefiri
 
Switching
SwitchingSwitching
Switching
Omar Lakrary
 

Similaire à Mécanisme de gestion de la file d'attente (20)

wireshark.pdf
wireshark.pdfwireshark.pdf
wireshark.pdf
 
Initiation à l’analyse réseau avec Wireshark.pdf
Initiation à l’analyse réseau avec Wireshark.pdfInitiation à l’analyse réseau avec Wireshark.pdf
Initiation à l’analyse réseau avec Wireshark.pdf
 
ccna 4 frame relay exposée.docx
ccna 4 frame relay exposée.docxccna 4 frame relay exposée.docx
ccna 4 frame relay exposée.docx
 
Cours 7 congestion
Cours 7 congestionCours 7 congestion
Cours 7 congestion
 
éTude des techno de stockage
éTude des techno de stockageéTude des techno de stockage
éTude des techno de stockage
 
Présentation de l'article &quot;taming tcp incast throughput collapse in dat...
Présentation de l'article &quot;taming tcp incast throughput collapse in dat...Présentation de l'article &quot;taming tcp incast throughput collapse in dat...
Présentation de l'article &quot;taming tcp incast throughput collapse in dat...
 
Apache Storm - Introduction au traitement temps-réel avec Storm
Apache Storm - Introduction au traitement temps-réel avec StormApache Storm - Introduction au traitement temps-réel avec Storm
Apache Storm - Introduction au traitement temps-réel avec Storm
 
Paris stormusergroup intrudocution
Paris stormusergroup intrudocutionParis stormusergroup intrudocution
Paris stormusergroup intrudocution
 
Protocoles d'acces aleatoires
Protocoles d'acces aleatoiresProtocoles d'acces aleatoires
Protocoles d'acces aleatoires
 
Les secrets de la JVM pour les algos à haute fréquence
Les secrets de la JVM pour les algos à haute fréquenceLes secrets de la JVM pour les algos à haute fréquence
Les secrets de la JVM pour les algos à haute fréquence
 
Noyau temps réel freertos cheriet mohammed el amine
Noyau temps réel freertos cheriet mohammed el amineNoyau temps réel freertos cheriet mohammed el amine
Noyau temps réel freertos cheriet mohammed el amine
 
Généralités sur le routeur
Généralités sur le routeurGénéralités sur le routeur
Généralités sur le routeur
 
Asterisk
AsteriskAsterisk
Asterisk
 
Étude de Qualité de service d’un serveur Web
Étude de Qualité de service d’un serveur WebÉtude de Qualité de service d’un serveur Web
Étude de Qualité de service d’un serveur Web
 
Présentation algo
Présentation algoPrésentation algo
Présentation algo
 
66051496 lte-9
66051496 lte-966051496 lte-9
66051496 lte-9
 
Vlan
VlanVlan
Vlan
 
Technologies & Systèmes
Technologies & SystèmesTechnologies & Systèmes
Technologies & Systèmes
 
CoAP master presentaion
CoAP master presentaionCoAP master presentaion
CoAP master presentaion
 
Switching
SwitchingSwitching
Switching
 

Plus de Anis Nouri

Google une royaume pas comme les autre
Google une royaume pas comme les autreGoogle une royaume pas comme les autre
Google une royaume pas comme les autre
Anis Nouri
 
Lettre de motivation pour technicien supérieur en réseaux et télécomminication
Lettre de motivation pour technicien supérieur en réseaux et télécomminicationLettre de motivation pour technicien supérieur en réseaux et télécomminication
Lettre de motivation pour technicien supérieur en réseaux et télécomminication
Anis Nouri
 
Curriculum vitae pour technicien superieur en réseaux et télécommunication
Curriculum vitae pour technicien superieur en réseaux et télécommunicationCurriculum vitae pour technicien superieur en réseaux et télécommunication
Curriculum vitae pour technicien superieur en réseaux et télécommunication
Anis Nouri
 
Installation ubuntu 14.04
Installation ubuntu 14.04Installation ubuntu 14.04
Installation ubuntu 14.04
Anis Nouri
 
Qu’est ce qu’un xG ?
Qu’est ce qu’un xG ?Qu’est ce qu’un xG ?
Qu’est ce qu’un xG ?
Anis Nouri
 
Digital Subscriber Line - Ligne numérique d’abonné
Digital Subscriber Line - Ligne numérique d’abonnéDigital Subscriber Line - Ligne numérique d’abonné
Digital Subscriber Line - Ligne numérique d’abonné
Anis Nouri
 
Installation du Network Simulator 2
Installation du Network Simulator 2Installation du Network Simulator 2
Installation du Network Simulator 2
Anis Nouri
 
Logiciel libre de simulation a événement discret
Logiciel libre de simulation a événement discret Logiciel libre de simulation a événement discret
Logiciel libre de simulation a événement discret
Anis Nouri
 
Mise à niveau d’un Data Center VoIP de CUCM 7.0 à CUCM 9.0
Mise à niveau d’un Data Center VoIP de CUCM 7.0 à CUCM 9.0 Mise à niveau d’un Data Center VoIP de CUCM 7.0 à CUCM 9.0
Mise à niveau d’un Data Center VoIP de CUCM 7.0 à CUCM 9.0
Anis Nouri
 
Mise à niveau d’un Data Center VoIP de CUCM 7.0 à CUCM 9.0
Mise à niveau d’un Data Center VoIP de CUCM 7.0 à CUCM 9.0 Mise à niveau d’un Data Center VoIP de CUCM 7.0 à CUCM 9.0
Mise à niveau d’un Data Center VoIP de CUCM 7.0 à CUCM 9.0
Anis Nouri
 

Plus de Anis Nouri (10)

Google une royaume pas comme les autre
Google une royaume pas comme les autreGoogle une royaume pas comme les autre
Google une royaume pas comme les autre
 
Lettre de motivation pour technicien supérieur en réseaux et télécomminication
Lettre de motivation pour technicien supérieur en réseaux et télécomminicationLettre de motivation pour technicien supérieur en réseaux et télécomminication
Lettre de motivation pour technicien supérieur en réseaux et télécomminication
 
Curriculum vitae pour technicien superieur en réseaux et télécommunication
Curriculum vitae pour technicien superieur en réseaux et télécommunicationCurriculum vitae pour technicien superieur en réseaux et télécommunication
Curriculum vitae pour technicien superieur en réseaux et télécommunication
 
Installation ubuntu 14.04
Installation ubuntu 14.04Installation ubuntu 14.04
Installation ubuntu 14.04
 
Qu’est ce qu’un xG ?
Qu’est ce qu’un xG ?Qu’est ce qu’un xG ?
Qu’est ce qu’un xG ?
 
Digital Subscriber Line - Ligne numérique d’abonné
Digital Subscriber Line - Ligne numérique d’abonnéDigital Subscriber Line - Ligne numérique d’abonné
Digital Subscriber Line - Ligne numérique d’abonné
 
Installation du Network Simulator 2
Installation du Network Simulator 2Installation du Network Simulator 2
Installation du Network Simulator 2
 
Logiciel libre de simulation a événement discret
Logiciel libre de simulation a événement discret Logiciel libre de simulation a événement discret
Logiciel libre de simulation a événement discret
 
Mise à niveau d’un Data Center VoIP de CUCM 7.0 à CUCM 9.0
Mise à niveau d’un Data Center VoIP de CUCM 7.0 à CUCM 9.0 Mise à niveau d’un Data Center VoIP de CUCM 7.0 à CUCM 9.0
Mise à niveau d’un Data Center VoIP de CUCM 7.0 à CUCM 9.0
 
Mise à niveau d’un Data Center VoIP de CUCM 7.0 à CUCM 9.0
Mise à niveau d’un Data Center VoIP de CUCM 7.0 à CUCM 9.0 Mise à niveau d’un Data Center VoIP de CUCM 7.0 à CUCM 9.0
Mise à niveau d’un Data Center VoIP de CUCM 7.0 à CUCM 9.0
 

Mécanisme de gestion de la file d'attente

  • 1. Atelier Logiciel Libre Mécanisme de gestion de la file d'attente TRT3 TD2 TP3 | Nouri Anis Ministère de l’Enseignement Supérieur et de la Recherche Scientifique Faculté des Sciences dz Bizerte Département de l’Informatique
  • 2. 1 Sommaire I. INTRODUCTION .........................................................................................................................................................2 a) Verrouillage................................................................................................................................................... 2 b) Files d'attente pleines................................................................................................................................... 2 II. EXEMPLE DE FILE D’ATTENTE .................................................................................................................................3 II.1 RED RANDOM EARLYDETECTION...........................................................................................................................3 II.2 DROP TAILEN........................................................................................................................................................4 II.3 TBF TOKEN BUKETFILTER......................................................................................................................................5 III. CONCLUSION ........................................................................................................................................................8 a) Réduire le nombre de paquets abandonnés dans les routeurs ................................................................... 8 b) Fournirun service interactif à plus faible délai ............................................................................................ 8 c) Éviter le comportement de verrouillage ...................................................................................................... 8
  • 3. 2 I. Introduction La théorie des files d’attente consiste en l’étude de systèmes ou des clients se présentent à un dispositif de service, appelé serveur. Puisqu’un client occupe le serveur pendant un certain temps, les autres clients doivent attendre avant d’être servis, formant ainsi une file d’attente. Quelques exemples d’application :  Réseaux informatiques : serveur = routeur, client = paquet.  Ateliers (job shop) : serveur = machine, client = tâche. En ingénierie, On s’intéresse à des métriques de performance des files d’attente, par exemple :  Taille moyenne de la file d’attente.  Taux d’utilisation du serveur.  Temps moyen d’attente d’un client  Le besoin d'une gestion active de file d'attente La technique traditionnelle pour la gestion des longueurs de file d'attente chez un routeur est d'établir une longueur maximum (en termes de paquets) pour chaque file d'attente, d'accepter ces paquets pour la file d'attente jusque à ce que la longueur maximum soit atteinte, puis de rejeter (abandonner) les paquets entrants suivants jusque à ce que la file d'attente diminue à cause de la transmission d'un paquet de la file d'attente. Cette technique est connue sous le nom de "abandon du bout de la queue" (tail drop), car le paquet arrivé le plus récemment (c'est-à-dire, celui qui est au bout de la queue) est abandonné lorsque la file d'attente est pleine. Cette méthode a bien servi l'Internet pendant des années, mais elle présente deux inconvénients importants. a) Verrouillage Dans certaines situations, l'exclusion du bout de la queue permet à une seule connexion ou à quelques flux de monopoliser l'espace de file d'attente, empêchant ainsi les autres connexions d'obtenir de l'espace dans la file d'attente. Ce phénomène de "verrouillage" est souvent le résultat d'effets de synchronisation ou autres effets temporels. b) Files d'attente pleines La discipline de l'abandon du bout de la queue permet aux files d'attente de conserver un statut de file d'attente complète (ou presque complète) pendant de longues périodes car l'abandon du bout de la queue ne signale l'encombrement (via un abandon de paquet) que si la file d'attente est devenue pleine. Il est important de réduire la taille de la file d'attente en régime permanent, et c'est peut-être l'objectif le plus important de la gestion de file d'attente. L'objet de la mise en mémoire tampon sur le réseau est d'absorber les salves de données et de les transmettre durant les salves de silence qui (on l'espère) vont suivre. Cela est essentiel pour permettre la transmission de salves de données. La raison pour laquelle on veut avoir des files d'attente normalement petites dans les routeurs devrait être claire : on veut avoir la capacité de file d'attente pour absorber les salves. Le résultat contraire à l'intuition est que d'entretenir des files d'attente normalement petites peut déboucher sur un débit supérieur ainsi que sur un plus petit délai de bout en bout. En bref, les limites des files d'attente ne devraient
  • 4. 3 pas refléter les files d'attente d'état permanent qu'on veut conserver dans le réseau ; elles devraient plutôt refléter la taille des salves qu'on a besoin d'absorber. II. Exemple de file d’attente II.1 RED random early detection Le comportement normal des files d'attente de routeurs est appelé "tail-drop" (NdT : élimine le reste). Le "tail-drop" consiste à mettre en file d'attente un certain volume de trafic et à éliminer tout ce qui déborde. Ce n'est pas du tout équitable et cela conduit à des retransmissions de synchronisation. Quand une retransmission de synchronisation a lieu, la brusque rafale de rejet d'un routeur qui a atteint sa limite entraînera une rafale de retransmissions retardée qui inondera à nouveau le routeur congestionné. Dans le but d'en finir avec les congestions occasionnelles des liens, les routeurs de dorsales intègrent souvent des files d'attente de grande taille. Malheureusement, bien que ces files d'attente offrent un bon débit, elles peuvent augmenter sensiblement les temps de latence et entraîner un comportement très saccadé des connexions TCP pendant la congestion. Ces problèmes avec le "tail-drop" deviennent de plus en plus préoccupants avec l'augmentation de l'utilisation d'applications hostiles au réseau. Le noyau Linux nous offre la technique RED, abréviation de Random Early Detect ou détection précoce directe. RED n'est pas la solution miracle à tous ces problèmes. Les applications qui n'intègrent pas correctement la technique de "l'exponentiel back off" obtiennent toujours une part trop grande de bande passante. Cependant, avec la technique RED elles ne provoquent pas trop de dégâts sur le débit et les temps de latence des autres connexions. RED élimine statistiquement des paquets du flux avant qu'il n'atteigne sa limite "dure" (hard). Sur une dorsale congestionnée, cela entraîne un ralentissement en douceur de la liaison et évite les retransmissions de synchronisation. La technique RED aide aussi TCP à trouver une vitesse "équitable" plus rapidement : en permettant d'éliminer des paquets plus tôt, il conserve une file d'attente plus courte et des temps de latence mieux contrôlés. La probabilité qu'un paquet soit éliminé d'une connexion particulière est proportionnelle à la bande passante utilisée par cette connexion plutôt qu'au nombre de paquets qu'elle envoie. La technique RED est une bonne gestion de file d'attente pour les dorsales, où vous ne pouvez pas vous permettre le coût d'une mémorisation d'état par session qui est nécessaire pour une mise en file d'attente vraiment équitable. Pour utiliser RED, vous devez régler trois paramètres : Min, Max et burst. Min est la taille minimum de la file d'attente en octets avant que les rejets n'aient lieu, Max est le maximum "doux" (soft) en dessous duquel l'algorithme s'efforcera de rester, et burst est le nombre maximum de paquets envoyés "en rafale". Vous devriez configurer Min en calculant le plus grand temps de latence acceptable pour la mise en file d'attente, multiplié par votre bande passante. Par exemple, sur mon lien ISDN à 64 Kbits/s, je voudrais avoir un temps de latence de base de mise en file d'attente de 200 ms. Je configure donc Min à 1600 octets (= 0,2 x 64000 / 8). Imposer une valeur Min trop petite va dégrader le débit et une valeur Min trop grande va dégrader le temps de latence. Sur une
  • 5. 4 liaison lente, choisir un coefficient Min petit ne peut pas remplacer une réduction du MTU pour améliorer les temps de réponse. Vous devriez configurer Max à au moins deux fois Min pour éviter les synchronisations. Sur des liens lents avec de petites valeurs de Min, il peut être prudent d'avoir Max quatre fois plus grand que Min ou plus. Burst contrôle la réponse de l'algorithme RED aux rafales. Burst doit être choisi plus grand que min/avpkt (paquet moyen). Expérimentalement, j'ai trouvé que (min+min+max)/(3*avpkt) marche bien. De plus, vous devez configurer limit et avpkt. Limit est une valeur de sécurité : s'il y a plus de Limit octets dans la file, RED reprend la technique "tail-drop". Je choisis une valeur typique égale à 8 fois Max. Avpkt devrait être fixé à la taille moyenne d'un paquet. 1000 fonctionne correctement sur des liaisons Internet haut débit ayant un MTU de 1500 octets. II.2 drop tailen Le comportement le plus utilisé pour la gestion des files d’attente des routeurs sur Internet est appelé Drop Tail ou Tail Drop (traduction : « élimine le reste »). La politique Drop Tail consiste `a mettre en file d’attente les paquets qui arrivent, et à rejeter tous les paquets quand la taille de la file d’attente dépasse la taille du tampon. La probabilité de rejet assez simple de Drop Tail d(k) est donnée par l’équation suivante : d(k) = {0 si k ≤ K 1 si k>K où k est la taille de la file d’attente et K la taille du tampon. Cela conduit `à des phénomènes de retransmissions de synchronisation pour les flux TCP par exemple. Quand une retransmission de synchronisation a lieu, la brusque rafale de rejets d’un routeur qui a atteint sa limite entraınera une rafale de retransmissions retardée qui inondera nouveau le routeur congestionné. Dans le but de régler les problèmes de congestion due `a des rafales de paquets, les routeurs intègrent souvent des files d’attente de grande taille. Malheureusement, bien que ces files d’attente 1.3. La gestion classique des files d’attente offrent un bon débit, elles peuvent augmenter sensiblement les temps de latence et entraıner un comportement très saccadé des connexions TCP pendant la congestion. Les files Drop Tail sont monopolisées par certains types de flux et empêchent ainsi les autres transmissions de trouver une place dans la file. C’est le problème du lock-out de Drop Tail : tous les flux n’ont pas la même chance d’entrer dans la file d’attente. Les problèmes avec DropTail deviennent de plus en plus préoccupants avec l’augmentation de l’utilisation d’applications« hostiles »au réseau comme les applications de diffusion vidéo. Il existe plusieurs autres techniques, côté routeur, pour obtenir une utilisation optimale des ressources et/ou adapter les applications aux conditions dynamiques du réseau.
  • 6. 5 II.3 TBF token buket filter Le Token Bucket Filter (TBF) est un gestionnaire de mise en file d'attente simple. Il ne fait que laisser passer les paquets entrants avec un débit n'excédant pas une limite fixée administrativement. L'envoi de courtes rafales de données avec un débit dépassant cette limite est cependant possible. TBF est très précis, et peu gourmand du point de vue réseau et processeur. Considérez-le en premier si vous voulez simplement ralentir une interface ! L'implémentation TBF consiste en un tampon (seau), constamment rempli par des éléments virtuels d'information appelés jetons, avec un débit spécifique (débit de jeton). Le paramètre le plus important du tampon est sa taille, qui correspond au nombre de jetons qu'il peut stocker. Chaque jeton entrant laisse sortir un paquet de données de la file d'attente de données et ce jeton est alors supprimé du seau. L'association de cet algorithme avec les deux flux de jetons et de données, nous conduit à trois scénarios possibles : Les données arrivent dans TBF avec un débit EGAL au débit des jetons entrants. Dans ce cas, chaque paquet entrant a son jeton correspondant et passe la file d'attente sans délai. Les données arrivent dans TBF avec un débit PLUS PETIT que le débit des jetons. Seule une partie des jetons est supprimée au moment où les paquets de données sortent de la file d'attente, de sorte que les jetons s'accumulent jusqu'à atteindre la taille du tampon. Les jetons libres peuvent être utilisés pour envoyer des données avec un débit supérieur au débit des jetons standard, si de courtes rafales de données arrivent. Les données arrivent dans TBF avec un débit PLUS GRAND que le débit des jetons. Ceci signifie que le seau sera bientôt dépourvu de jetons, ce qui provoque l'arrêt de TBF pendant un moment. Ceci s'appelle << une situation de dépassement de limite >> (overlimit situation). Si les paquets continuent à arriver, ils commenceront à être éliminés. Le dernier scénario est très important, car il autorise la mise en forme administrative de la bande passante disponible pour les données traversant le filtre. L'accumulation de jetons autorise l'émission de courtes rafales de données sans perte en situation de dépassement de limite, mais toute surcharge prolongée causera systématiquement le retard des paquets, puis leur rejet. Notez que, dans l'implémentation réelle, les jetons correspondent à des octets, et non des paquets.  Paramètres & usage Même si vous n'aurez probablement pas besoin de les changer, TBF a des paramètres. D'abord, ceux toujours disponibles sont :  limit or latency Limit est le nombre d'octets qui peuvent être mis en file d'attente en attendant la disponibilité de jetons. Vous pouvez également indiquer ceci d'une autre manière en
  • 7. 6 configurant le paramètre latency, qui spécifie le temps maximal pendant lequel un paquet peut rester dans TBF. Ce dernier paramètre prend en compte la taille du seau, le débit, et s'il est configuré, le débit de crête (peakrate).  burst/buffer/maxburst Taille du seau, en octets. C'est la quantité maximale, en octets, de jetons dont on disposera simultanément. En général, plus les débits de mise en forme sont importants, plus le tampon doit être grand. Pour 10 Mbit/s sur plateforme Intel, vous avez besoin d'un tampon d'au moins 10 kilo-octets si vous voulez atteindre la limitation configurée ! Si votre tampon est trop petit, les paquets pourront être rejetés car il arrive plus de jetons par top d'horloge que ne peut en contenir le tampon.  mpu Un paquet de taille nulle n'utilise pas une bande passante nulle. Pour ethernet, la taille minimale d'un paquet est de 64 octets. L'Unité Minimale de Paquet (Minimun Packet Unit) détermine le nombre minimal de jetons à utiliser pour un paquet.  rate Le paramètre de la vitesse. Voir les remarques au-dessus à propos des limites ! Si le seau contient des jetons et qu'il est autorisé à se vider, alors il le fait par défaut avec une vitesse infinie. Si ceci vous semble inacceptable, utilisez les paramètres suivants :  peakrate Si des jetons sont disponibles et que des paquets arrivent, ils sont immédiatement envoyés par défaut ; et pour ainsi dire à << la vitesse de la lumière >>. Cela peut ne pas vous convenir, spécialement si vous avez un grand seau. Le débit de crête (peak rate) peut être utilisé pour spécifier la vitesse à laquelle le seau est autorisé à se vider. Si tout se passe comme écrit dans les livres, ceci est réalisé en libérant un paquet, puis en attendant suffisamment longtemps, pour libérer le paquet suivant. Le temps d'attente est calculé de manière à obtenir un débit égal au débit de crête. Cependant, étant donné que la résolution du minuteur (timer) d'UNIX est de 10 ms et que les paquets ont une taille moyenne de 10 000 bits, nous sommes limités à un débit de crête de 1mbit/s !  mtu/minburst Le débit de crête de 1Mb/s ne sert pas à grand chose si votre débit habituel est supérieur à cette valeur. Un débit de crête plus élevé peut être atteint en émettant davantage de paquets par top du minuteur, ce qui a pour effet de créer un second seau. Ce second bucket ne prend par défaut qu'un seul paquet, et n'est donc en aucun cas un seau. Pour calculer le débit de crête maximum, multipliez le mtu que vous avez configuré par 100 (ou plus exactement par HZ, qui est égal à 100 sur Intel et à 1024 sur Alpha).  Configuration simple
  • 8. 7 Voici une configuration simple, mais très utile : # tc qdisc add dev ppp0 root tbf rate 220kbit latency 50ms burst 1540 Pourquoi est-ce utile ? Si vous avez un périphérique réseau avec une grande file d'attente, comme un modem DSL ou un modem câble, et que le dialogue se fasse à travers une interface rapide, comme une interface ethernet, vous observerez que télécharger vers l'amont (uploading) dégrade complètement l'interactivité. [NdT : uploading désigne une opération qui consiste à transférer des données ou des programmes stockés dans un ordinateur local vers un ordinateur distant à travers un réseau. La traduction officielle pour ce terme est << téléchargement vers l'amont >>. On parle alors de voie montante. Le downloading désigne l'opération inverse (transfert d'un hôte distant vers l'ordinateur local) et est traduit par << téléchargement >> ou << téléchargement vers l'aval >>. On parle alors de la voie descendante.] Le téléchargement vers l'amont va en effet remplir la file d'attente du modem. Celle-ci est probablement ENORME car cela aide vraiment à obtenir de bon débit de téléchargement vers l'amont. Cependant, ceci n'est pas forcément ce que voulez. Vous ne voulez pas forcément avoir une file d'attente importante de manière à garder l'interactivité et pouvoir encore faire des choses pendant que vous envoyez des données. La ligne de commande au-dessus ralentit l'envoi de données à un débit qui ne conduit pas à une mise en file d'attente dans le modem. La file d'attente réside dans le noyau Linux, où nous pouvons lui imposer une taille limite. Modifier la valeur 220kbit avec votre vitesse de lien REELLE moins un petit pourcentage. Si vous avez un modem vraiment rapide, augmenter un peu le paramètre burst.
  • 9. 8 III. Conclusion En résumé, un mécanisme de gestion active de file d'attente peut fournir les avantages suivants pour les flux qui "répondent". a) Réduire le nombre de paquets abandonnés dans les routeurs Les salves de paquet sont un aspect inévitable des réseaux par paquet [Willinger95]. Si tout l'espace de file d'attente dans un routeur est déjà affecté au trafic "d'état permanent" ou si l'espace de mémoire tampon est inadéquat, le routeur n'aura alors aucune capacité pour mettre les salves en mémoire tampon. En maintenant petite la taille moyenne de file d'attente, la gestion active de file d'attente donne une plus grande capacité d'absorption des salves qui surviennent naturellement sans abandonner de paquets. De plus, sans une gestion active de file d'attente, plus de paquets seront abandonnés lorsqu’une file d'attente déborde. Cela n'est pas souhaitable pour plusieurs raisons. Tout d'abord, avec une file d'attente partagée et la discipline d'abandon du bout de la file d'attente, une synchronisation globale inutile du ralentissement des flux peut résulter en une diminution de l'utilisation moyenne de la liaison, et donc en une diminution du débit du réseau. Ensuite, TCP récupère plus difficilement d'une salve d'abandons de paquets que de l'abandon d'un seul paquet. Troisièmement, des abandons inutiles de paquet représentent un gâchis possible de bande passante sur le chemin vers le point d'abandon. b) Fournir un service interactif à plus faible délai En conservant petite la taille moyenne de la file d'attente, la gestion de file d'attente va réduire les délais subis par les flux. Ceci est particulièrement important pour les applications interactives telles que les courts transferts sur la Toile, le trafic Telnet, ou les sessions audio- vidéo interactives, dont les performances subjectives (et objectives) sont meilleures lorsque le délai de bout en bout est faible. c) Éviter le comportement de verrouillage La gestion active de file d'attente peut empêcher le comportement de verrouillage en s'assurant qu'il y aura presque toujours une mémoire tampon disponible pour un paquet entrant. Pour la même raison, la gestion active de file d'attente peut empêcher un biais du routeur à l'encontre des flux à faible bande passante mais très saccadés. Il est clair que le verrouillage est indésirable parce qu'il constitue une injustice criante entre les groupes de flux. Cependant, on ne va pas appeler cet avantage "égalité accrue", parce que l'égalité parfaite entre les flux nécessite un état par flux, ce qui n'est pas fourni par la gestion de file d'attente. Par exemple, dans un routeur qui utilise la gestion de file d'attente mais seulement la programmation FIFO, deux flux TCP peuvent recevoir des bandes passantes très différentes simplement parce qu’ils ont des délais d'aller-retour différents [Floyd91], et un flux qui n'utilise pas le contrôle d'encombrement reçoit plus de bande passante qu'un flux qui
  • 10. 9 l'utilise. L'état flux par flux pour réaliser l'égalité parfaite pourrait être entretenu par un algorithme de programmation flux par flux tel que la mise en file d'attente équitable (FQ, Fair Queueing) [Demers90], ou un algorithme de programmation fondé sur la classe tel que CBQ [Floyd95], par exemple. D'un autre côté, la gestion active de file d'attente est nécessaire même pour les routeurs qui utilisent des algorithmes de programmation flux par flux tels que FQ ou des algorithmes de programmation fondés sur la classe tels que CBQ. La raison en est que par eux-mêmes les algorithmes de programmation flux par flux ne font rien pour contrôler la taille globale de file d'attente des queues individuelles. La gestion active de file d'attente est nécessaire pour contrôler les tailles moyennes globales de file d'attente, de telle sorte que les salves arrivantes puissent être traitées sans abandon de paquet. De plus, la gestion active de file d'attente devrait être utilisée pour contrôler la taille de la file d'attente pour chaque flux ou classe individuel, de façon à ce qu'ils ne subissent pas de forts retards inutiles. Donc, la gestion active de file d'attente devrait être appliquée entre classes ou flux aussi bien qu'au sein de chaque classe ou flux.