[pfSense] Comprendre la priorisation de trafic

05/06/2019

Dans pfSense, il existe 3 principaux mécanismes de priorisation de flux :

- CBQ - Class Based Queueing
- PRIQ - Priority Queueing
- HFSC - Hierarchical Fair-Service Curve

PRIQ est un protocole de priorisation très simple (simpliste ?) mais nécessitant de faire très attention dans sa configuration.

CBQ est sans doute le protocole à utiliser dans la plupart des cas pour une entreprise souhaitant une gestion de la priorisation de trafic simple et efficace.

HFSC est sans conteste le protocole le plus évolué permettant un niveau de souplesse avancé, au prix d'une forte complexité...

Nous nous proposons ici de passer en revue ces différents mécanismes.
Dans un prochain article, nous verrons comment les mettre en œuvre dans pfSense.

CBQ - Class Based Queueing

CBQ est un algorithme permettant de diviser la bande passante d'une connexion en multiples queues ou classes.
Le trafic est assigné à l'une des queues, en fonction du protocole source/destination utilisé, du numéro de port, de l'adresse IP, etc.

Chaque queue se voit attribuer une bande passante et une priorité.

Les queues CBQ sont organisées de manière hiérarchique. Au sommet, nous retrouvons la queue "ROOT" (racine).
Chaque queue fille partage la bande passante de sa queue mère.

Il est également possible d'autoriser une queue à utiliser la bande passante de sa queue parente si celle-ci est sous-utilisée.

Exemple :

Root Queue (5Mbps)
	- Queue 1 (2Mbps)
	- Queue 2 (2Mbps)
	- Queue 3 (1Mbps)

La somme de la bande passante attribuée aux queues filles ne peut pas être supérieure à la bande passante totale de la queue mère.
Ainsi, dans notre exemple, la somme des bandes passantes des queues 1, 2 et 3 ne peut être supérieure à la bande passante de la queue Root.

Chaque queue fille peut elle-même avoir des queues filles :

Root Queue (5Mbps)
	- Queue 1 (2Mbps)
		Queue VoIP (1Mbps)
		Queue SSH (1Mbps)
	- Queue 2 (2Mbps)
		Queue HTTP (800Kbps)
		Queue VNC (200Kbps)
	- Queue 3 (1 Mbps)

Pour chacune de ces queues, on peut activer l'emprunt ("borrow") de bande passante à sa queue mère :

Root Queue (5Mbps)
	- Queue 1 (2Mbps)
		Queue VoIP (1Mbps - borrow)
		Queue SSH (1Mbps)
	- Queue 2 (2Mbps)
		Queue HTTP (800Kbps)
		Queue VNC (200Kbps)
	- Queue 3 (1 Mbps)

Dans l'exemple ci-dessus, la queue VoIP dispose d'une bande passante de 1Mbps. Cependant, elle peut potentiellement utiliser jusqu'à 2Mbps (bande passante allouée à sa queue mère - Queue 1) si la queue SSH n'est pas pleine.

Une priorité est attachée à chaque queue. La priorité la plus forte sera préférée en cas de congestion. Si deux queues ont la même priorité, la distribution s'opère suivant un processus de type round-robin.

Root Queue (5Mbps)
	- Queue 1 (2Mbps, priorité 1)
		Queue VoIP (1Mbps - borrow, priorité 5)
		Queue SSH (1Mbps, priorité 3)
	- Queue 2 (2Mbps, priorité 1)
		Queue HTTP (800Kbps, priorité 1)
		Queue VNC (200Kbps, priorité 2)

Dans notre exemple ci-dessus, la queue 1 et la queue 2 ayant la même priorité, aucune des deux queues ne sera priorisée l'une par rapport à l'autre. Durant le temps où la queue 1 sera traitée, les queues filles seront traitées en même temps. La queue VoIP sera traitée en priorité par rapport à la queue SSH (en cas de congestion).
Il est à noter qu'uniquement les queue fille de la même queue mère sont comparées entre-elles (c'est-à-dire que la priorité de la queue VoIP sera comparée à la priorité de la queue SSH, mais ne sera pas comparée à la queue HTTP par exemple).

Davantage d'informations sur le protocole CBQ : CBQ sur openbsd.org - EN

PRIQ - Priority Queueing

PRIQ est un protocole permettant de définir plusieurs queues attachées à une interface et d'y affecter une priorité. Une queue avec une priorité supérieure sera toujours traitée avant une queue avec une priorité plus faible.
Si deux queues ont à la même priorité, la distribution se fera suivant le processus round-robin.

La construction des queues PRIQ est plate (il n'y a pas de notion de queue mère et de queue fille) - il n'est pas possible de définir une queue au sein d'une autre queue.

Une queue "ROOT" (racine) est définie, qui sera la bande passante totale de la connexion. Les autres queues sont définies sous la queue ROOT.

Exemple :

Root Queue (2Mbps)
	- Queue 1 (priorité 2)
	- Queue 2 (priorité 1)

La queue Root est définie comme disposant de 2Mbps. La queue 1 disposant de la plus forte priorité, l'ensemble de ses paquets seront traités en priorité. Tant qu'il existe des paquets dans la queue 1, la queue 2 ne sera pas traitée.
Dans chaque queue, les paquets sont traités dans l'ordre FIFO (First IN First OUT).

/!\ Attention : il est bien important de comprendre que dans le processus PRIQ, les paquets se trouvant dans les queues disposant de la priorité la plus élevée sont toujours traités avant les paquets des autres queues.
Ainsi, si une queue disposant d'une priorité élevée reçoit un flux de paquet continu, les queues disposant d'une priorité plus faible seront peu, voire pas traitées.

Davantage d'informations sur le protocole PRIQ : PRIQ sur openbsd.org - EN

H-FSC

HFSC est un algorithme évolué de traitement hiérarchique permettant de répartir la bande passante d'un lien et de contrôler l'allocation de ressources en fonction de la bande passante et de la latence.

Tout comme dans l'algorithme CBQ, les queues HFSC sont organisées de manière hiérarchique. Au sommet, nous retrouvons la queue "ROOT" (racine).
Chaque queue fille partage la bande passante de sa queue mère.

Chaque queue fille peut elle-même avoir des queues filles :

Root Queue (5Mbps)
	- Queue 1 (2Mbps)
		Queue VoIP (1Mbps)
		Queue SSH (1Mbps)
	- Queue 2 (2Mbps)
		Queue HTTP (800Kbps)
		Queue VNC (200Kbps)
	- Queue 3 (1 Mbps)

Une priorité est donnée à chaque queue. Les priorités vont de 0 (priorité la plus faible) à 7 (priorité la plus forte). Comme pour CBQ, ces priorités ne sont appliquées qu'en cas de saturation du lien.

Root Queue (5Mbps)
	- Queue 1 (2Mbps, priorité 1)
		Queue VoIP (1Mbps, priorité 5)
		Queue SSH (1Mbps, priorité 3)
	- Queue 2 (2Mbps, priorité 1)
		Queue HTTP (800Kbps, priorité 1)
		Queue VNC (200Kbps, priorité 2)

Qlimit

Chaque queue se voit attribuée en plus un paramètre "Qlimit". Qlimit correspond à un buffer (tampon) qui va se remplir lorsque la bande passante attribuée à la queue sera saturée : plutôt que de rejeter les nouveaux paquets arrivant, ceux-ci vont être mis en file d'attente dans ce buffer.

La valeur de Qlimit (la taille du buffer donc) est exprimée en nombre de paquets. Par défaut, sa valeur est de 50.

Un fois que le buffer définit par Qlimit est saturé, les nouveaux paquets sont supprimés (drop).

Il n'est pas nécessaire, et sûrement contre-productif, de définir une valeur trop grande pour Qlimit : cela ne solvera pas un problème de saturation de bande-passante. Une trop grande valeur peut entraîner un "buffer bloat".

Pour calculer la bonne valeur de Qlimit, il faut se demander combien de temps nous souhaitons garder un paquet dans le buffer.

Si le concept de MTU ou de latence ne vous est pas familier, lisez tout d'abord les liens cités précédemment.

Si l'on souhaite qu'un paquet reste bufferisé au maximum 0,5 seconde (ce qui est déjà long), le calcul à effectuer pour connaître la valeur de Qlimit est le suivant :

(BP / 8) / MTU = nb paquets/sec.

Avec :
BP : bande passante (en bits/s)
MTU : MTU du lien (en bytes)

Par exemple, si nous disposons d'un lien offrant 10Mbps en upstream ayant une MTU de 1500 bytes :

(10.000.000 / 8) / 1500 = 833 pq/sec

Soit, si l'on souhaite une bufferisation de 0,5 sec sur notre lien : 833x0,5 = 416 paquets (=valeur de notre Qlimit)

Si vous ne souhaitez pas vous lancer dans de tels calculs, laissez la valeur par défaut de Qlimit (50 paquets).

realtime

Ce paramètre permet de définir la bande-passante minimale garantit en permanence à la queue.

upperlimit

Le paramètre upperlimit permet de définir une limite haute de bande passante que la queue ne pourra jamais dépasser.
Cela permet, par exemple, de limiter l'usage fait de la bande passante pour un type de service ou d'utilisateurs.

linkshare

Ce paramètre remplit la même fonctionnalité que le paramètre "bandwith" définit plus haut. C'est-à-dire qu'il permet de définir la bande-passante disponible pour une queue ; cette bande-passante pouvant être empruntée à d'autres queues.

Aussi, si nous définissons le paramètre "bandwith" ET le paramètre "link share (m2)", c'est le paramètre "linkshare m2" qui sera pris en compte.

Ainsi, nous avons les paramètres suivants :

realtime : bande-passante minimale garantie à une queue
linkshare : bande-passante globale attribuée à la queue (utilisée une fois que realtime est plein)
upperlimit : bande-passante maximale que la queue ne pourra jamais dépassée
bandwith : redondant avec linkshare. Peut être utilisé si l'on ne souhaite pas utiliser le mécanisme NLSC.

Il est important de comprendre que le paramètre "linkshare" n'est utile que si l'on souhaite activer le mode NLSC (non linear service curve). Autrement, seul le paramètre "bandwith" peut être utilisé dans le paramétrage des queues.

NLSC

NLSC est un mécanisme permettant de définir une bande-passante initiale, puis après un certain temps, une bande-passante définitive.
Ainsi, on va pouvoir définir une bande-passante qui va évoluer dans le temps.

Il existe 3 paramètres pour la configuration de NLSC :

m1 : bande passante initiale attribuée à la queue
m2 : bande passante définitive attribuée à la queue
d : durée (en ms) durant laquelle la bande passante attribuée à la queue est la bande passante initiale (m1), avant de devenir la bande passante définitive (m2)

NLSC est principalement utilisé dans le but d'offrir un maximum de bande-passante sur un certain laps de temps, puis de brider cette bande-passante. Ainsi, ce "bridage" n'impacte que les gros fichiers transitant dans la queue concernée.

NLSC est activable aussi bien sur les directives realtime, upperlimit et linkshare.
Si l'on ne souhaite pas faire évoluer la bande-passante dans le temps, seul le paramètre m2 doit être défini.

Options

Il existe plusieurs options que l'on peut définir sur nos queues. Actuellement, elles sont au nombre de quatre :

Default queue : permet de définir la queue par défaut. Il ne peut y avoir qu'une seule queue par défaut par interface.
Explicit Congestion Notification (ECN) : ECN permet d'envoyer une notification de congestion sur le réseau afin de limiter le "drop" de paquets. N'est utilisable qu'entre deux équipements le supportant.
Random Early Detection (RED) : utilisé avec ECN, offre un mécanisme de détection de congestion (avant qu'elle n'ait lieu).
Random Early Detection In and Out (RIO) : idem RED.

Nous ne recommandons pas l'usage des paramètres RED, RIO et ECN.

Une fois tous ces paramètres appliqués, si nous reprenons notre exemple de queues définit précédemment :

Root Queue (5Mbps)
	- Queue 1 (2Mbps, upperlimit: 3Mbps, realtime: 1Mbps)
		Queue VoIP (1Mbps, realtime: 1Mbps, qlimit: 500)
		Queue SSH (1Mbps, qlimit 500)
	- Queue 2 (2Mbps, upperlimit: 3Mbps, default)
		Queue HTTP (800Kbps, realtime: 500Kbps)
		Queue VNC (200Kbps, qlimit: 500)

Nous venons de passer en revu les 3 principaux mécanismes de priorisation de trafic proposés dans pfSense.

Dans un prochain article, nous verrons comment les configurer et les activer dans pfSense.