Artículo:
TCP-like Congestion Control for Layered Multicast Data Transfer
Autores: Lorenzo Vicisano, Jon Crowcroft
En este documento se presenta un nuevo algoritmo de control de congestión adecuado para utilizar con flujos de datos en capas acumuladas en el MBone (IP Multicast Backbone). Este algoritmo se comporta de manera similar a los algoritmos de control de congestión de TCP, y comparte ancho de banda de forma justa con las demás instancias del protocolo y con flujos TCP, es enteramente receptor impulsado y no requiere el receptor el estado del remitente, en ordenar a escala a un gran número de receptores. Se basa en funcionalidades estándar de enrutadores de multidifusión, y es adecuado para la corriente continua y fiable la transferencia de datos.
En el documento se muestra el algoritmo, se caracteriza su respuesta a pérdidas tanto analítica como por las simulaciones, y se analiza su comportamiento mediante simulaciones y experimentos en redes reales. También se muestra que la recuperación puede ser tratada independientemente del control de la congestión mediante el uso Técnicas FEC, a fin de proporcionar la transferencia masiva de datos fiable.
Introducción
El diseño de uno a muchos protocolos de transferencia de datos que se ejecutan en la parte superior del servicio de multidifusión de Internet tienen que enfrentar el problema fundamental de control de congestión. La red es compartida por muchos usuarios que compiten y los flujos incontrolados y agresivos pueden llevar la red a un colapso de la congestión. Para evitar esto, las instancias del protocolo deben comportarse de tal manera para lograr una distribución equitativa de los recursos de red con las instancias de otros protocolos de buen comportamiento. Al mismo tiempo, en los protocolos de multidifusión, y de control eficaz de la congestión no debe ir en detrimento de la escalabilidad, ya que se desea abordar escenarios que comprenden miles de receptores.
El problema esta siendo cada vez más y más importante con la aumento de la difusión de las herramientas multimedia intensivas de banda ancha para vídeo y audioconferencia, que estimulan el uso de la red para llegar a grandes grupos heterogéneos, de los usuarios. para estas aplicaciones, las técnicas que se han propuesto para la transmisión de la misma corriente el uso de múltiples tipos de datos (que tiene diferentes niveles de calidad) sobre la base de una capa acumulada de organización de los datos. Mediante el uso de arreglos de datos apropiados, un enfoque puede ser usado para la transferencia fiable de datos.
El requisito de ser un competidor justo con otros protocolos de buen comportamiento, tales como TCP complica aún más el problema de la elaboración de un algoritmo adecuado que permita a los receptores elegir dinámicamente la velocidad de datos adecuada.
En este artículo se va a describir una congestión impulsada por el receptor algoritmo de control que es TCP y es adecuado para su uso en el Mbone. Se apoyan diferentes anchos de banda mediante una capa organización de los datos, y se deja que los receptores se adapten a la disposición de ancho de banda mediante la unión a uno o más grupos de multidifusión. Cada receptor toma decisiones de manera autónoma, pero las técnicas se utilizan para sincronizar receptores detrás del mismo cuello de botella (y que pertenecen a la misma instancia de protocolo), y para lograr un uso eficaz del ancho de banda. El algoritmo es completamente escalable y fácil de implementar, tanto en el emisor y en el lado del receptor.
Relación entre el rendimiento y la tasa de pérdida
Las redes IP no tienen un mecanismo de notificaciones de congestión explícita. La respuesta a esta congestión hace que caigan paquetes, y ocasionan la pérdida de uno o más paquetes y el receptor informa al remitente donde se interpreta como una señal de congestión.
Un algoritmo de control de congestión debe reaccionar a señales de congestión mediante la reducción de la velocidad de transmisión.
La relación entre la tasa de pérdida de paquetes y el rendimiento, T, de una sesión de buen comportamiento es tal que incrementa los valores de p correspondientes a decrementar los valores de T. Para el algoritmo de control de congestión usado en TCP varios autores han llegado a la siguiente relación entre el rendimiento y la perdida de paquetes.
en donde la s es el tamaño del paquete, RTT es el tiempo de ida y vuelta para la sesión y la constante c esta en el rango 0.9...1.5. La relación es válida para pequeños valores de p, a altas tasas de pérdida, TCP tiende a perder su reloj auto ACK-basado, la sesión asume un caótico comportamiento y el rendimiento real tiene una disminución brusca y se convierte altamente dependiente de la longitud de la retransmisión tiempos de espera.
La pasada ecuación muestra que en presencia de tras el mismo cuello de botella (experimentando así una tasa de pérdida similar), la proporción real del ancho de banda depende de s y RTT.
Aparte de esta diferencia, compiten sesiones TCP para reducir su rendimiento de manera similar en la respuesta a las pérdidas. La equidad entre los diferentes protocolos requiere que todos ellos tengan un comportamiento similar en la respuesta a perdidas, y que sean comparables los valores absolutos de rendimiento y tiempos de respuesta.
La ecuación mostrada no captura completamente el comportamiento del sistema de control. Otro parámetro importante de cualquier algoritmo de control es la velocidad de respuesta a las variaciones en el sistema controlado en este caso condiciones de la red. Para el control de congestión del TCP, este tiempo de respuesta es del orden de RTT de la sesión que es el tiempo requerido para el remitente para recibir la retroalimentación y reaccionar.
Pertenencia a un grupo de multidifusión
La transmisión de datos de multidifusión en el Mbone es implementado por los routers de multidifusión, que se comunican con los hosts que utilizan un protocolo de pertenencia a un grupo dedicado, IGMP.
Los paquetes para un grupo multicast se presentan, en un segmento de red sólo si ese segmento conduce a receptores activos para ese grupo (ser nodos finales u otros routers multicast sirven para receptores activos).
En la fase de unión, un receptor que se une a un nuevo grupo envía una
Mensaje IGMP al router, que a su vez activa el reenvío para ese grupo, la propagación de la información a la enrutador de aguas arriba (mensaje del injerto). La fase de unión es rápida, teniendo aproximadamente un RTT (calculado entre el nodo de unión y el primer router hacia la fuente que está bloqueando el grupo).
En la fase de permiso, un receptor informa a su router local que no está interesado en el grupo. Esto desencadena una fase en la que comprueba el router multicast si otros receptores en la subred local todavía están interesados en el grupo. Si no existen receptores activos, el router envía un mensaje para que el grupo y el enrutador de multidifusión bloque el reenvío para ese grupo. Dado que la ausencia de receptores activos sólo se puede determinar después de un tiempo de espera, la fase de licencia puede tardar mucho tiempo tiempo (unos segundos) lo que se llamamos demora de licencia.
Organización en capas de los datos
El protocolo de control de congestión se dirige a la distribución de los mismos datos (posiblemente, con diferente calidad) a un conjunto de receptores con diferentes anchos de banda, aumentando el ancho de banda. Suele ser factible para los flujos de datos multimedia, para los datos tales como un archivo y minimiza repeticiones.
Control de congestión para la capa de datos
El mecanismo de control de congestión está diseñado por un transmisor de envío de datos a muchos receptores en el Mbone. La comunicación puede implicar una corriente continua (por ejemplo, vídeo o audio datos), o una, de transferencia de datos mayor fiable (por ejemplo, un archivo). En esta sección se ignoran los paquetes que tenga que ser retransmitidos a fin de completar una transferencia de datos.
En las comunicaciones de unidifusión, el remitente toma parte de el control de congestión con señales de congestión de acuerdo a lo que recibe. En las comunicaciones multicast, este enfoque sería problemático, ya que los grupos de receptores pueden tener diferentes requisitos, y la adaptación a las necesidades de un conjunto de receptores penalizaría a los demás con los requisitos de contraste.
Adaptación a los requisitos heterogéneos se hace posible (y simple), ya que puede hacerse de forma independiente en cada uno subárbol servido por un router multicast. Como consecuencia de este enfoque, el transmisor no necesita ni siquiera tomar parte en el control de la congestión (excepto para el uso de una organización de los datos en capas).
En este algoritmo, los receptores conocen el estado de la red con señales de congestión (por lo general, las pérdidas de paquetes), y de control de flujo de datos de entrada utilizando la capacidad de enrutamiento multicast IP. Cada receptor se une o deja capas dependiendo de las señales de congestión recibidos. La estrategia para unirse o abandonar capas se elige de tal manera para emular el comportamiento de TCP y generar una relación similar entre el rendimiento y la tasa de pérdida.
Puntos de sincronización
Con más de un receptor detrás de un cuello de botella, la sincronización entre los receptores es fundamental con el fin de hacer que el mecanismo de trabajo funcione correctamente. De hecho:
- la acción de un receptor de dejar caer una capa (dejando un grupo) no tiene ningún efecto a menos que todos los receptores compartan la caída de cuello de botella esa capa;
- si un receptor provoca congestión en la capa nueva, algún otro receptor puede interpretar los resultados como consecuencia de su nivel demasiado alto de suscripción y y soltar una capa;
- si dos receptores detrás del mismo cuello de botella tienen diferentes niveles de suscripción, el cuello de botella del ancho de banda asignado a esa instancia del protocolo no se aprovecha plenamente;
Todos estos problemas pueden reducirse al mínimo si los intentos de unirse a diferentes receptores están coordinados.
Se ha evitado la introducción de un protocolo explícito para la coordinación receptor, ya que puede tener problemas de usabilidad, y podría ser lento.
Los problemas descritos en la sección anterior se agravan aún más por la duración de la demora, lo que hace un intento de unión y tiene consecuencias sobre la red durante mucho tiempo. Por otra parte, como una optimización del algoritmo, se debería ser capaz de aumentar el nivel de suscripción sólo cuando hay confianza de que el intento pueda tener éxito.
Diferencias con TCP
Aunque el algoritmo intenta imitar el comportamiento de control de la congestión TCP hay algunas diferencias entre los comportamientos de los dos algoritmos.
En primer lugar, con el algoritmo propuesto, los rendimientos relativos de las sesiones en competencia que experimentan el mismo tipo de pérdida no depende de la "distancia" (RTT) entre el emisor y el receptor. Entonces, el control de congestión de TCP tiene lo que puede aparecer como un grado de falta de equidad, en el que el rendimiento es inversamente proporcional al RTT. De hecho, ambos enfoques son apropiados y tienen diferentes objetivos:
En TCP, el control de congestión es controlado completamente por el remitente, y la única forma en que el receptor tiene que reducir el rendimiento es retrasar la generación de acuses de recibo, por lo que el RTT parece ser más grande de lo que realmente es. Además, las conexiones con mayor RTT son menos sensibles que aquellos con un RTT más corto, para ambos casos, es más que aceptable ese ancho de banda.
Conclusión
Se ha explicado un algoritmo de control de congestión para la transferencia de datos de multidifusión en la MBone, evaluado su desempeño y demostrado su aplicabilidad en corriente continua y la transferencia de mayor confianza. El algoritmo no requiere de apoyo del enrutador, o por el estado del emisor, sino que es completamente controlado por el receptor, y no se basa en cualquier protocolo explícito para la sincronización del receptor o la gestión de pertenencia al grupo. Los resultados analíticos, simulaciones y experimentos en redes reales han demostrado que el algoritmo para lograr un reparto equitativo de la anchura de banda de cuello de botella con otras instancias del protocolo y con instancias TCP.
Este algoritmo es bastante óptimo ya que no toma en cuenta al enrutador y ni el emisor, si no todo es controlado por el receptor además no se basa solamente en protocolos para la sincronización del receptor si no toma en cuenta algunos otras medidas de calidad. Sería interesante programar en NS3 algo que simulara un comportamiento parecido para poder ver las estadísticas más a detalle y compararlo directamente con el TCP original.
Referencias
