9. Class Based Queueing

 

 

9.1 PRINCIPE DE CBQ POUR LA MISE EN FORME

 

CBQ fonctionne en s’assurant que le lien est inactif juste assez longtemps pour abaisser la bande passante réelle au débit configuré. Pour cela, il calcule le temps qui devrait s’écouler entre des paquets de taille moyenne.

 

En cours de fonctionnement, le temps d’inactivité effectif (effective idle time) est mesuré en utilisant un algorithme qui considère que les paquets récents sont exponentiellement plus importants que ceux passés, on parle d’algorithme EWMA (Exponential Weighted Moving Average). La charge moyenne, ou load average, UNIX est calculée de manière identique.

 

Le temps d’inactivité calculé est soustrait à celui mesuré par EWMA. On appelle « avgidle » le nombre qui résulte de cette soustraction. Un lien parfaitement chargé a un avgidle nul car un paquet arrive à chaque intervalle calculé. On parle de dépassement de limite (overlimit) lorsque le CBQ doit s’arrêter à cause d’une liaison surchargée (avgidle << 0).

 

Le temps moyen d’inactivité avgidle doit être borné à une valeur maxidle car si le lien est inoccupé pendant plusieurs heures, la valeur de l’avgidle devient trop grande, ce qui autoriserait des bandes passantes infinies.

 

 

9.2 SYNTAXE POUR LA MISE EN FORME

 

tc qdisc {add | del} dev INTERFACE root cbq [avpkt AVPKT] [bandwidth BP]

     [cell CELL] [maxburst MAXBURST] [minburst MINBURST] [minidle MINIDLE]

     [mpu MPU] [rate RATE]

 

Avec comme paramètres :

 

Ø       avpkt : taille moyenne d’un paquet (en nombre d’octets) ;

 

Ø       bandwidth : bande passante du périphérique, nécessaire pour les calculs de temps d’inoccupation ;

 

Ø       cell : durée de transmission d’un paquet, généralement de valeur 8, doit être une puissance de 2 ;

 

Ø       maxburst : nombre de paquets utilisés pour calculer maxidle de sorte que lorsque avgidle est égal à maxidle, maxburst paquets puissent être envoyés en rafale avant que avgidle ne retombe à zéro ;

 

Ø       minburst : nombre de paquets envoyés d’un seul coup après un temps supérieur au temps d’inoccupation, après l’envoi des minburst paquets, on attend pendant une période de minburst ;

 

Ø       minidle : si avgidle < 0, il y a dépassement de limite et on attend jusqu’à ce que avgidle soit suffisamment grand pour envoyer un paquet. Si avgidle atteint une valeur trop basse, il est remis à minidle afin d’éviter qu’une brusque rafale de données n’empêche le lien de fonctionner pendant une période prolongée.

 

Ø       mpu : taille minimum d’un paquet qui prend en compte l’encapsulation du paquet dans un autre protocole (exemple : une trame ethernet avec 0 octet de données IP fait 64 octets) ;

 

Ø       rate : débit du trafic sortant du gestionnaire.

 

Remarques : On ne peut configurer directement le maxidle, il faut passer par la configuration de maxburst. D’autre part, minidle est mesuré en µs et correspond à un temps négatif, par exemple, si minidle = 15µs, cela correspond en fait à -15µs.

 

 

9.3 UTILISATION DE CBQ AVEC LES CLASSES

 

CBQ peut agir comme une file d’attente PRIO dans la mesure où les classes peuvent avoir différentes priorités et que les nombres de priorité les plus faibles sont examinés en premier. Les classes de plus faibles priorités sont regroupées et interrogées si elles ont des données disponibles. Lorsqu’une classe est autorisée à retirer un certain nombre d’octets de sa file d’attente, on essaye la classe de priorité suivante.

 

La syntaxe à adopter est alors la suivante :

 

tc qdisc {add | del} dev INTERFACE root cbq [ allot ALLOT ] [ prio PRIO ]

                      [ weight WEIGHT ] [ split NODE ] [ defmap MASK ]

 

dont les paramètres sont les suivants :

 

Ø       allot : unité de base de la quantité de données que peut envoyer une classe ;

 

Ø       prio : priorité, les classes internes avec les priorités les plus basses sont essayées en premier et tant qu’elles ont du trafic, les autres classes ne sont pas examinées ;

 

Ø       weight : rate / 10 ;

 

Ø       split NODE : une des sous classes du gestionnaire de mise en file d’attente désire recevoir des paquets configurés avec une certaine priorité qui est définie par le champ TOS (cf. Annexe 5) ;

 

Ø       defmap MASK : les bits de priorité des paquets subissent un OU logique avec le masque MASK pour savoir s’il y a bien correspondance, si MASK = 0xFF, on vérifie tout, si MASK = 0x00, on ne vérifie rien.

 

 

9.4 PARTAGE ET PRET DE LIEN

 

On peut ajouter à CBQ deux paramètres qui permettent d’indiquer quelles sont les classes qui peuvent emprunter de la bande passante aux autres, ou réciproquement, en prêter :

 

Ø       isolated/sharing : une classe configurée « isolated » ne prêtera pas sa bande passante à ses classes enfants, contrairement à une classe paramétrée « sharing »;

 

Ø       bounded/borrow : une classe bornée, ou « bounded », ne peut pas emprunter de la bande passante à ses classes enfants, contrairement à une classe configurée « borrow ».

 

 

9.5 EXEMPLE D'UTILISATION POSSIBLE

 

On cherche à faire de la mise en forme de trafic. On a une carte réseau à 100 Mbits/s et on souhaite limiter le trafic vers le PC 06 à 5 Mbits/s et celui vers le PC 03 à 3 Mbits/s. On commence par créer le gestionnaire de mise en file d’attente racine :

 

# tc qdisc add dev eth0 root handle 1:0 cbq bandwidth 100Mbit avpkt 1000 cell 8

 

Puis, on lui ajoute une sous-classe 1:1 bornée à 6 Mbits/s :

 

# tc class add dev eth0 parent 1:0 classid 1:1 cbq bandwidth 100Mbit rate 6Mbit weight 0.6Mbit prio 8 allot 1514 cell 8 maxburst 20 avpkt 1000 bounded

 

On ajoute deux sous-classes à la classe 1:1 (qui dérive de la racine 1:0), la sous-classe 1 :2 est limitée à 5Mbits/s et la sous-classe 1 :3 à 3Mbits/s, toutes deux ont un CBQ comme gestionnaire de mise en file d’attente :

 

# tc class add dev eth0 parent 1:1 classid 1:2 cbq bandwidth 100Mbit rate 5Mbit weight 0.5Mbit prio 5 allot 1514 cell 8 maxburst 20 avpkt 1000

 

# tc class add dev eth0 parent 1:1 classid 1:3 cbq bandwidth 100Mbit rate 3Mbit weight 0.3Mbit prio 5 allot 1514 cell 8 maxburst 20 avpkt 1000

 

Il nous manque encore les gestionnaires de mise en file d’attente dont les paquets sortant seront présentés à l’interface. On veut que chaque flux de données soit traité de manière égale, on utilise donc un gestionnaire SFQ :

 

# tc qdisc add dev eth0 parent 1:2 handle 20: sfq

# tc qdisc add dev eth0 parent 1:3 handle 30: sfq

 

On ajoute les filtres qui, attachés directement à la racine, permettront d’envoyer le flux en destination du PC 03 vers 1 :2 et celui en destination du PC 06 vers 1 :3 (cf. Annexe 11 pour la syntaxe du classificateur u32) :

 

# tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip src 192.168.0.3/24 flowid 1:2

 

# tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip src 192.168.1.6/24 flowid 1:3

 

 

Remarque : compte tenu de la configuration du réseau mis à notre disposition pour les tests, il est évident que le bon fonctionnement des commandes ci-dessus n’a pas pu être vérifié expérimentalement, le trafic venant d’Internet ne passant pas par le routeur linux.

 

 


Retour au sommaire