¿Cómo se relacionan la ponderación equitativa ponderada y la detección precoz aleatoria ponderada?

Estoy tratando de entender cómo funcionan los sistemas QoS y no estoy seguro de cómo interactuarían exactamente WFQ y WRED.

Al principio, pensé que WFQ es un mecanismo de espera y que WRED es un mecanismo para evitar la congestión. WFQ debe programar paquetes en colas y WRED está allí para descartarlos cuando las colas están llenas. Si configuro QoS en, por ejemplo, un conmutador L3, establecería un mecanismo de cola y un mecanismo para evitar la congestión, por lo que, en teoría, podría tener WFQ y WRD trabajando juntos. Por ejemplo, este documento parece implicar que yo estaría configurado de esa manera. Algunos otros documentos de Cisco mencionan que podría usarlos de forma independiente.

Luego quise aprender más sobre cómo funcionaban y comencé a buscar en Internet. Como resultado, ahora no tengo idea de qué son y cómo funcionan.

Algunos sitios (al menos para mi comprensión del contenido) afirman que los algoritmos de programación de paquetes y los algoritmos para evitar la congestión son básicamente los mismos. Por ejemplo, en este artículo de Wikipedia, todos se ubican en un mismo grupo. Algunos artículos al azar mencionaron que podría usar WFQ XOR WRED.

Entonces, ¿qué quería preguntar es qué tan relacionados están WFQ y WRED? ¿Cuándo usaría uno u otro y cuándo ambos, si eso es posible?

La ponderación equitativa ponderada (WFQ) es como su nombre implica un algoritmo de colas. La cola se utiliza cuando hay congestión en una interfaz. Esto generalmente se detecta a través de que el anillo de transmisión (TX-Ring) está lleno. Esto significa que la interfaz está ocupada enviando paquetes. Las colas no tienen lugar a menos que haya congestión en la interfaz. En algunos casos, el tamaño del anillo TX puede ser manipulado. Un pequeño anillo TX le da a la cola del software más poder en cuanto a qué paquetes se envían primero, pero no es muy efectivo. Un anillo TX demasiado grande haría que la cola del software fuera casi inútil y provocaría una mayor latencia y jitter para los paquetes importantes.

El algoritmo de cola predeterminado suele ser Primero en entrar, primero en salir (FIFO). Esto significa que los paquetes se entregan exactamente en el orden en que llegan a la entrada de la interfaz. Esto generalmente no es deseable porque algunos paquetes deben tener prioridad.

Es bastante común que un cliente compre un servicio de un proveedor de servicios de Internet (ISP) en una subvaloración. Es decir, el cliente compra un servicio de 50 Mbit / s pero la interfaz física funciona a 100 Mbit / s. En este caso no habrá congestión, pero el ISP limitará la cantidad de tráfico del cliente. Para introducir congestión artificial en estos casos, se puede aplicar un moldeador.

Entonces, ahora que hay congestión, se puede aplicar un algoritmo de colas. Tenga en cuenta que los algoritmos de colas no proporcionan ancho de banda adicional, solo nos permiten decidir qué paquetes son más importantes para nosotros. WFQ es un algoritmo que toma varios parámetros y toma una decisión basada en eso. El algoritmo es bastante complejo y utiliza el peso (precedencia de IP), el tamaño del paquete y el tiempo de programación como parámetros. Aquí hay una explicación muy detallada del INE . WFQ es una buena opción si uno no quiere jugar demasiado con las colas, ya que proporciona un ancho de banda adecuado para flujos de pequeño tamaño como SSH, Telnet, voz y eso significa que una transferencia de archivos no robará todo el ancho de banda.

La detección precoz aleatoria ponderada (WRED) es un mecanismo para evitar la congestión. WRED mide el tamaño de las colas en función del valor de precedencia y comienza a descartar paquetes cuando la cola está entre el umbral mínimo y el umbral máximo. La configuración decidirá que se descarte 1 de cada N paquetes. WRED ayuda a prevenir la sincronización TCP y el hambre TCP. Cuando TCP pierde paquetes, comenzará lentamente y si todas las sesiones TCP pierden paquetes al mismo tiempo, podrían sincronizarse, lo que proporciona un gráfico como este:

Como se puede ver si WRED no está configurado, el gráfico se dispara completamente, luego se silencia, luego se dispara y así sucesivamente. WRED proporciona una velocidad de transmisión más promedio. Es importante tener en cuenta que UDP no se ve afectado por la caída de paquetes porque no tiene un mecanismo de reconocimiento y una ventana deslizante implementada como TCP. Por lo tanto, WRED no debe implementarse en una clase basada en UDP como una clase que maneja SNMP, DNS u otros protocolos basados ​​en UDP.

Tanto WFQ como WRED pueden y deben implementarse juntos.

Antes que nada, no creas todo lo que lees en Internet ;-)

A veces, los algoritmos (o la forma en que se implementan físicamente) no encajan perfectamente en una categoría teórica. Lo que llamas es menos importante que entender lo que hace.

El objetivo de WFQ (o cualquier otro algoritmo de programación) es compartir el ancho de banda de enlace limitado entre los diversos flujos. WFQ intenta asignar el ancho de banda proporcionalmente a cada flujo. CBWFQ hace lo mismo con cada "clase". En un mundo perfecto, con colas ilimitadas y memoria ilimitada, eso sería todo lo que necesita: comparte el ancho de banda y todos están felices.

Pero debido a que los dispositivos no tienen colas y memoria ilimitadas, se deben hacer algunos "atajos". Debido a que una cola tiene un tamaño limitado, existe el peligro de que la cola se llene, causando caídas de cola y sincronización de tráfico. Esencialmente, si mi cola se desborda, ya no estoy controlando el ancho de banda.

Para evitar que mis colas se desborden, uso la detección temprana aleatoria. Este algoritmo descarta aleatoriamente los paquetes de la cola de acuerdo con su nivel (profundidad): cuanto más llena sea la cola, más paquetes se descartarán. El objetivo es evitar que la cola se desborde, de modo que el algoritmo de programación pueda funcionar.

Luego, un ingeniero brillante de Cisco notó que uno podía usar menos colas (hardware más simple) y soltar aleatoriamente diferentes tipos de tráfico a diferentes profundidades de cola. WRED elimina el tráfico de la cola a diferentes profundidades según el tipo de tráfico. Aunque podría llamar a WRED un mecanismo para evitar la congestión, ya que la profundidad donde se cae el tráfico varía con el tipo de tráfico, el efecto es que los diferentes tipos obtienen menos espacio en la cola y, por lo tanto, menos ancho de banda. Por lo tanto, también actúa como un algoritmo de programación. Dices po-tay-to y yo digo po-tah-toe.

Una diferencia más: FQ y WFQ funcionan en todos los tipos de tráfico, ya que esencialmente cuentan los bytes. RED y WRED solo funcionan con TCP, porque dependen del mecanismo de control de flujo de TCP para ralentizar el tráfico y evitar que la cola se desborde.

(Nota: en aras de la explicación, estoy ignorando las colas de prioridad y LLQ. Esa es otra respuesta).

Estoy de acuerdo con todo lo que Mike dijo también.

Aquí hay un ejemplo de CBWFQ y WRED:

mapa de políticas OUT

clase Voz
prioridad por ciento 20

clase Video
ancho de banda por ciento 30

ancho de banda de clase P1 por ciento 10
detección
aleatoria basada en dscp detección aleatoria dscp af31 26 40 10

ancho de banda de clase P2 por ciento 15
detección aleatoria detección basada
en dscp detección aleatoria dscp af21 24 40 10

clase class-default
fair-queue
random-detect basado en dscp