Quel est le lien entre la mise en file d'attente pondérée et la détection précoce aléatoire pondérée?

J'essaie de comprendre comment fonctionnent les systèmes QoS et je ne sais pas exactement comment WFQ et WRED interagiraient.

Au début, je pensais que WFQ est un mécanisme de mise en file d'attente et que WRED est un mécanisme d'évitement de congestion. WFQ doit planifier les paquets dans les files d'attente et WRED est là pour les supprimer lorsque les files d'attente sont pleines. Si je configure QoS sur par exemple un commutateur L3, je mettrais en place un mécanisme de mise en file d'attente et un mécanisme d'évitement de congestion, donc je pourrais en théorie avoir WFQ et WRD travaillant ensemble. Par exemple, ce document semble impliquer que je les organiserais de cette manière. Certains autres documents Cisco mentionnent que je pourrais les utiliser indépendamment.

Ensuite, j'ai voulu en savoir plus sur leur fonctionnement et j'ai commencé à chercher sur Internet. En conséquence, maintenant je n'ai aucune idée de ce qu'ils sont et comment ils fonctionnent.

Certains sites (du moins à ma connaissance du contenu) affirment que les algorithmes de planification de paquets et les algorithmes d'évitement de congestion sont fondamentalement les mêmes. Par exemple, dans cet article Wikipedia, ils sont tous placés dans un même groupe. Certains articles aléatoires ont mentionné que je pouvais utiliser WFQ XOR WRED.

Donc, ce que je voulais demander, c'est à quel point WFQ et WRED sont liés? Quand devrais-je utiliser l'un ou l'autre et quand les deux, si c'est même possible?

Weighted Fair Queuing (WFQ) est comme son nom l'indique un algorithme de mise en file d'attente. La file d'attente est utilisée en cas d'encombrement sur une interface. Ceci est généralement détecté par le fait que la bague de transmission (TX-Ring) est pleine. Cela signifie que l'interface est occupée à envoyer des paquets. La mise en file d'attente n'a lieu qu'en cas de congestion sur l'interface. Dans certains cas, la taille de l'anneau TX peut être manipulée. Un petit anneau TX donne à la file d'attente du logiciel plus de puissance quant aux paquets qui seront envoyés en premier, mais ce n'est pas très efficace. Un anneau TX trop grand rendrait la file d'attente du logiciel presque inutile et entraînerait une latence et une gigue plus élevées pour les paquets importants.

L'algorithme de mise en file d'attente par défaut est généralement First In First Out (FIFO). Cela signifie que les paquets sont livrés exactement dans l'ordre où ils arrivent à l'entrée de l'interface. Ce n'est généralement pas souhaitable car certains paquets doivent être priorisés.

Il est assez courant qu'un client achète un service auprès d'un fournisseur d'accès Internet (FAI) chez subrate. Autrement dit, le client achète un service à 50 Mbit / s mais l'interface physique fonctionne à 100 Mbit / s. Dans ce cas, il n'y aura pas de congestion, mais le FAI limitera la quantité de trafic provenant du client. Pour introduire une congestion artificielle dans ces cas, un shaper peut être appliqué.

Maintenant qu'il y a congestion, un algorithme de mise en file d'attente peut être appliqué. Notez que les algorithmes de mise en file d'attente ne fournissent pas de bande passante supplémentaire, ils nous permettent simplement de décider quels paquets sont les plus importants pour nous. WFQ est un algorithme qui prend plusieurs paramètres et prend une décision en fonction de cela. L'algorithme est assez complexe et utilise le poids (priorité IP), la taille des paquets et le temps de planification comme paramètres. Il y a une explication très détaillée d'INE ici. WFQ est un bon choix si l'on ne veut pas trop tripoter la file d'attente car il fournit une bande passante adéquate aux flux de petite taille comme SSH, Telnet, voix et cela signifie qu'un transfert de fichiers ne volera pas toute la bande passante.

La détection précoce pondérée aléatoire (WRED) est un mécanisme permettant d'éviter la congestion. WRED mesure la taille des files d'attente en fonction de la valeur de priorité et commence à supprimer des paquets lorsque la file d'attente se situe entre le seuil minimum et le seuil maximum. La configuration décidera que 1 paquet sur N est supprimé. WRED aide à empêcher la synchronisation TCP et la famine TCP. Lorsque TCP perd des paquets, il démarre lentement et si toutes les sessions TCP perdent des paquets en même temps, elles pourraient être synchronisées, ce qui fournit un graphique comme celui-ci:

Comme on peut le voir si WRED n'est pas configuré, le graphique passe à fond, puis devient silencieux, puis à fond et ainsi de suite. WRED fournit un débit de transmission plus moyen. Il est important de noter que UDP n'est pas affecté par la suppression de paquets car il n'a pas de mécanisme d'accusé de réception et de fenêtre coulissante implémentée comme TCP. Par conséquent, WRED ne doit pas être implémenté sur une classe basée sur UDP comme une classe gérant SNMP, DNS ou d'autres protocoles basés sur UDP.

WFQ et WRED peuvent et doivent être déployés ensemble.

Tout d'abord, ne croyez pas tout ce que vous lisez sur Internet ;-)

Parfois, les algorithmes (ou la façon dont ils sont physiquement mis en œuvre) ne rentrent pas parfaitement dans une catégorie théorique. Ce que vous appelez cela est moins important que de comprendre ce qu'il fait.

L'intérêt de WFQ (ou de tout autre algorithme de programmation) est de partager la bande passante de liaison limitée entre les différents flux. WFQ essaie d'allouer la bande passante proportionnellement à chaque flux. CBWFQ fait de même pour chaque "classe". Dans un monde parfait, avec des files d'attente illimitées et une mémoire illimitée, ce serait tout ce dont vous avez besoin - vous partagez la bande passante et tout le monde est heureux.

Mais comme les appareils n'ont pas de files d'attente et de mémoire illimitées, certains "raccourcis" doivent être créés. Parce qu'une file d'attente a une taille limitée, il y a le risque que la file d'attente se remplisse, provoquant des pertes de queue et la synchronisation du trafic. Essentiellement, si ma file d'attente déborde, je ne contrôle plus la bande passante.

Pour éviter que mes files d'attente ne débordent, j'utilise la détection précoce aléatoire. Cet algorithme supprime de manière aléatoire des paquets de la file d'attente en fonction de son niveau de remplissage (profondeur) - plus la file d'attente est pleine, plus les paquets seront supprimés. L'objectif est d'empêcher la file d'attente de déborder, afin que l'algorithme de planification puisse fonctionner.

Ensuite, un ingénieur Cisco brillant a remarqué que l'on pouvait utiliser moins de files d'attente (matériel plus simple) et supprimer de manière aléatoire différents types de trafic à différentes profondeurs de file d'attente. WRED supprime le trafic de la file d'attente à différentes profondeurs en fonction du type de trafic. Bien que vous puissiez appeler WRED un mécanisme d'évitement de la congestion, étant donné que la profondeur de chute du trafic varie en fonction du type de trafic, l' effet est que différents types obtiennent moins d'espace dans la file d'attente et donc moins de bande passante. Il agit donc également comme un algorithme de planification. Vous dites po-tay-to et je dis po-tah-toe.

Une autre différence: FQ et WFQ fonctionnent sur tous les types de trafic, car ils comptent essentiellement des octets. RED et WRED ne fonctionnent qu'avec TCP, car ils dépendent du mécanisme de contrôle de flux de TCP pour ralentir le trafic et empêcher la file d'attente de déborder.

(Remarque: pour des raisons d'explication, j'ignore les files d'attente prioritaires et LLQ. C'est une autre réponse).

Je suis également d'accord avec tout ce que Mike a dit.

Voici un exemple de CBWFQ et WRED:

carte-politique OUT

classe Voix
priorité pour cent 20

classe
Bande passante vidéo pour cent 30

classe P1
largeur de bande pour cent 10
détection
aléatoire basée sur dscp détection aléatoire dscp af31 26 40 10

classe P2
bande passante pourcentage 15
détection
aléatoire basée sur dscp détection aléatoire dscp af21 24 40 10

classe classe par défaut
fair-queue
détection aléatoire basée sur dscp