Revenons donc sur HFSC, qui, contrairement aux autre mécanismes de gestion des queues, offre un niveau de souplesse très avancé… au prix d'une complexité bien plus élevée que la plupart des autres mécanismes de QoS qui peuvent être mis en œuvre avec pfSense.

Avant de plonger dans ce sujet passionnant, il est essentiel de bien comprendre cette section pour pouvoir réussir votre implémentation de HFSC au sein de pfSense.

 

Bande passante (bandwidth) : ce concept recouvre deux notions bien distinctes :

  • Pour la queue "principale (parent)" - il s'agira ici du taux de transfert (bit rate) maximum disponible pour toutes les queues rattachées à cette interface.
  • Pour les queues "enfant (child)" : cela correspond au taux de transfert (bit rate) maximum disponible pour la queue. Cette valeur est similaire à l'utilisation de «linkshare» avec une valeur dans le champs «m2». La valeur ne doit pas dépasser celle de la queue principale et peut être précisé en valeur absolue ou en pourcentage. Il est conseillé d'assigner un pourcentage de la bande passante totale disponible en prenant soin de ne pas dépasser les 100%.

 

Priorité (priority) :

Cela indique le niveau de priorité des queues les unes par rapport aux autres.

Plus le nombre est élevé, plus les paquets seront traités de façon prioritaire.

Les niveaux de priorité vont de 0 à 7 pour des queues de type HFSC et CBQ et de 0 à 15 pour les queues de type PRIQ.

Les queues de type PRIQ avec un numéro de priorité élevé sont toujours servi les premiers.

Les queues de type CBQ et HFSC sont servi les premiers si le lien est saturé et que la bande passante défini en "realtime" est aussi épuisée.

 

Qlimit : 

Qlimit défini le nombre de "slots" disponibles pour une queue afin de sauvegarder les paquets sortant quand la bande passante disponible a été épuisée (50 par défaut). Quand la totalité de la bande passante a été atteinte sur l'interface sortante, ou que les queues de niveau supérieur ont capté toute la bande passante alors les données ne peuvent plus être transmises.

Qlimit place alors les paquets que la queue ne peut transmettre et qui se présentent à lui dans des "slots" ordonnées en mémoire. Lorsque la bande passante devient de nouveau disponible, les slots Qlimit seront "vidés" suivant la méthode FIFO.

Si Qlimit atteint la valeur maximum de ses "slots", alors les paquets seront supprimés. Il faut considérer Qlimit comme une "solution à n'utiliser qu'en situation d'urgence" - mais qui est tout de même nettement préférable à la suppression directe des paquets. Ce paramètre ne constitue en rien un palliatif au bon réglage de ses queues. L’objectif principal doit être la mise au point de queues avec des limites de bande passante adéquates ! 

 

Realtime :

Le niveau de bande passante qui est garantie à la queue quel que soit le besoin des autres queues. Ce montant peut aller de 0 à 80% de la bande passante totale.

 

Par exemple si vous voulez être certain que votre serveur HTTP bénéficie d’une bande passante de 25KB/s quoi qu’il arrive. Régler ce paramètre donnera à votre queue HTTP la bande passante dont il a besoin, même si les autres queues souhaitent partager leur bande passante.

 

Upperlimit :

Le niveau de bande passante que la queue ne peut jamais dépasser.

 

Par exemple si vous avez des utilisateurs de peer to peer, il est possible de transférer leur trafic dans une queue et de limiter le trafic à un niveau faible en utilisant Upperlimit.

 

Linkshare (m2) :

Ce paramètre correspond à la même utilisation que le paramètre «bandwidth» exposé ci-avant. Si sous décidez d’utiliser les deux paramètres «linkshare m2» et «bandwidth» dans une même règle, pf n’utilisera que le paramètre précisé à la ligne «linkshare m2».

 

Cela ajoute un peu de confusion à un système déjà complexe. Pour cette raison, nous préférons n’utiliser que «bandwidth» dans les règles que nous créerons. La seule raison valable d’utiliser ce paramètre est si vous allez utiliser la fonction NLSC (non linear service curve).

 

NLSC : non linear service curve

Les directives «realtime», «upperlimit» et «linkshare» peuvent toutes bénéficier de l’utilisation de NLSC. m2 contrôle la bande passante attribuée à la queue, m1 et d sont des paramètres optionnels qui permettent de contrôler la bande passante initialement attribuée à la queue : pendant les d première mili secondes la bande passante bénéficie de la bande passante précisée dans m1.

 

Default :

Paramètre permettant de définir la queue par défaut. Il ne peut y avoir qu’une seule queue par défaut.

 

ECN (Explicit Congestion Notification) :

Dans ALTQ ECN (Explicit Congestion Notification) fonctionne en conjonction avec RED (Random early detection). ECN permet une notification de bout en bout des réseaux congestionnés sans perte de paquet. C’est une option qu’il est possible d’activer dans le protocole TCP/IP.

 

En règle générale la congestion est signalée dans les réseaux TCP/IP par une perte de paquet (drop). L’activation de l’option ECN permet à deux équipements  réseaux qui le supportent d’éviter la perte de paquets en signalant à l’autre équipement que le lien devient saturé.

 

Les paramètres RED (Random Early Detection) et RIO (Random Early Detection In and Out) fournissent des mécanismes de détection qui permettent de détecter préalablement les problème de congestion.

 

Le résultat permet d’obtenir une connexion plus stable des réseaux TCP/IP en cas de congestion.

QoS dans pfSense 2.0

 

Si cet article vous a intéressé, n'oubliez pas d'achetter vos appliances OpenSource auprès d'OSNet.eu !