Transcript TP Réseaux matières approfondies RED et WRED

Facultés Universitaires Notre-Dame de la Paix
Institut d’informatique
TP Réseaux matières approfondies
RED et WRED
Travail réalisé par
Arnaud André
Xavier Dubois
Fabian Gilson
2e Maîtrise Info
Année académique 2003-2004
TABLE DES MATIÈRES
Introduction ________________________________________________________________ 3
Première partie : Rappel théorique ______________________________________________ 4
1. RED________________________________________________________________ 4
2. WRED ______________________________________________________________ 6
3. Avantages (pour les flux attentifs au contrôle de congestion) ___________________ 7
Réduction du nombre de paquets supprimés___________________________________ 7
Diminution des délais d’attente des paquets ___________________________________ 7
Eviter le « lock-out »_____________________________________________________ 7
4. Inconvénients ________________________________________________________ 7
Deuxième partie : La réimplémentation __________________________________________ 8
1. Le parcours d'un paquet IP dans le kernel Linux _____________________________ 8
2. iptables _____________________________________________________________ 9
3. le module QUEUE ___________________________________________________ 10
Troisième partie : tc_________________________________________________________ 11
1. Fonctionnement de tc _________________________________________________ 11
2. Commandes tc afin d’implémenter RED __________________________________ 12
3. Commandes tc afin d’implémenter le WRED ______________________________ 13
4. En pratique... ________________________________________________________ 13
Conclusion________________________________________________________________ 15
Références ________________________________________________________________ 16
2
INTRODUCTION
L’architecture de la pile protocolaire Internet repose sur le protocole IP, et une approche
Best Effort des communications en réseau. Ce protocole utilisé seul a cependant montré sa
faiblesse dans la gestion de la congestion, chaque hôte émettant sans se préoccuper de l’état
du réseau et donc en risquant de surcharger celui-ci, ce qui oblige les routeurs à supprimer
tous les paquets reçus lorsque leur file d’attente est pleine.
Pour éviter ce problème de « congestion collapse », Jacobson a développé le mécanisme
de « congestion avoidance » de TCP, qui diminue la vitesse de transmission des paquets par
l’expéditeur lorsque celui-ci détecte des pertes répétées[1].
RED (Random Early Detection) est une technique de gestion active des files d’attentes sur
un routeur. En résumé, cet algorithme permet de supprimer ou de marquer aléatoirement des
paquets dans un routeur, avec une probabilité augmentant avec la congestion de celui-ci. Il
garantit aussi que la file ne soit jamais pleine.
Cela permet d’éviter des phénomènes de « Lock-out » (une connexion monopolise
l’espace de la file d’attente au détriment des autres) et de files d’attente pleines. En effet, les
paquets arrivent souvent en rafale au routeur, ce qui cause leur suppression en rafale si son
buffer est plein. Il faut donc un mécanisme qui permet de garantir que la file d’attente ne sera
jamais remplie, afin de toujours pouvoir accepter et traiter une rafale de paquets.
RED et la « congestion avoidance » de TCP sont donc des mécanismes complémentaires
pour la gestion de la congestion sur un réseau.
Nous allons commencer par un bref rappel théorique du fonctionnement de l’algorithme
RED et de ses avantages. Ensuite, nous allons décrire notre tentative d’implémentation de
RED en dehors du noyau Linux et expliquer le fonctionnement de TC. Nous pourrons alors
enfin parler des configurations de test du générateur de trafic MGEN et de la paramétrisation
de TC.
3
PREMIÈRE PARTIE : RAPPEL THÉORIQUE
1. RED
Le RED[2][3], Random Early Detection, est un algorithme de gestion de files d’attentes.
Cependant, contrairement aux autres algorithmes de gestion de files, RED propose de
supprimer (ou marquer) des paquets arrivant dans la file d’attente avant que celle-ci ne
devienne pleine. RED utilise une valeur aléatoire entre 0 et une certaine probabilité de
suppression pour décider de jeter ou non le paquet. L’algorithme RED se divise en deux
partie : l’estimation de la taille moyenne de la file (avg) et la décision de supprimer ou pas un
paquet arrivant.
a) Estimation de la taille moyenne de la file d’attente
Normalement, l’estimation de la taille moyenne de la file devrait être effectuée à intervalle
régulier. En pratique, pour une question d’efficacité, l’estimation se fait par le calcul
d’une moyenne pondérée de la taille réelle de la file (avg) à l’arrivée de chaque nouveau
paquet. Le calcul de la taille moyenne de cette file doit prendre en compte le temps durant
lequel la file a été vide. De plus, cette valeur peut être calculée indifféremment en nombre
de paquets ou en bytes. Cette estimation détermine la taille des rafales de paquets (degree
of burstiness) que la file peut contenir.
b) Décision de supprimer ou pas le paquet
RED décide de jeter un paquet sortant avec une certaine probabilité. Pour cela, RED va
utiliser deux variables minth (minimum threshold) et maxth (maximum threshold) qui
représente un intervalle de taille pour la file. La décision de supprimer le paquet dépend
de la valeur de avg. Voici les trois cas de figure (voir figure 2 : algorithme RED) :
• minth <= avg < maxth :
L’algorithme calcule la probabilité de supprimer le paquet de façon linéaire de 0 à maxP
(probabilité maximale de dropper un paquet) en fonction de minth, maxth et avg. Ensuite,
un nombre aléatoire est tiré afin de décider si le paquet est jeté. Ce nombre aléatoire est
choisi, selon les méthodes, à l’arrivée de chaque paquet ou seulement quand un paquet est
supprimé.
• avg > maxth :
L’algorithme supprime le paquet.
• avg < minth :
L’algorithme accepte le paquet.
La figure 2 illustre très bien cet algorithme (la variable count y compte le nombre de
paquets qui ont été mis dans la file depuis que le dernier paquet ait été supprimé)[4].
Enfin, l’algorithme teste s’il reste des paquets dans la file, sinon, il démarre un timer
donnant le temps d’inactivité de la file.
4
Il a été montré de manière empirique qu’une gestion active de file d’attente sur le réseau
Internet (comme RED) permettait de grands gains de performance. Mais, malheureusement,
dans le cas où les paquets sont très petits, l’algorithme dégénère et le transfert ne se fera plus
au-delà d’un paquet par RTT (Round Trip Time).
Figure 1 – Graphique d’une simulation RED
La figure 1 nous montre l’évolution de la taille de la queue (en rouge) et de la taille
moyenne calculée par le RED (en vert) en fonction du temps. Notons que la taille de la queue
est en nombre de paquets et que le temps est en seconde.
Ce graphique nous montre que RED peut être vu comme un algorithme de gestion modebased. On voit clairement sur le graphique trois politiques différentes de gestion. En jaune,
RED met en file tous les paquets entrants, en rouge, il les supprime tous et en bleu, il les
supprime sur base d’une probabilité. Ces politiques sont en relation directe avec l’état de
congestion du réseau. Si la taille de la queue reste faible, le réseau est peu ou pas
congestionné, on ne droppe donc pas de paquets. Quand la taille de la file augmente, l’état de
congestion du réseau augmente, on droppe certains paquets. Enfin, quand une grosse rafale
(burst) se présente à l’entrée, le fait que la file n’est jamais entièrement remplie, une partie
(ou la totalité) des paquets peut être enfilée et traitée.
5
Figure 2 – algorithme RED
2. WRED
Le WRED (Weighted Random Early Detection) est une extension de l’algorithme RED
afin de promouvoir une politique avec plusieurs niveaux de priorité. Un routeur fonctionnant
en WRED doit posséder autant de files implémentées en RED que de niveaux de priorité
désirés. Chaque file s’occupe des paquets pour lesquels elle est désignée, chaque paquet se
trouve ainsi classé dans la file correspondante. On utilise fréquemment le champ TOS (Type
Of Service) du header IP pour classer les paquets. Chaque file étant elle-même gérée par un
module RED différent, avec des valeurs différentes de minth, maxth et maxP, chacune d’elle
permet une politique différente suivant la priorité du paquet.
6
3. AVANTAGES (POUR LES FLUX ATTENTIFS AU CONTRÔLE DE CONGESTION)
RÉDUCTION DU NOMBRE DE PAQUETS SUPPRIMÉS
Garder la taille de la file d’attente relativement basse permet d’augmenter la capacité
d’absorber les rafales sans supprimer de paquets. Cela permet donc de diminuer le gaspillage
de bande passante dû aux retransmissions de paquets. De plus, TCP se remet plus facilement
quand un seul paquet est supprimé que quand toute une rafale disparaît.
DIMINUTION DES DÉLAIS D’ATTENTE DES PAQUETS
En garantissant une petite taille de la file d’attente, RED diminue le délai moyen de
passage des paquets dans le routeur, ce qui diminue les délais de transmission des paquets
entre l’expéditeur et le destinataire (end-to-end delay). C’est particulièrement le cas pour
toutes les applications interactives en temps réel, comme les téléconférences et les jeux en
ligne.
EVITER LE « LOCK-OUT »
Il y a un phénomène de lock-out quand une connexion monopolise l’espace de la file
d’attente au détriment des autres.
Dans un système sans gestion active de la file d’attente, il est possible celle-ci soit remplie
par une rafale d’un flux A. Lorsqu’une rafale de B arrive, tous ses paquets sont alors
supprimés, étant donné qu’il n’y a plus de place pour les accueillir sur le routeur. RED permet
une plus grande équité dans le partage de la bande passante, étant donné qu’il y aura
normalement toujours assez de place pour accepter une rafale de B.
Cependant, pour garantir une vraie équité, il est nécessaire d’utiliser des mécanismes de
« scheduling » couplés à RED.
4. INCONVÉNIENTS
Il existe des expéditeurs qui ne régulent pas leur flux en fonction des indications de
congestion (paquet perdu ou marqué). Le fait de supprimer des paquets sur un routeur pousse
les expéditeurs de flux TCP à diminuer leur taux d’envoi pour ne pas saturer le réseau
(congestion avoidance), alors que les expéditeurs de flux UDP ne sont pas mis au courant de
la congestion. Ils continuent donc à saturer le réseau, occupant de plus en plus de bande
passante au détriment des connexions TCP en cours.
7
DEUXIEME PARTIE : LA REIMPLEMENTATION
Afin de pouvoir réimplémenter les fonctionnalités du RED et WRED, notre premier
objectif fut d'essayer de récupérer l'ensemble des paquets envoyés sur la file de sortie d'une
interface et de pouvoir décider de leur sort (drop ou queue). Nous avons donc étudié le
fonctionnement interne du kernel linux lors du passage d'un paquet. En connaissant son
chemin, on pourra mieux cerner les possibilités d'interfaçage avec le kernel pour implémenter
le RED.
1. LE PARCOURS D'UN PAQUET IP DANS LE KERNEL LINUX
Le parcours d'un paquet dans les entrailles du kernel Linux peut être résumé par le schéma
suivant [5] :
Figure 3 – Schéma du passage d’un paquet dans le kernel
8
Le paquet arrive en premier lieu dans la file d'entrée de l'interface réseau. Celui-ci est
ensuite transféré par le driver de l'interface dans la mémoire du kernel sous la forme d'une
structure sk_buff [6]. Cette dernière sera le contenant de l'information du paquet tout au long
de son voyage. Lorsque le kernel prend connaissance du paquet arrivé (grâce à un type
particulier d'interruption, une softirq), il appelle la fonction gérant le type du paquet (dans le
cas d'ipv4 : ip_rcv()) .
Juste après ip_rcv(), le paquet va passer à travers les « hooks » (accroches) de netfilter [7]
[8]. Ces accroches permettent à des modules kernel d'intercepter les paquets. Ils peuvent
ensuite les modifier et décider s'ils peuvent ou non continuer leur chemin. Au nombre de cinq,
ces points d'encrage sont répartis tout au long du chemin du paquet et sont représentés par un
HOOK dans le schéma.
Si le paquet passe les « hooks », la fonction ip_rcv_finish() est appelée. Elle vérifie si la
destination du paquet est locale, au quel cas elle appelle ip_local_delivery() pour traitement.
Sinon, elle appelle les fonctions de routage afin de savoir où le forwarder et appelle ensuite
ip_forward() afin que le paquet soit effectivement forwardé.
Finalement, le paquet arrive à la fonction dev_queue_xmit() qui l'ajoute à la file de sortie
de l'interface (q->enqueue()) et ensuite appelle le scheduler réseau (q->disc_run()). Lorsque
le scheduler le décide, il appelle hard_start_xmit() qui envoie le paquet à l'interface de sortie.
Des paquets locaux peuvent évidemment être aussi générés. Ceux-ci démarrent leur
voyage par la fonction ip_queue_xmit() et « rejoignent » à la fonction dev_queue_xmit()
l'ensemble des paquets en partance.
Les paquets subissent de nombreuses vérifications et modifications tout au long des appels
de fonctions :
- la forme des paquets est testée pour voir s’ils correspondent au protocole;
- le TTL est décrémenté et vérifié;
- un module de NAT peut modifier l'ip source/destination;
- le scheduler peut modifier le bit ECN;
- ...
2. IPTABLES
La solution la plus évidente serait de passer par ces hooks afin de capturer les paquets. Ces
accroches sont principalement utilisées par l'utilitaire 'iptables'. Celui-ci permet de configurer,
en user space (niveau de privilège hors kernel), les modules kernel. Ces derniers varient du
simple module qui rejette tous les paquets, au module qui réalise les opérations nécessaires à
l'établissement d'un NAT. Iptables permet de définir quels sont les modules accrochés à
chaque hook, de paramétrer ces modules si nécessaire et de définir à quels paquets ils seront
appliqués.
9
Exemple : iptables -I PREROUTING -i eth0 -s 138.48.0.0/16 -j DROP
Cette dernière ligne attache un module de type « DROP » au hook de PREROUTING
(correspondant à celui après ip_rcv()) qui sera uniquement traversé par les paquets venant de
l'interface eth0 et dont l'adresse source est de type 138.48.x.x.
3. LE MODULE QUEUE
Dans l'ensemble des modules qu'iptables propose, nous en avons retenu un qui correspond
exactement aux besoins que nous avions spécifiés : le module « QUEUE ». Ce module, aussi
appelé ip_queue, permet d'envoyer les paquets à des applications user space qui s'inscrivent et
qui attend de leur part un verdict sur le futur du paquet (accept ou drop). En ajoutant, grâce à
tc, un module ip_queue au hook de POSTROUTING d'une interface, nous avons les bases
pour implémenter le RED.
Afin de pouvoir récupérer les informations sur les paquets reçus par le module
« QUEUE » et de pouvoir lui répondre, nous avons besoin d'un moyen de communication
entre le user space et le kernel. Ce moyen est fourni par un socket spécial, le socket netlink.
Nous verrons dans la seconde partie comment il fonctionne et sa multitude d'utilités.
Dans le cas d'ip_queue, nous n'avons pas besoin d'utiliser directement un socket netlink.
La librairie « libipq » propose des fonctions aidant à communiquer directement avec ip_queue
[9]. Libipq permet de récupérer un handle (ipq_create_handle()) afin de pouvoir lire toute
information transitant par le module (ipq_read()) . Il permet de plus de renvoyer au module le
verdict sur un paquet (ipq_set_verdict()) .
Nous avons donc maintenant un moyen de récupérer l'ensemble des paquets sortant sur
une interface et un moyen de les jeter si nécessaire. Malheureusement, nous avons besoin de
connaître une information supplémentaire : la taille de la file de sortie.
Après avoir retourné toute la documentation que nous avons pu trouver, nous n'avons pas
pu déterminer comment la récupérer. Aussi bien les fichiers d'informations de /proc/net/* que
l'API mise à notre disposition par le kernel (comme la fonction ioctl() qui permet de contrôler
les périphériques [10]) ne permettent pas d'avoir cette information. Cette variable n'est
accessible que dans le kernel. Il nous aurait donc fallu réimplémenter RED par un module
kernel. Nous avons décidé que, vu qu'il existe déjà un module kernel réalisant le RED, nous
n'allions pas le reprogrammer. En effet, cela se réduirait à faire un copier/coller du module
déjà existant.
Nous nous sommes donc recentrés sur le module kernel RED et la commande qui permet
de le configurer (tc).
10
TROISIEME PARTIE : TC
1. FONCTIONNEMENT DE TC
Tc est l'utilitaire qui permet de configurer le Forwarding Engine (FE) de Linux. Celui-ci
est composé d'un Traffic Control (TC) en entrée, du module de forwarding et finalement du
TC de sortie [11]. Ce dernier est responsable du queueing de sortie et du scheduling.
Le FE fait évidemment partie du kernel et tc est un utilitaire en user space. Tc doit donc
discuter d'une certaine manière avec le kernel afin de configurer le FE. Cette discussion est
réalisée grâce au socket netlink, mentionné plus haut dans ce document.
Netlink est un protocole d'interaction entre des composants de contrôle (Control Plane
Component, CPC) et des composants du FE (Forwarding Engine Component, FEC), les
CPCs se trouvant en user space et les FEC dans le kernel. Ce protocole est défini par la rfc
3549. Il permet, entre autres, la configuration des interfaces réseaux, des tables de routage et
des TCs. Un exemple d'application est le daemon ospfd qui réalise les modifications de la
table de routage selon le protocole ospf.
Nous ne nous intéresserons pas aux tables de routage, mais bien au TC de sortie. Celui-ci
peut être configuré de manière très flexible. Le TC de sortie peut être modelé de façon
hiérarchique à partir de trois types de blocs :
• les queuing disciplines( qdisc ) qui correspondent aux algorithmes de scheduling et
de gestion de files
• les classes qui permettent de différentiés différents type de flux de paquets
• les filtres qui permettent de classer les paquets dans différentes classes
Par exemple, le TC peut ressembler à la structure suivante :
Filtre1
Classe1
Qdisc1
Filtre2
Classe2
Qdisc2
dev
Filtre3
Figure 4 - Structure
générale du tc
Qdisc parent( attaché à l’interface )
11
Le module kernel RED fait partie des qdiscs du TC. Il « suffit » donc d’attacher le qdisc
RED à l’interface grâce à tc. Pour le WRED, les filtres sont tout indiqués afin de diriger les
paquets vers différents « types » de RED.
2. COMMANDES TC AFIN D’IMPLEMENTER RED
La commande suivante permet d’attacher un RED à une interface réseau [12] [13] [14]:
tc qdisc add dev ethx root red limit <bytes> min <bytes> max <bytes> avpkt
<bytes> burst <packets> [ ecn ] [ bandwidth <rate> ] probability <chance>
qdisc add
dev ethx
root
red
max <bytes>
Demande à tc d’ajouter un qdisc
La commande est définie pour l’interface ethx
Demande d’ajouter le qdisc sur l’interface directement (qdisc parent)
Le qdisc est de type RED
Définit le max threshold (maxth) en bytes. Il peut être calculé comme suit:
max = <bande passante (bytes / sec)> * <temps de latence maximum (sec)>
min <bytes>
Définit le min threshold (minth) en bytes.
Selon Floyd & Jacobson, un min optimal serait de :
min ~ max / 3
burst
Les recommandations de la man page sont :
<packets>
burst = (2 * min + max) / (3 * avpkt)
limit <bytes> Taille réelle de la file d’attente en bytes. Cette taille ne doit jamais être atteinte,
et donc limit est supérieur à max + burst.
En general limit = x * max
Avec par exemple x = 8.
probability
Probabilité maximale de supprimer un paquet (maxP)
<chance>
Floyd & Jacobson recommandent probability = 0.02
bandwidth
Bande passante de l’interface Ethernet concernée en bytes/seconde. Peut être
<rate>
omis, dans quel cas, la bande passante est définie à 10Mbit/seconde.
avpkt <bytes> Est la taille moyenne des paquets reçus (en bytes).
avpkt = 1000 est une bonne valeur pour ethernet
ecn
Explicit Congestion Notification. Si cette option est spécifiée, les paquets ne sont
pas supprimés mais leur flag « ECN » est mis à 1. Les hôtes qui supportent
l’ECN sont alors directement mis au courant de la congestion.
12
3. COMMANDES TC AFIN D’IMPLÉMENTER LE WRED
Le WRED demande une configuration un peu plus complexe. Nous devons d’abord
passer par un qdisc de type « PRIO » [15]. Ce qdisc de scheduling permet de créer une série
de classes prêtes à l’emploi, appelées « bandes ».
tc qdisc add dev
band,band,band...]
ethx
root handle 1:
prio [ bands <bands> ] [ priomap
Cette opération crée un qdisc prio attaché directement à l’interface ethx avec un nombre
<bands> de classes. Si ce nombre n’est pas spécifié, trois classes sont créées par défaut. La
priomap permet une répartition des paquets dans les différentes classes selon leur champ
TOS. Elle n’est pas nécessaire lorsque des filtres sont attachés au qdisc prio. Le handle
permet d’identifier le qdisc. Les classes créées ont un handle assigné automatiquement de
1:1, 1:2, 1:3, …, 1:<bands>.
On attache ensuite un RED à chacune des classes par une commande équivalente au point
précédent sauf que « root » est remplacé par « parent 1:x » où x est la xième classe.
Enfin, on crée une série de filtres qui dirigent les paquets vers la classe correspondante
selon le TOS des paquets:
tc filter add dev ethx parent 1: protocol ip prio 1 u32 match ip tos 0x10 0xff flowid 1:1
Cette dernière commande crée un filtre attaché au prio (parent 1:). Le filtre accepte tout
paquet ip (protocol ip) dont le tos vaut 0x10 (match ip tos 0x10 0xff) et l’envoie vers la classe
1:1 (flowid 1:1).
L’ensemble de ces blocs permet de créer un WRED.
4. EN PRATIQUE...
Le script utilisé pour configurer un système RED simple sur une interface 100Mbit d’un
routeur avec tc est le suivant:
# !/bin/bash
#
#maximum latency = 0.01 sec -> max = 12.5 (MB/s) * 0.01 = 128KB
#min = max /2 ou /3, nous on prend /2 => min = 64KB
#limit = x * max => on prend 4 => limit = 512KB
#avgpkt = taille moyenne d'un packet => avgpkt = 1000
#burst = (2 * min + max ) / (3* avgpkt ) => burst = 90
tc qdisc add dev eth1 root red limit 512KB min 64KB max 128KB burst 90 avpkt 1000
bandwidth 100Mbit probability 0.02
13
Ce script a ensuite évolué pour permettre l'utilisation et la configuration d'un système
WRED.
# !/bin/bash
#
tc qdisc add dev eth1 root handle 1: prio
#max latency = 0.01 sec
tc qdisc add dev eth1 parent 1:1 handle 10: red limit 512KB min 64KB max 128KB burst 90
avpkt 1000 bandwidth 1Mbit probability 0.02
#max latency = 0.02 sec
tc qdisc add dev eth1 parent 1:2 handle 20: red limit 1024KB min 128KB max 256KB burst
170 avpkt 1000 bandwidth 100Mbit probability 0.04
tc filter add dev eth1 parent 1: protocol ip prio 1 u32 match ip tos 0x10 0xff flowid 1:1
tc filter add dev eth1 parent 1: protocol ip prio 2 u32 match ip tos 0x08 0xff flowid 1:2
Nous avons ensuite utilisé le générateur de trafic MGEN pour essayer de saturer le routeur
configuré pour RED. MGEN permet d'envoyer des paquets de taille définie à une fréquence
décidée par l'utilisateur. Il est aussi possible d'envoyer des paquets en rafale (burst).
Voici le script utilisé (par « mgen input nom_du_script ») :
0.0 ON 1 UDP DST 10.0.3.2/5000 TOS 0x10 POISSON [100.0 1000]
0.0 ON 2 UDP DST 10.0.3.2/5001 TOS 0x10 PERIODIC [100.0 1000]
1.0 OFF 1
1.0 OFF 2
Nous n'avons malheureusement pas pu retirer de traces réseau ni de confirmation explicite
du bon fonctionnement de RED. En effet, il nous est apparu fort tard que certaines des
liaisons entre les machines du labo étaient en 10Mbps et d'autres en 100Mbps. Lorsque nous
avons tenté d'obliger RED à dropper des paquets, nous avons malencontreusement essayé de
surcharger une ligne 100Mbps avec deux lignes 10Mps. Le module RED n'a donc pas droppé
de paquet. Cependant, la commande
tc -s -d qdisc ls
a pu nous confirmer que les paquets transmis transitaient bien par le module RED. Nous en
déduisons que celui-ci est installé et configuré correctement par le script.
14
CONCLUSION
RED est un mécanisme qui permet de contenir la congestion du réseau dans des
proportions raisonnables. Cependant, RED n’est vraiment efficace que dans le cas où le
protocole utilisé est sensible à la congestion du réseau (par exemple TCP avec son principe de
congestion avoidance).
Nous avons pu nous rendre compte personnellement de la difficulté d’implémenter RED
en user space, sans les struct du noyau. Il est en effet impossible de connaître facilement la
taille réelle de la file de sortie d’une interface, ni la durée durant laquelle celle-ci est vide, tous
deux nécessaires pour le calcul de la taille moyenne pondérée de la queue.
Nous nous sommes finalement tournés vers tc pour configurer le module RED du noyau
linux. C’est à partir de ce premier script que nous avons pu configurer un WRED, en s’aidant
de filtres pour distinguer les différents TOS (Type Of Service) des paquets.
15
RÉFÉRENCES
[1] Network Working Group, “TCP Slow Start, Congestion Avoidance, Fast Retransmit, and
Fast Recovery Algorithms”, http://www.ietf.org/rfc/rfc2001.txt
[2] Network working group, « Recommendations on Queue Management and Congestion
Avoidance in the Internet », http://www.ietf.org/rfc/rfc2309.txt (RFC 2309)
[3] Floyd, S., and Jacobson, V., « Random Early Detection gateways
for Congestion Avoidance », http://ftp.ee.lbl.gov/floyd/red.html
[4] Leonardo Balliache, « Differentiated Service on Linux HOWTO »,
http://www.opalsoft.net/qos/DS.htm
[5] M. Rio, M. Goutelle, T. Kelly, R. Hughes-Jones, J.P. Martin-Flatin and Y.T. Li, “A Map
of the Networking Code in Linux Kernel 2.4.20”, http://datatag.web.cern.ch/datatag/papers/trdatatag-2004-1.pdf
[6] Harald Welte, « skb - Linux network buffers », http://gnumonks.org/ftp/pub/doc/skbdoc.html
[7] « netfilter homepage », http://www.netfilter.org/
[8] Rusty Russell and Harald Welte, « Linux netfilter hacking how-to »,
http://www.netfilter.org/documentation/HOWTO//netfilter-hacking-HOWTO.html
[9] James Morris, « Libipq man page », http://www.cs.princeton.edu/~nakao/libipq.htm
[10] « ioctl man page », http://www.doc.ic.ac.uk/lab/labman/lookup-man.cgi?ioctl(2)
[11] Network working group, « Linux netlink as an IP services Protocol »,
http://www.ietf.org/rfc/rfc3549.txt (RFC 3549)
[12] Bert Hubert, « Linux advanced routing & trafic control howto »,
http://www.lartc.org/lartc.html
[13]Bert Hubert, « tc man page », http://www.lartc.org/manpages/tc.txt
[14]Alexey N. Kuznetsov, Alexey Makarenko and J Hadi Salim, « tc-red man page »,
http://www.lartc.org/manpages/tc-red.txt
[15]Alexey N. Kuznetsov and J Hadi Salim, « tc-prio man page »,
http://www.lartc.org/manpages/tc-prio.txt
16