Leí el artículo original PostScript SIGCOMM '97 sobre HFSC, es muy técnico, pero entiendo el concepto básico. En lugar de proporcionar una curva de servicio lineal (como ocurre con casi cualquier otro algoritmo de programación), puede especificar una curva de servicio convexa o cóncava y, por lo tanto, es posible desacoplar el ancho de banda y el retraso. Sin embargo, aunque este documento menciona el tipo de algoritmos de programación que se utilizan (en tiempo real y compartir enlaces), siempre menciona UNA curva por clase de programación (el desacoplamiento se realiza especificando esta curva, solo se necesita una curva para eso )
Ahora se ha implementado HFSC para BSD (OpenBSD, FreeBSD, etc.) usando el marco de programación ALTQ y se ha implementado Linux usando el marco de programación TC (parte de iproute2). Ambas implementaciones agregaron dos curvas de servicio adicionales, que NO estaban en el documento original. Una curva de servicio en tiempo real y una curva de servicio de límite superior. Nuevamente, tenga en cuenta que el documento original menciona dos algoritmos de programación (en tiempo real y compartir enlaces), pero en ese documento ambos trabajan con una sola curva de servicio. Nunca ha habido dos curvas de servicio independientes para ninguna de las dos, como se encuentra actualmente en BSD y Linux.
Peor aún, alguna versión de ALTQ parece agregar una prioridad de cola adicional a HSFC (tampoco hay prioridad en el documento original). Encontré varios BSD HowTo que mencionan esta configuración de prioridad (aunque la página de manual de la última versión de ALTQ no conoce dicho parámetro para HSFC, por lo que oficialmente ni siquiera existe).
Todo esto hace que la programación HFSC sea aún más compleja que el algoritmo descrito en el documento original y hay toneladas de tutoriales en Internet que a menudo se contradicen entre sí, uno afirmando lo contrario del otro. Esta es probablemente la razón principal por la que nadie parece entender realmente cómo funciona realmente la programación HFSC. Antes de poder hacer mis preguntas, necesitamos una configuración de muestra de algún tipo. Usaré uno muy simple como se ve en la imagen a continuación:
texto alternativo http://f.imagehost.org/0177/hfsc-test-setup.png
Aquí hay algunas preguntas que no puedo responder porque los tutoriales se contradicen entre sí:
¿Para qué necesito una curva en tiempo real? Suponiendo que A1, A2, B1, B2 son todos compartidos de enlace de 128 kbit / s (sin curva en tiempo real para ninguno de los dos), entonces cada uno de ellos obtendrá 128 kbit / s si la raíz tiene 512 kbit / s para distribuir (y A y B son ambos 256 kbit / s, por supuesto), ¿verdad? ¿Por qué adicionalmente le daría a A1 y B1 una curva en tiempo real con 128 kbit / s? ¿Para qué sería bueno esto? ¿Darles a esos dos una mayor prioridad? De acuerdo con el documento original, puedo darles una mayor prioridad al usar una curva , de eso se trata HFSC después de todo. Al dar a ambas clases una curva de [256kbit / s 20ms 128kbit / s], ambas tienen el doble de prioridad que A2 y B2 automáticamente (todavía solo obtienen 128 kbit / s en promedio)
¿El ancho de banda en tiempo real cuenta para el ancho de banda de enlace compartido? Por ejemplo, si A1 y B1 solo tienen 64 kbit / s en tiempo real y 64 kbit / s de ancho de banda de enlace compartido, eso significa que una vez que reciben 64 kbit / s en tiempo real, su requisito de enlace compartido también se cumple (podrían obtener un ancho de banda en exceso, pero ignoremos eso por un segundo) o eso significa que obtienen otros 64 kbit / s a través del enlace compartido? Entonces, ¿cada clase tiene un "requisito" de ancho de banda de tiempo compartido más enlace compartido? ¿O una clase solo tiene un requisito más alto que la curva en tiempo real si la curva de enlace compartido es más alta que la curva en tiempo real (el requisito actual de compartir enlace es igual al requisito de compartir enlace especificado menos el ancho de banda en tiempo real ya proporcionado para esto) clase)?
¿La curva de límite superior se aplica también en tiempo real, solo para compartir enlaces, o tal vez para ambos? Algunos tutoriales dicen de una manera, otros dicen la otra. Algunos incluso afirman que el límite superior es el máximo para ancho de banda en tiempo real + ancho de banda de enlace compartido. ¿Cuál es la verdad?
Suponiendo que A2 y B2 son 128 kbit / s, ¿hace alguna diferencia si A1 y B1 son solo 128 kbit / s de enlace compartido, o 64 kbit / s en tiempo real y 128 kbit / s de enlace compartido, y si es así? , ¿Qué diferencia?
Si uso la curva separada en tiempo real para aumentar las prioridades de las clases, ¿por qué necesitaría "curvas"? ¿Por qué no es en tiempo real un valor fijo y compartir enlaces también es un valor fijo? ¿Por qué son ambas curvas? La necesidad de curvas es clara en el documento original, porque solo hay un atributo de ese tipo por clase. Pero ahora, teniendo tres atributos (tiempo real, enlace compartido y límite superior), ¿para qué necesito curvas en cada uno? ¿Por qué querría que la forma de las curvas (no el ancho de banda promedio, sino sus pendientes) sean diferentes para el tráfico en tiempo real y de enlace compartido?
Según la poca documentación disponible, los valores de las curvas en tiempo real se ignoran por completo para las clases internas (clase A y B), solo se aplican a las clases hoja (A1, A2, B1, B2). Si eso es cierto, ¿por qué la configuración de muestra ALTQ HFSC (búsqueda de configuración de muestra 3.3 ) establece curvas en tiempo real en clases internas y afirma que esas establecen la tasa garantizada de esas clases internas? ¿No es eso completamente inútil? (nota: pshare establece la curva de enlace compartido en ALTQ y ralla la curva en tiempo real; puede ver esto en el párrafo sobre la configuración de muestra).
Algunos tutoriales dicen que la suma de todas las curvas en tiempo real no puede ser superior al 80% de la velocidad de la línea, otros dicen que no debe ser superior al 70% de la velocidad de la línea. ¿Cuál está bien o quizás ambos están equivocados?
Un tutorial decía que olvidarás toda la teoría. No importa cómo funcionan realmente las cosas (planificadores y distribución de ancho de banda), imagine las tres curvas de acuerdo con el siguiente "modelo mental simplificado": el ancho de banda garantizado que siempre obtendrá esta clase en tiempo real. link-share es el ancho de banda que esta clase quiere satisfacer por completo, pero la satisfacción no puede garantizarse. En caso de que haya un exceso de ancho de banda, la clase podría incluso recibir más ancho de banda del necesario para estar satisfecho, pero es posible que nunca use más de lo que dice el límite superior. Para que todo esto funcione, la suma de todos los anchos de banda en tiempo real puede no ser superior al xx% de la velocidad de la línea (consulte la pregunta anterior, el porcentaje varía). Pregunta: ¿Es esto más o menos exacto o un malentendido total de HSFC?
Y si la suposición anterior es realmente precisa, ¿dónde está la priorización en ese modelo? Por ejemplo, cada clase puede tener un ancho de banda en tiempo real (garantizado), un ancho de banda de enlace compartido (no garantizado) y quizás un límite superior, pero aún algunas clases tienen necesidades de mayor prioridad que otras clases. En ese caso, todavía debo priorizar de alguna manera, incluso entre el tráfico en tiempo real de esas clases. ¿Priorizaría por la pendiente de las curvas? Y si es así, ¿qué curva? La curva en tiempo real? La curva de enlace compartido? La curva de límite superior? ¿Todos ellos? ¿Les daría a todos la misma pendiente o una diferente y cómo encontrar la pendiente correcta?
Todavía no he perdido la esperanza de que exista al menos una mano llena de personas en este mundo que realmente entiendan HFSC y puedan responder a todas estas preguntas con precisión. Y hacerlo sin contradecirse en las respuestas sería realmente bueno ;-)
Respuestas:
Leer los documentos sobre HFSC y sus primos no es una buena forma de entenderlo. El objetivo principal del documento HFSC es proporcionar una prueba matemática rigurosa de sus afirmaciones, sin explicar cómo funciona. De hecho, no puede entender cómo funciona solo desde el documento HFSC, también debe leer los documentos a los que hace referencia. Si tiene algún problema con el reclamo o sus pruebas, puede ser una buena idea ponerse en contacto con los autores de los documentos, de lo contrario dudo que estén interesados en saber de usted.
He escrito un tutorial para HFSC . Léalo si mis explicaciones a continuación no son claras.
La curva en tiempo real y la curva de intercambio de enlaces se evalúan de diferentes maneras. La curva en tiempo real tiene en cuenta lo que ha hecho una clase a lo largo de toda su historia. Debe hacerlo para proporcionar una asignación precisa de ancho de banda y latencia. La desventaja no es lo que la mayoría de las personas intuitivamente considera justo . En tiempo real, si una clase toma prestado el ancho de banda cuando nadie más lo quiere, se penaliza cuando alguien más lo quiere más tarde. Esto significa que, bajo la garantía en tiempo real, una clase no puede obtener ancho de banda durante un período prolongado porque lo usó antes, cuando nadie lo quería.
El intercambio de enlaces es justo, ya que no penaliza a una clase por usar ancho de banda adicional. Sin embargo, esto significa que no puede proporcionar fuertes garantías de latencia.
La separación de compartir enlaces de proporcionar garantías de latencia es lo nuevo que HFSC trae a la mesa, y el documento dice tanto en su oración de apertura: en este documento, estudiamos modelos jerárquicos de gestión de recursos y algoritmos que admiten tanto el intercambio de enlaces como la garantía Servicios en tiempo real con retraso desacoplado (prioridad) y asignación de ancho de banda. La palabra clave en esa oración está desacoplada. Traducido, significa que se espera que usted diga cuán ancho de banda no utilizado se va a compartir con ls, y especifique qué garantías en tiempo real (también conocidas como garantías de latencia) se necesitan con rt. Los dos son ortogonales.
Sí. En el documento HFSC definen el ancho de banda en términos de lo que la clase ha enviado desde que la clase se ha atrasado (es decir, tiene paquetes en espera de ser enviados). La única diferencia entre rt y ls es que rt espera cada vez que la clase se atrasa y calcula el ancho de banda más bajo garantizado de ese conjunto, mientras que el intercambio de enlaces solo se ve desde la última vez que la clase se atrasó. Entonces rt toma más bytes en consideración que ls, pero cada byte que ls considera también es considerado por rt.
El límite superior no impide que se envíen paquetes para satisfacer la condición en tiempo real. Los paquetes enviados bajo la condición de tiempo real todavía cuentan para el límite superior y, por lo tanto, pueden retrasar el envío de un paquete bajo la condición de compartir enlaces en el futuro. Esta es otra diferencia entre tiempo real y compartir enlaces.
Sí, hace la diferencia. Como se explicó anteriormente si usa el tiempo real, las latencias están garantizadas pero el enlace no se comparte de manera justa (y en particular la clase podría sufrir el hambre de ancho de banda), y los límites superiores no se aplican. Si utiliza el enlace compartido, la latencia no está garantizada, pero el enlace compartido es justo, no hay riesgo de inanición y se aplica el límite superior. El tiempo real siempre se verifica antes del enlace compartido, sin embargo, esto no significa necesariamente que se ignore el enlace compartido. Eso es porque los paquetes se cuentan de manera diferente. Dado que el historial se considera en tiempo real, puede que no sea necesario un paquete para cumplir con la garantía en tiempo real (debido a uno incluido en el historial), pero es necesario para satisfacer el intercambio de enlaces porque ignora el paquete histórico.
La curva para controles en tiempo real le permite cambiar la latencia ajustada para una clase de tráfico particular (por ejemplo, VOIP) por una latencia deficiente para otras clases de tráfico (por ejemplo, correo electrónico). Al decidir qué paquete enviar bajo la restricción de tiempo real, HFSC elige el que completará el envío primero. Sin embargo, no usa el ancho de banda del enlace para calcular esto, usa el ancho de banda asignado por la curva en tiempo real. Por lo tanto, si tenemos VOIP y paquetes de correo electrónico de la misma longitud, y el paquete VOIP tiene una curva convexa que da un aumento de 10 veces sobre la curva cóncava para el correo electrónico, entonces se enviarán 10 paquetes VOIP antes del primer paquete de correo electrónico. Pero esto solo ocurre durante el tiempo de ráfaga, que debería ser como máximo el tiempo que lleva enviar algunos paquetes, es decir, milisegundos. A partir de entonces, la curva VOIP debería aplanarse, y VOIP no recibirá un impulso futuro a menos que retroceda por un tiempo (que, dado que VOIP es una aplicación de bajo ancho de banda, debería). El resultado neto de todo esto es garantizar que los primeros dos paquetes de VOIP se envíen más rápido que cualquier otra cosa, lo que le da a VOIP una baja latencia a expensas de que el correo electrónico obtenga una alta latencia.
Como dije anteriormente, debido a que el enlace compartido no mira el historial, no puede dar garantías de latencia. Una garantía sólida es lo que se necesita para el tráfico en tiempo real como VOIP. Sin embargo, en promedio, una curva convexa compartida de enlace aún proporcionará un impulso de latencia a su tráfico. Simplemente no está garantizado. Eso está bien para la mayoría de las cosas, como el tráfico web por correo electrónico.
La documentación es correcta. La jerarquía (y, por lo tanto, los nodos internos) no tiene ningún efecto en el cálculo del tiempo real. No puedo decirte por qué ALTQ evidentemente cree que sí.
Ambos están equivocados. Si el 70% o el 80% de su tráfico tiene requisitos de latencia dura que deben especificarse en tiempo real, la realidad es que es casi seguro que no puede satisfacerlos con el enlace que está utilizando. Necesitas un enlace más rápido.
La única forma en que alguien podría pensar que especificar el 80% del tráfico debería ser en tiempo real es si estuviera pisando en tiempo real como un impulso prioritario. Sí, para proporcionar garantías de latencia, en realidad está aumentando la prioridad de algunos paquetes. Pero solo debería ser por milisegundos. Eso es todo lo que un enlace puede hacer frente y aún proporcionar las garantías de latencia.
Hay muy poco tráfico que necesita garantías de latencia. VoIP es uno, NTP otro. El resto debe hacerse con el intercambio de enlaces. Si desea que la web sea rápida, puede hacerlo rápidamente asignándole la mayor parte de la capacidad de los enlaces. Esa participación está garantizada a largo plazo. Si desea que sea de baja latencia (en promedio), déle una curva convexa en el enlace compartido.
Es una buena descripción límite superior. Si bien la descripción del enlace compartido es estrictamente precisa, es engañosa. Si bien es cierto que el enlace compartido no brinda las garantías de latencia dura como lo hace en tiempo real, hace un mejor trabajo al asignar a la clase su ancho de banda que a sus competidores, como CBQ y HTB. Entonces, al decir que el recurso compartido de enlace "no proporciona garantías", lo mantiene en un estándar más alto que cualquier otro programador puede proporcionar.
La descripción en tiempo real logra ser precisa, pero tan engañosa que lo llamaría incorrecto. Como su nombre lo indica, el propósito en tiempo real no es dar ancho de banda garantizado. Es para proporcionar latencia garantizada, es decir, el paquete se envía AHORA, no una cantidad de tiempo aleatorio más tarde, dependiendo de cómo se use el enlace. La mayoría del tráfico no necesita latencia garantizada.
Dicho esto, el tiempo real tampoco ofrece garantías de latencia perfectas. Podría, si el enlace no se gestionó también mediante el intercambio de enlaces, pero la mayoría de los usuarios desean la flexibilidad adicional de tener ambos y no es gratis. El tiempo real puede perder su fecha límite de latencia para el tiempo que lleva enviar un paquete MTU. (Si sucede, se debe a que se trata de un paquete compartido de enlace de MTU que se coló en tiempo real, manteniendo el enlace inactivo en caso de que se le entregara un paquete con una fecha límite corta que debía enviarse de inmediato. Esta es otra diferencia más entre el enlace compartido y en tiempo real. Con el fin de proporcionar sus garantías, el tiempo real puede mantener deliberadamente inactiva la línea aunque haya paquetes para enviar, por lo que se proporciona menos del 100% de la utilización del enlace. El recurso compartido de enlaces siempre utiliza el 100% de la capacidad disponible de los enlaces. A diferencia del tiempo real ,
La razón por la que se puede decir que el tiempo real ofrece garantías de latencia dura es que el retraso está limitado. Entonces, si está tratando de ofrecer una garantía de latencia de 20 ms en un enlace de 1 Mbit / seg, y el recurso compartido de enlace está enviando paquetes de tamaño MTU (1500 bytes), sabe que uno de esos paquetes tardará 12 ms en enviarse. Por lo tanto, si le dice en tiempo real que desea una latencia de 8 ms, aún puede cumplir el plazo de 20 ms, con una garantía absoluta.
No hay un modelo de priorización. Seriamente. Si desea dar prioridades absolutas al tráfico, use pfifo. Esto es para lo que sirve. Pero también ten en cuenta que si se le da el tráfico de Internet prioridad absoluta sobre el tráfico de correo electrónico, que significa dejar que el tráfico web saturar el enlace y por lo tanto no hay paquetes de correo electrónico conseguir a través, en absoluto . Todas sus conexiones de correo electrónico mueren.
En realidad, nadie quiere ese tipo de priorización. Lo que quieren es lo que proporciona HFSC. Si realmente tiene tráfico en tiempo real, HFSC lo proporciona. Pero serán cosas de todo. Por lo demás, HFSC le permite decir "en un enlace congestionado, asignar el 90% a la web y dejar que el correo electrónico gotee al 10% y enviar el paquete DNS extraño rápidamente, pero no permita que alguien me envíe DOS".
fuente
Podría definir las curvas con diferentes nombres:
Cuando realiza una definición en HFSC solo con tasas, establece automáticamente 'dmax' en 0. Lo que básicamente significa que no tiene en cuenta el retraso. Una buena configuración HFSC debe incluir tanto el ancho de banda como los límites de retardo que desea usar para su clase, de lo contrario, el algoritmo no puede determinar exactamente cuánta prioridad debería tener una clase.
Cada vez que le dé prioridad a los paquetes, otros paquetes tendrán que reducirse en prioridad. Basado en los valores 'dmax' y 'rate', todas las clases se multiplexarán usando temporizadores virtuales. Consulte tc-hfsc (7) para obtener más información.
Si el flujo no supera los límites de la definición de enlace compartido de la clase, entonces la curva en tiempo real nunca se utiliza. Definir una curva en tiempo real en este caso le permite, por ejemplo: garantizar un cierto 'dmax'.
Si sus definiciones de enlace compartido son perfectas, entonces no necesitaría curvas en tiempo real. Simplemente podría definir curvas de servicio (sc), pero eso haría que su configuración trabaje más.
La curva de límite superior de su clase se aplica solo al enlace compartido, cuando define una curva de límite superior DEBE definir una curva de enlace compartido. Sin embargo, la curva de límite superior de las clases principales todavía se aplica.
Hay una ligera diferencia, por ejemplo, A2 = 0 kbits / sy B2 = 256 kbits / s. Entonces, el tiempo virtual para A2 será máximo. Siempre que los paquetes se clasifiquen en A2, se procesarán instantáneamente. Sin embargo, la curva en tiempo real de B2 seguirá garantizando que sea capaz de transmitir al menos 64 kbit / s
Las curvas en tiempo real no comparten el tráfico entre las hojas vecinas, las curvas de enlace compartido sí.
Es cierto que las curvas en tiempo real se ignoran para las clases internas, solo se aplican a las clases hoja. Sin embargo, las curvas en tiempo real definidas en esas clases internas se tienen en cuenta para los cálculos en las clases de hoja.
Lo que significan es: no se puede priorizar todo el tráfico ... Siempre que le dé prioridad a los paquetes, otros paquetes tendrán que disminuir en prioridad. Si sobre-garantizas, el algoritmo se vuelve inútil. Defina la clase que gana prioridad y defina las clases que pueden sufrir.
Esto es correcto.
La diferencia entre, por ejemplo, HFSC y HTB es que HFSC le permitirá definir exactamente cuánta priorización desea que tenga. Para ello, defina límites mínimos y máximos con el valor 'dmax'.
fuente
Finalmente, una guía que parece explicar la mayoría de las inconsistencias y también cómo la implementación actual es diferente del documento original:
http://manpages.ubuntu.com/manpages/precise/man7/tc-hfsc.7.html
De acuerdo con esta guía, muchas otras guías y publicaciones en foros sobre HFSC no tienen ningún sentido; solo muestra cuán complicado es HFSC, ya que muchas personas que parecen ser expertas y pretenden comprender completamente HFSC, de hecho, tienen un conocimiento parcial y hacen declaraciones falsas basadas en un malentendido del concepto y cómo todos esos ajustes juegan juntos.
Creo que finalmente me rendiré con HFSC. Si puede configurar correctamente su HFSC, puede ser la mejor QoS que pueda obtener, pero las posibilidades de que se equivoque completamente son mucho mayores que las posibilidades de tener éxito.
fuente
Si no puede localizar a los autores originales, intentaré esto a continuación:
También intente verificar otros documentos más nuevos que citan este. Es posible que haya documentos más recientes que continúen la investigación en esta área y que puedan incluir más información sobre las preguntas que hace.
fuente