Julien BISCONTI Sébastien CORNET Joël VANDERPYPEN Facultés Universitaires Notre-Dame de la Paix Institut d Informatique Année 2005-2006 TÉLÉINFORMATIQUE : MATIÈRES APPROFONDIES ÉNONCÉ : Déploiement et test du Weighted Fair Queuing en Linux
Téléinformatique : matières approfondies TABLE DES MATIÈRES Table des matières 1 Introduction 1 2 Weighted Fair Queuing 2 2.1 Scheduler.............................. 2 2.2 GPS................................. 2 2.3 MAX-min Fairness........................ 3 2.4 Implémentation.......................... 3 3 Déploiement 5 3.1 Installation............................. 5 3.2 Utilisation............................. 5 4 Expérimentation 7 4.1 Test HTB.............................. 8 4.1.1 Test 1............................ 8 4.1.2 Test 2............................ 9 4.1.3 Test 3............................ 11 4.2 Test WFQ.............................. 13 4.2.1 Test 1............................ 13 4.2.2 Test 2............................ 14 5 Conclusion 17 A Installation WFQ 19 A.1 Patch Kernel............................ 19 A.2 Patch tc............................... 19 B Modification du Code 20 Weighted Fair Queuing Page 1
Téléinformatique : matières approfondies 1 INTRODUCTION 1 Introduction L Internet fonctionne sur le principe best-effort, les paquets sont envoyés à leur destinataire mais sans aucune garantie si ce n est qu ils feront de leur mieux. Il y a beaucoup de choses qui peuvent arriver aux paquets pendant qu ils vont de l origine à leur destination. Un paquet peut être retardé (delayed), corrompu, arrivé dans un autre ordre que celui par lequel il a été envoyé, voire être carrément supprimé (dropped). L évolution des nouvelles technologies et du monde des télécommunications nous a poussé à mettre en place des mécanismes permettant d avoir une garantie sur la qualité du service. Les protocoles offrant la qualité de service (QoS) permettent, à l aide d algorithmes, de donner la priorité à certains flux par rapport à d autres, mais aussi d effectuer de la gestion de bande passante, d optimiser le délai de transfert et bien d autres fonctionnalités. Du point de vue des fournisseurs d accès à Internet, offrir un service assurant une qualité minimum certaine est une motivation supplémentaire pour facturer les utilisateurs. Ce rapport a pour but de montrer une méthode parmi tant d autre permettant de garantir la qualité de service. Dans notre cas, nous utiliserons un scheduler organisateur de paquet permettant de contrôler le flux de données selon une certaine équité. La section 2 introduira le concept de scheduler de paquet et décrira le WFQ. La section 3 expliquera le déploiement d une version du WFQ sous Linux. La section 4 décrira les différents tests validant ou non l implémentation, ainsi que les différentes configurations utilisées, ainsi que les explications des différents résultats obtenus. Nous terminerons cette étude par une conclusion à la section 5 Weighted Fair Queuing Page 1
Téléinformatique : matières approfondies 2 WEIGHTED FAIR QUEUING 2 Weighted Fair Queuing 2.1 Scheduler Le Weighted Fair Queuing est une technique d ordonnancement de paquet permettant de garantir un débit minimum. La principale caractéristique du WFQ est de permettre à plusieurs sessions de partager la même ligne physique. Le WFQ est une approximation du Generalized Processor Sharing (GPS) qui est, comme son nom l indique, une généralisation du Processor Sharing. Brièvement, le PS est un scheduler dont chaque session possède sa file d attente First-In First-Out propre. À n importe quel moment, les (N) files d attente actives (c est-à-dire, les sessions ayant une file link speed N. d attente non vide) sont desservies simultanément à un débit : À partir du moment où toutes les sessions ont leur propre file d attente, une session envoyant trop de données n influence pas le débit des autres sessions, seulement le sien. 2.2 GPS Le GPS permet à chaque session d avoir des parts différentes du rapport 1/N, autrement dit, il permet d offrir des garanties de débit minimum, mais pondérées pour chaque session. Le GPS est un scheduler idéal, malheureusement il est irréalisable en terme technique, c est un idéal mathématique. La raison est qu il ne fonctionne pas par paquet "entier" comme le font tous les protocoles de communications actuels, le GPS envoie sur le réseau une quantité infinitésimale de donnée de chaque file d attente à la façon d un tourniquet 1. Il permet d allouer de la bande passante aux files d attentes actives. Nous pouvons leur allouer des priorités, plus concrètement, des poids, garantissant un pourcentage de la bande passante minimum. Cela se fait avec la formule : r j (t) = W j (1) Wk où r j (t) est le débit (bande passante) de la session j au temps t, W j représente le poids associé à la session j et k est l indice parcourant l ensemble de toutes les files d attentes actives. Pour de plus amples détails sur le sujet, le lecteur intéressé peut consulter l article original [Par92]. 1 Round-Robin. Weighted Fair Queuing Page 2
Téléinformatique : matières approfondies 2 WEIGHTED FAIR QUEUING 2.3 MAX-min Fairness Un principe très important est la MAX-min Fairness 2. Pour rappel, cela signifie que chaque session a droit à autant de ressources du réseau que les autres sessions, d où le principe d équité. Mais certaines sessions ont de plus grands besoins que d autres. On va maximiser l utilisation des ressources de ceux qui ont le minimum de besoin, et on s assure que l on maximise l utilisation des ressources de chaque session sous la contrainte qu une augmentation des ressources nécessaires pour une session donnée ne diminue pas les ressources allouées aux sessions nécessitant moins de ressources. On peut adapté ce principe au scheduler, c est-à-dire qu il garanti un débit minimum à toutes les sessions, mais si la bande passante n est pas totalement occupée, il y a possibilité d emprunter de la bande passante sans déranger aucune autre session. On peut faire une analogie avec le monde des télécommunications. La différence est la même qu entre le paradigme packet-switch et le paradigme virtual-circuit. Avec ce dernier, le réseau établit un circuit dédié avant que les noeuds ne commencent à communiquer. Une partie de la bande passante est réservée, empêchant les autres noeuds de pouvoir utiliser cette partie de bande passante jusqu à ce qu elle soit relâchée et qu une nouvelle connexion soit mise en place. Quant à lui, le paradigme packet-switch est prédominant dans le monde de l Internet, il ne requiert pas de réservation de bande passante et permet à plusieurs noeuds de communiquer presque simultanément sur le même câble. 2.4 Implémentation Le WFQ (ou Packet-by-Packet GPS, PGPS) est en fait, la version paquet du GPS. Un seul paquet est traité à la fois provenant des différentes files d attente actives. Chaque session j (file d attente) a un poids W j définissant son débit minimum garanti. Quand la file d attente envoie un paquet sur l interface réseau, chaque session reçoit une certaine quantité de bande passante, qui est toujours plus grande ou égale à ce dont elle a droit. La formule ci-dessous est la même que l équation (1) pour le GPS mais on raisonne ici en terme de paquet : r j (t) = W j Wk (2) où r j (t) est le débit (bande passante) de la session j au temps t, W j représente le poids associé à la session j et k est l indice parcourant l ensemble de toutes les files d attentes actives. 2 Équité maximum-minimum Weighted Fair Queuing Page 3
Téléinformatique : matières approfondies 2 WEIGHTED FAIR QUEUING La signification des poids est très importante, le poids d une session représente le débit minimum de la session, garanti par la formule citée ci-dessus. Évidemment, si toutes les sessions sont actives (ont un/des paquet(s) dans la file d attente), le poids W j de la session j garanti un débit minimum borné inférieurement. Dans le cas où une seule session est active, nous avons W j = W k, la session peut alors utiliser toute la bande passante. Un seul paquet peut être traité à la fois provenant des différentes files d attente actives. Chaque paquet arrivant dans la file d attente se voit recevoir une heure virtuelle de départ (virtual start time) et une heure virtuelle de fin d envoi (virtual finishing time). Soit S(k,i) Heure virtuelle de départ du k e paquet de la session i ; F(k,i) Heure virtuelle de fin d envoi du k e paquet de la session i ; a(k,i) Heure d arrivée du k e paquet de la session i ; L(k,i) Taille du k e paquet de la session i v(t) Fonction temps virtuel représentant la progression du temps virtuel dans la simulation du modèle du GPS ; r(i) Débit de la session i, r(i) = W i /(link speed). Nous avons donc : dv (t) dt = d(real time) Wj (t) S(k,i) = max{f(k 1,i),V (a(k,i))} (4) F(k,i) = S(k,i) + L(k,i)/r(i) avec F(0,i) = 0. (5) Pour chaque session k, il faut retenir l heure virtuelle du dernier paquet dans la file d attente, F(k,i 1). Si la file d attente est vide, alors F(k,i 1) = 0. La fonction du temps virtuelle est en fait un timer qu il faut mettre à jour à chaque fois qu un paquet est envoyé sur le réseau ou arrive dans la file d attente. La formule (3) nous dit que quand il y a des sessions inactives, le temps virtuel progresse plus rapidement. Ce qui signifie que les sessions restantes obtiennent les parts des sessions inactives. Dans ce cas, le paquet sélectionné pour être envoyé est celui qui a l heure virtuelle de fin d envoi la plus petite. Ceci termine l explication du WFQ, nous allons poursuivre avec le déploiement. (3) Weighted Fair Queuing Page 4
Téléinformatique : matières approfondies 3 DÉPLOIEMENT 3 Déploiement Cette section contient principalement le descriptif de l installation et des problèmes techniques rencontrés. L environnement nécessaire au bon fonctionnement du module requiert quelques modifications que nous avons apportées. Nous allons en détailler les étapes pertinentes en vue de facilité la reproduction et la vérification de nos recherches, permettant l élaboration de travaux approfondis en la matière. 3.1 Installation Premièrement, nous devions déployer sous Linux, une version du WFQ trouvée sur Internet 3. L installation du scheduler dans le kernel linux n a nécessité que quelques légères modifications. Pour vérifier son fonctionnement, nous avons utilisé l outil tc contenu dans le package Iproute2. 4 Cette suite logicielle permet un accès à une variété d accessoires pour les réseaux avec le kernel Linux. Il permet de faire de la politique de routage, du NAT, de fournir de la QoS, et bien d autres encore. Quelques modifications ont été apportées pour que tc reconnaisse le module WFQ, mais les modifications sont mineures et n influencent pas le comportement du programme en général. Par contre, le module WFQ n est pas utilisable avec les versions plus récentes de tc. Une petite modification est nécessaire pour pouvoir l utiliser, le lecteur intéressé peut consulter les différents détails d implémentation en annexe, page 20. Se plonger dans le code a été très fastidieux, car il y a pas mal de lignes de code, qui ont évolué entre les différentes version. Il s agissait en fait d un appel de fonction mal parsé. Une fois découvert, le bug a été très facilement corrigé. 3.2 Utilisation Nous allons maintenant illustrer les différentes commandes nécessaires à l utilisation des schedulers à l aide de tc. Tous les détails relatifs à ce logiciel sont repris dans [LAR06]. La première étape consiste à créer la qdisc principale avec la commande : t c qdisc add dev eth3 root handle 1 : 0 wfq W ifspeed LS 3 http ://pod.homelinux.net/wfq-linux/wfq qdisc on Linux.htm 4 http ://linux-net.osdl.org/index.php/iproute2 Weighted Fair Queuing Page 5
Téléinformatique : matières approfondies 3 DÉPLOIEMENT Où W (weight) représente le poids de la classe par défaut et LS (link speed) représente la vitesse de la ligne sortante. Pour créer les classes la commande est : t c c l a s s add dev eth0 parent 1 : 0 c l a s s i d 1 : 1 wfq W Où W représente le poids de la classe. Si nous voulons définir 3 sessions avec des poids respectivement de 1/2, 1/3 et 1/6, cela nous donnerait : #!/ bin/bash TC="/ r oot/iproute2/ t c / t c " ETH=" eth3 " echo " S e t t i n g QDISC... " $TC qdisc add dev $ETH r oot handle 1 : wfq 1 ifspeed 1250000 echo " S e t t i n g WFQ Classes " $TC c l a s s add dev $ETH parent 1 : c l a s s i d 1 : 1 0 wfq 17 $TC c l a s s add dev $ETH parent 1 : c l a s s i d 1 : 2 0 wfq 33 $TC c l a s s add dev $ETH parent 1 : c l a s s i d 1 : 3 0 wfq 50 echo " S e t t i n g u32 f i l t e r s " U32="$TC f i l t e r add dev $ETH parent 1 : 0 protocol ip prio 10 u32 match " $U32 ip dport 5000 0 x f f f f flowid 1 : 1 0 $U32 ip dport 5001 0 x f f f f flowid 1 : 2 0 $U32 ip dport 5002 0 x f f f f flowid 1 : 3 0 Le schéma ci-après illustre le script précédent. Weighted Fair Queuing Page 6
Téléinformatique : matières approfondies 4 EXPÉRIMENTATION RULES 1/2 WFQ WFQ 1/3 1/6 WFQ U32 FILTER PACKETS 00111010111010011001 01011011001111010110 11011010010101011101 OUT WFQ Other traffic not catched ROOT QDISC CLASS 4 Expérimentation Nous avons effectués différents tests sur les deux Qdisc HTB 5 et WFQ. Nous présentons ici ceux qui font le mieux ressortir le fonctionnement de ces Qdisc. Les tests sont composés comme suit : A Trois sessions (trois flux de données) différenciées par le port tcp, avec un instant de démarrage différent afin d isoler les comportements. B Deux sessions différenciées par leur TOS : un transfert scp et une session ssh réalisant un listing récursif du système de fichier. Tous les tests ont été effectués sur le testbed d Hugues Van Peteghem 6 entre les machines PC01 (émetteur, scheduling) et PC04 (récepteur, capture) reliées par un câble 100 Mbits. La vitesse du câble offrant une trop grande bande passante pour réaliser des tests de saturation, nous avons d abord étudier le comportement de HTB afin de pouvoir limiter le débit pour mener à bien nos tests. Les différentes captures de paquets et les graphiques montrant l évolution des sessions ont été faits à l aide du logiciel ethereal 7. Pour générer les données à envoyer, nous avons utiliser l utilitaire tg 8. L envoi de paquets de données pour les tests suivent un distribution exponentielle de moyenne 0.02, la taille des paquets suit elle aussi une distribution exponentielle avec pour moyenne 1400. En sachant que le MTU est 5 Hierarchical Token Bucket 6 http ://www.info.fundp.ac.be/ hvp 7 http ://www.ethereal.com/ 8 http ://www.postel.org/tg/ Weighted Fair Queuing Page 7
Téléinformatique : matières approfondies 4 EXPÉRIMENTATION généralement de 1500 par paquet, 1400 semble convenir. Lors de nos tests nous avons essayer de faire de sessions envoyant de plus petits paquets et cela venait fausser les priorités. Par moment, les sessions ayant beaucoup de petit paquet à envoyer prenait le dessus sur les sessions ayant de gros paquets à envoyer. C est pourquoi nous avons gardé une distribution exponentielle avec une moyenne de 1400. 4.1 Test HTB 4.1.1 Test 1 Le scheduler HTB, la documentation très claire et très complète se trouve dans [Dev02]. Le premier graphe a été réalisé avec les 3 flux de données passant chacun par un Token Bucket, les trois passant par un Token Bucket parent limitant la bande passante à 150Ko/s suivant cette configuration pour tc : $TC c l a s s add dev $ETH parent 1 : c l a s s i d 1 : 1 htb r a t e 150 kbps c e i l 150 kbps $TC c l a s s add dev $ETH parent 1 : 1 c l a s s i d 1 : 1 1 htb r a t e 10 kbps c e i l 50 kbps $TC c l a s s add dev $ETH parent 1 : 1 c l a s s i d 1 : 1 2 htb r a t e 50 kbps c e i l 100 kbps $TC c l a s s add dev $ETH parent 1 : 1 c l a s s i d 1 : 1 3 htb r a t e 70 kbps c e i l 100 kbps Weighted Fair Queuing Page 8
Téléinformatique : matières approfondies 4 EXPÉRIMENTATION TOTAL Flux 1 (tcp 5000) Flux 2 (tcp 5001) Flux 3 (tcp 5002) Les indicateurs noir, rouge, vert et bleu correspondent respectivement au 1 flux (tcp 5000), 2 flux (tcp 5001), 3 flux (tcp 5002) et tous flux venant de l émetteur pour le bleu. En analysant les valeurs du graphe obtenu, on observe que la limitation globale à 150Ko/s est bien respectée. Les trois flux restent toujours entre le taux minimum (rate) et leur plafond (ceil). Dans la mesure où le total des trois taux minimum (10, 50, 70) est inférieur à la bande passante disponible, les flux ont donc partagé le débit disponible pour atteindre les débits de {20, 60, 70} Ko/s 4.1.2 Test 2 Les valeurs rate et ceil ont été modifiées afin de voir si HTB respectait bien les limites : la somme des 3 taux minimum est supérieure au taux minimum de la classe parent mais reste inférieure à limite globale. Voici le script utilisé pour le test : Weighted Fair Queuing Page 9
Téléinformatique : matières approfondies 4 EXPÉRIMENTATION $TC c l a s s add dev $ETH parent 1 : c l a s s i d 1 : 1 htb r a t e 140 kbps c e i l 170 kbps $TC c l a s s add dev $ETH parent 1 : 1 c l a s s i d 1 : 1 1 htb r a t e 30 kbps c e i l 100 kbps $TC c l a s s add dev $ETH parent 1 : 1 c l a s s i d 1 : 1 2 htb r a t e 50 kbps c e i l 100 kbps $TC c l a s s add dev $ETH parent 1 : 1 c l a s s i d 1 : 1 3 htb r a t e 70 kbps c e i l 100 kbps Voici le graphique : TOTAL Flux 1 (tcp 5000) Flux 2 (tcp 5001) Flux 3 (tcp 5002) Weighted Fair Queuing Page 10
Téléinformatique : matières approfondies 4 EXPÉRIMENTATION On remarque ce qui semblerait être une période d hésitation dans la période allant de la 50 à la 60 secondes du test, lors de la fin du flux 2, les deux autres flux ne reprennent pas le débit disponible simultanément. Autre point obscur, la bande passante n est pas complètement allouée (max 150 sur 170Ko/s). 4.1.3 Test 3 Des filtres faisant correspondre (match) les bits Bandwidth=0x08 et Delay=0x10 du champ TOS de l entête ip redirige les flux vers deux classes différentes. L outil scp est utilisé pour envoyer un fichier volumineux (une capture d un test antérieur dans ce cas-ci), ce flux sera marqué comme trafic de masse (TOS 0x08). Dans le même temps, une session ssh depuis PC04 sur PC01 qui exécute la commande ls -R /, cela afin de générer un flux important sur une session dite interactive (TOS 0x10). Le flux par défaut (non reconnu par les filtres) sera dirigé vers une troisième classe #!/ bin/bash TC="/ r oot/iproute2/ t c / t c " ETH=" eth3 " LIMIT=" l i m i t 4000" echo " S e t t i n g HTB r oot " $TC qdisc add dev $ETH r oot handle 1 : htb d e f a u l t 13 echo " S e t t i n g HTB Classes " $TC c l a s s add dev $ETH parent 1 : c l a s s i d 1 : 1 htb r a t e 100 kbps $TC c l a s s add dev $ETH parent 1 : 1 c l a s s i d 1 : 1 1 htb r a t e 30 kbps c e i l 100 kbps $TC c l a s s add dev $ETH parent 1 : 1 c l a s s i d 1 : 1 2 htb r a t e 50 kbps c e i l 100 kbps $TC c l a s s add dev $ETH parent 1 : 1 c l a s s i d 1 : 1 3 htb r a t e 70 kbps c e i l 100 kbps echo " S e t t i n g u32 f i l t e r s " U32="$TC f i l t e r add dev $ETH parent 1 : protocol ip prio 10 u32 " $U32 match ip t o s 0 x10 0 x10 flowid 1 : 1 1 #min delay $U32 match ip t o s 0x8 0 x8 flowid 1 : 1 2 #max BW Ce qui nous donne le graphe suivant : Weighted Fair Queuing Page 11
Téléinformatique : matières approfondies 4 EXPÉRIMENTATION Les indicateurs rouge, noir et vert correspondent respectivement au flux de masse, flux interactif et la somme des flux venant de l émetteur pour le vert. On remarque que le trafic interactif monte son débit jusqu à pousser le trafic de masse à son débit minimum. Weighted Fair Queuing Page 12
Téléinformatique : matières approfondies 4 EXPÉRIMENTATION 4.2 Test WFQ Nous avons obtenu des résultats assez concluant avec le HTB. Nous sommes alors passer au WFQ. Toujours afin de simuler une bande passante limitée, un Tocken Bucket a été placé à la racine de l interface, limitant la sortie à 100Ko/s. 4.2.1 Test 1 Les 3 flux utilisés précédemment ont été repris avec des pondérations de 17, 33, 50. #!/ bin/bash TC="/ r oot/iproute2/ t c / t c " ETH=" eth3 " $TC qdisc add dev $ETH r oot handle 1 : htb d e f a u l t 1 $TC c l a s s add dev $ETH parent 1 : c l a s s i d 1 : 1 htb r a t e 100 kbps c e i l 100 kbps echo " S e t t i n g WFQ QDISC" $TC qdisc add dev $ETH parent 1 : 1 handle 1 0 : wfq 100 ifspeed 1250000 echo " S e t t i n g WFQ Classes " $TC c l a s s add dev $ETH parent 1 0 : c l a s s i d 1 0 : 1 wfq 17 $TC c l a s s add dev $ETH parent 1 0 : c l a s s i d 1 0 : 2 wfq 33 $TC c l a s s add dev $ETH parent 1 0 : c l a s s i d 1 0 : 3 wfq 50 echo " S e t t i n g u32 f i l t e r s " U32="$TC f i l t e r add dev $ETH parent 1 : protocol ip prio 10 u32 " $U32 match ip dport 5000 0 x f f f f flowid 1 0 : 1 $U32 match ip dport 5001 0 x f f f f flowid 1 0 : 2 $U32 match ip dport 5002 0 x f f f f flowid 1 0 : 3 TOTAL Flux 1 (tcp 5000) Flux 2 (tcp 5001) Ce qui nous donne le graphique suivant : Flux 3 (tcp 5002) Weighted Fair Queuing Page 13
Téléinformatique : matières approfondies 4 EXPÉRIMENTATION Il n y a aucune différence marquante entre le débit des différents flux. À chaque fois que des données sont envoyé sur le réseau le débit des différents flux s équilibre avec celui des autres. Nous constatons que les priorités définies pour chaque session n influencent pas le comportement ces dernières. 4.2.2 Test 2 Le test suivant constitue à envoyer un flux beaucoup plus prioritaire que les autres, et en constater la nette différence entre les différentes sessions. Les pondérations sont cette fois de 10, 10, 80. Weighted Fair Queuing Page 14
Téléinformatique : matières approfondies 4 EXPÉRIMENTATION #!/ bin/bash TC="/ r oot/iproute2/ t c / t c " ETH=" eth3 " $TC qdisc add dev $ETH r oot handle 1 : htb d e f a u l t 1 $TC c l a s s add dev $ETH parent 1 : c l a s s i d 1 : 1 htb r a t e 100 kbps c e i l 100 kbps echo " S e t t i n g WFQ QDISC" $TC qdisc add dev $ETH parent 1 : 1 handle 1 0 : wfq 100 ifspeed 1250000 echo " S e t t i n g WFQ Classes " $TC c l a s s add dev $ETH parent 1 0 : c l a s s i d 1 0 : 1 wfq 10 $TC c l a s s add dev $ETH parent 1 0 : c l a s s i d 1 0 : 2 wfq 10 $TC c l a s s add dev $ETH parent 1 0 : c l a s s i d 1 0 : 3 wfq 80 echo " S e t t i n g u32 f i l t e r s " U32="$TC f i l t e r add dev $ETH parent 1 : protocol ip prio 10 u32 " $U32 match ip dport 5000 0 x f f f f flowid 1 0 : 1 $U32 match ip dport 5001 0 x f f f f flowid 1 0 : 2 $U32 match ip dport 5002 0 x f f f f flowid 1 0 : 3 Nous obtenons le graphe suivant : TOTAL Flux 1 (tcp 5000) Flux 2 (tcp 5001) Flux 3 (tcp 5002) Weighted Fair Queuing Page 15
Téléinformatique : matières approfondies 4 EXPÉRIMENTATION Nous n avons pas obtenu de résultat concluant, les 3 flux de données s équilibre sans que les poids ne soit pris en compte. Maintenant, deux possibilités s offre à nous, soit nous avons fait les mauvais tests, soit l implémentation du WFQ n est pas bonne. Nous avons donc tenu à mettre les différents scripts nous permettant d effectuer nos tests. Nous n avons pas réussi à entrer en contact avec l auteur du scheduler WFQ, et la documentation disponible était très légère, ce qui ne nous empêcher d approfondir le sujet. Malgré l aide reçue, nous n avons pas réussi à obtenir un seul résultat concluant avec le scheduler WFQ. Weighted Fair Queuing Page 16
Téléinformatique : matières approfondies 5 CONCLUSION 5 Conclusion La prise en main de HTB fut relativement aisée une fois que nous maîtrisions un peu mieux le logiciel tc. HTB donne les résultats escomptés tant que les valeurs rate et ceil sont bien hiérarchisées. Nous n avons pas exploité le concept de burst rate dans le cadre de ce TP. On remarque aussi qu il répartit plus facilement le débit disponible aux flux ayant le rate le plus bas comme nous le montre les tests 1 et 3 du HTB, page 8 et page 11 respectivement. Le plus difficile a été de comprendre le fonctionnement du logiciel tc. Il y a une communauté autour de ce projet offrant un certain support qui nous a été précieux. Concernant le WFQ, nous avons été déçu, malgré de nombreux essais. Il n a fonctionné qu une seule fois partiellement pour un seul des trois flux lorsque ce dernier émettait de petits paquets (de l ordre de 140 octets), le débit était alors inférieur aux autres mais il nous était impossible de déterminer si les poids étaient respecté du fait que les deux autres flux fonctionnait comme si le troisième n existait pas. Les résultats nous ont semblé erroné, c est pourquoi nous n avons pas tenu compte de ces résultats. Nous aurions aimé pousser plus loin notre expérimentation du WFQ mais le code étant tellement complexe et proche du kernel qu il aurait été plus facile de programmer un nouveau scheduler WFQ que de déboguer celuici. Les différents problèmes techniques, liés justement au code, ont été très demandeurs en temps, nous ralentissant pour effectuer plus de tests. Au niveau conceptuel, permettre à plusieurs sessions de fonctionner avec un débit minimum assuré devrait plaire à, par exemple, un opérateur de téléphonie mobile pour proposer différents services à ses clients. Les différentes sessions pourraient être du multimédia (visionner un film, écouter de la musique), de la voix (VoIP), ou du transfert de données (FTP) fournissant ainsi un débit ou délai minimum selon les besoins de chacun. Ce que cette technique apporte de plus est le principe d équité, ce qui est inutilisé peut être alloué à celui qui en a besoin, sans pour autant privé les autres utilisateurs. Weighted Fair Queuing Page 17
Téléinformatique : matières approfondies RÉFÉRENCES Références [Bla05] [Dev02] [KR05] Christophe Blaess. Programmation système en C sous Linux. EY- ROLLES, seconde edition, 2005. Martin Devera. HTB Linux queuing discipline manual - user guide, Mai 2002. James F. Kurose and Keith W. Ross. Computer Networking, A topdown approach featuring the internet. Addison Wesley, third edition, 2005. [LAR06] LARTC. Linux Advanced Routing and Traffic Control, 2006. http ://- lartc.org/. [Par92] A. Parekh. A generalized processor sharing approach to flow control in integrated services networks. Phd dissertation, Massachusetts Institute of Technology, February 1992. [Tan02] Andrew S. Tanenbaum. Computer Networks. Pearson Education, fourth edition, 2002. Weighted Fair Queuing Page 18
Téléinformatique : matières approfondies A INSTALLATION WFQ A Installation WFQ Ceci reprend les différentes étapes pour installer le module WFQ dans le kernel linux : A.1 Patch Kernel 1 * Placer le fichier sch_wfq.c dans le répertoire des sources du kernel : net/sched/ 2 * Modifier le fichier net/sched/makefile pour qu il contienne les lignes suivantes : {obj-$(config_net_sch_wfq) += sch_wfq.o} 3 * Modifier le fichier net/sched/config.in pour qu il contienne les lignes suivantes : if [ "$CONFIG_X86_TSC" = "y" ]; then tristate WFQ queue CONFIG_NET_SCH_WFQ fi A.2 Patch tc 4 * Copier q_wfq.c dans le répertoire des sources de iproute2 iproute2/tc/ 5 * Modifier le fichier iproute2/tc/makefile pour qu il contienne les lignes suivantes : TCMODULES += q_wfq.o 6 * Compiler votre kernel et tc, vous pouvez maintenant profiter du WFQ! Weighted Fair Queuing Page 19
Téléinformatique : matières approfondies B MODIFICATION DU CODE B Modification du Code Dans le fichier q_wfq.c, la fin du fichier est : 148 s t r u c t q d i s c _ u t i l wfq_ util = { 149 NULL, 150 "wfq ", 151 wfq_ parse_ opt, 152 wfq_print_opt, 153 NULL, 154 wfq_parse_class_opt, 155 wfq_ print_class_opt, 156 } ; Pour pouvoir fonctionner avec la dernière version de tc, il faut modifier le nom de la fonction wfq_util en wfq_qdisc_util. 148 s t r u c t q d i s c _ u t i l wfq_ qdisc_util = { 149 NULL, 150 "wfq ", 151 wfq_ parse_ opt, 152 wfq_print_opt, 153 NULL, 154 wfq_parse_class_opt, 155 wfq_ print_class_opt, 156 } ; Weighted Fair Queuing Page 20