Para ésta semana continuamos con los temas de lecturas científicas, ahora el tema es referente a mecanismos de control de congestión, el documento seleccionado fue:
...
RAP: An End-to-end Rate-based Congestion Control Mechanism for Realtime
Streams in the Internet
Reza Rejaie, Mark Handley, Deborah Estrin
University of Southern California
Information Sciences Institute
Marina Del Rey, CA 90292
{ reza, mjh, estrin} @ isi.edu
...
1. Introducción
El Internet ha venido experimentando un aumento explosivo en el uso de aplicaciones de stream de audio y video. Dichas aplicaciones son bastante sensitivas a retrasos, cambios en las tasas de transferencia y necesitan tener un buen grado de confiabilidad, para esto se utilizan mecanismos QoS de punto a punto.
A pesar de todo esto, el Internet no garantiza bajos niveles de retrasos o un buen nivel de banda ancha disponible, por lo que el servicio provisto no es ni controlable ni predecible. Estas fallas en los mecanismos QoS no frenan el crecimiento de las aplicaciones de stream.
En redes compartidas, los sistemas reaccionan a las congestiones adaptando sus tasas de transferencia, para evitar que el sistema colapse; así mismo, adaptan su uso de banda ancha para que todos los flujos e información puedan coexistir sobre la misma conexión. Lo sistemas que toman estas medidas se conocen como "buenos ciudadanos".
La porción de tráfico dominante en Internet esta basado en TCP, por lo que es más viable implementar mecanismos de control de congestión que sean amigables con el entorno de dicho protocolo. Esto quiere decir que las aplicaciones de stream de datos deben tener la misma cantidad de banda ancha promedio sobre una sesión TCP que permanezca activa en el mismo camino y bajo las mismas condiciones de latencia y pérdida de paquetes.
Se hace uso de una arquitectura que se encarga de proveer streams codificados por capas y almacenados en Internet, el enfoque principal es el uso de un servidor web o de video bajo demanda que provea acceso a una gran variedad de contenido multimedia para un gran número de clientes. La meta es que las aplicaciones de reproducción en tiempo real sean buenos ciudadanos. La idea es separar el control del tráfico del control de errores porque el primero depende del estado de la red mientras que el segundo es especifico de la aplicación.
Las tasas de transferencia de los servidores son continuamente adaptadas por el protocolo RAP (Rate Adaptation Protocol), y dicho módulo es exclusivo para el control de congestiones y la detección de pérdidas. El gestor de capas adapta la calidad del stream transmitido de acuerdo a la tasa de transferencia especificada por el RAP y trata de enviar la mayor cantidad de capas posibles según la cantidad de banda ancha disponible. Durante un viaje de ida y vuelta algunas capas pueden perderse, por lo que se hace uso de un buffer en el lado del cliente para almacenarlas y ordenarlas temporalmente, así mismo, para hallar dónde faltan capas. El buffer ayuda a la retransmisión selectiva de capas las cuales son determinadas por el gestor de retransmisión. La banda ancha agregada utilizada por el servidor y por el gestor de retransmisión no debe exceder la banda ancha especificada por el RAP.
El paper presenta el diseño y evaluación del protocolo RAP a través de simulaciones, como método de control de congestión adecuado para aplicaciones unicast de streams en tiempo real, asi como para otras aplicaciones compatibles. La meta es lograr que RAP se comporte correctamente y se amigable en TCP.
2. Trabajos relacionados
El estudio de mecanismos de control de congestión no es nuevo, sin embargo, el estudio de mecanismos de control de congestión amigables con TCP en redes de mejor intento es un poco más limitado.
Una aproximación común para la adaptación de tasas de transferencia es utilizar métodos de codificación adaptativa mediante el ajuste de los parámetros de los codecs basándose en el estado de la red. Sin embargo, esto no es muy recomendable ya que hace un uso intensivo del CPU para codificar los diferentes streams de los diferentes clientes.
Existe, por ejemplo, el protocolo SCP que es una versión modificada de TCP que utiliza un método parecido al TCP-Vegas para adaptar las tasas de transferencia, sin embargo, SCP no es muy amigable con TCP, por lo que para TCP se basa en el RTT calculado (Round Trip delay time).
3. Protocolo RAP
El protocolo fue implementado desde el principio. Básicamente, el protocolo envía todos los paquetes numerados secuencialmente, el destino de los paquetes reconoce los paquetes lo que provee un sistema de retroalimentación en la comunicación. Cada mensaje ACK contiene una secuencia de números que corresponde con la información entregada por el paquete. Utilizando la retroalimentación, la fuente RAP puede detectar las pérdidas. Durante el diseño del mecanismo de adaptación, se hallaron 3 problemas:
a) Función de decisión
El esquema de adaptación se basa en 2 reglas simples
- Si no se detecta congestión, aumentar periódicamente la tasa de transferencia.
- Si se detecta congestión, reducir inmediatamente la tasa de transferencia.
El RAP utiliza los mensajes de pérdidas como señales de congestión, y los tiempos de espera y las separaciones en las secuencias para detectar las pérdidas.
Mantiene un RTT (round trip delay time) estimado, al igual que en TCP, llamado SRTT y calcula el timeout utilizando el algoritmo de Jacobson/Karel.
A diferencia de TCP, RAP puede enviar varios paquetes antes de recibir un nuevo ACK que permita recalcular el RTT estimado.
Para la deteccion de perdidas basado en ACK, RAP utiliza la misma intuición que el fast-recovery en TCP. Si una fuente RAP recibe un ACK, implica la entrega de tres paquetes después de perder uno.
b) Algoritmo de incremento/decremento
El algoritmo de incremento/reducción. En ausencia de pérdidas, la tasa de transferencia ira incrementándose en buena forma.
El algoritmo es controlado ajustando la separación entre paquetes, dicho ajuste depende de la tasa de transferencia y el tamaño del incremento, también depende de una constante de tiempo.
c) Frecuencia de decisión
Especifica que tan seguido se actualiza la tasa de transferencia. La frecuencia de ajuste optimo depende del delay en la retroalimentación. Los delays en la retroalimentación son iguales a un RTT. Esto sugiere que los esquemas basados en la tasa de transferencia no deben actualizarse mas de una vez por RTT, cambios muy frecuentes pueden causar oscilaciones inesperadas y ocasionar que el sistema no responda.
RAP realiza los ajustes una vez por SRTT. El tiempo entre dos ajustes es llamado step.
Pérdidas agrupadas
En una red compartida basada en el mejor esfuerzo con un alto nivel de multiplexing estadístico, se observa que el patrón de pérdidas se acerca mucho a un comportamiento aleatorio.
Ésto dificulta el control de las pérdidas ajustando solamente la tasa de transferencia.
RAP requiere de un mecanismo para identificar donde se concentran las pérdidas y saber si estan relacionadas a un mismo evento de congestión. La pérdida de un paquete resulta en un retroceso, los paquetes pendientes en la cola, llamada cluster, tienen un número de secuencia que se enumeran desde la ultima perdida hasta el momento en que sucede la siguiente pérdida.
Un evento de pérdida define un nuevo evento de congestión.
Random Early Detection Gateway
Parece existr un acuerdo general en la comunidad para desarrollar Random Early Detection gateways para mejorar el desempeño del trafico TCP.
El manejo de la cola de paquetes en RED intenta mantener un tamaño promedio pequeño y también acomodar una gran cantidad de paquetes para evitar el desbordamiento del buffer.
Uno de los principales problemas en el control de congestión en TCP es intentar recuperarse de multiples perdidas dentro de un mismo periodo. Esto se debe a que durante un desbordamiento se tiran todas las colas de datos.
Idealmente, los gateways RED deben estar configurados de tal manera que cada flujo experimenta como máximo una sola pérdida por RTT. Bajo estas circunstancias, los flujos de TCP pueden recuperar de manera eficiente a partir de una sola pérdida sin experimentar un tiempo de espera de retransmisión. Intuitivamente, siempre y cuando un gateway RED funcione en su región ideal, RAP y TCP obtienen una parte igual de ancho de banda ya que ambos utilizan el algoritmo AIMD. Sin embargo, si la longitud media de la cola supera el umbral máximo, RED comienza a descartar paquetes con una probabilidad muy alta. En este punto, RAP y TCP empiezan a comportarse de forma diferente. Cuando el TCP normal experimenta pérdidas múltiples dentro de una ventana, se somete a un tiempo de espera de retransmisión y sus control de congestión divergen del algoritmo AIMD.
Se espera observar una mejora sustancial en el rendimiento mediante la implementación de RED aunque sólo impide que el búfer se desborde y causando la pérdida de ráfaga. Este comportamiento limita la divergencia de control de congestión de TCP del algoritmo AIMD.
Como parámetros RED dependen estrechamente del comportamiento del tráfico total, es difícil mantener el trafico RED en su región ideal debido a los cambios de tráfico con el tiempo.
Por lo tanto, la configuración de RED sigue siendo un tema de investigación.
4. Simulación
El objetivo de la simulación presentada es explorar las propiedades de RAP y su capacidad de hacer frente al trafico TCP, su interacción con gateways RED.
Las simulaciones demuestran que RAP es amigable bajo el protocolo TCP.
Las simulaciones se realizaron utilizando el simulador NS2 y se comparo con TCP Tahoe, Reno, NewReno, Sack y con experimentos del mundo real.
La topología de la simulación se muestra en la siguiente imagen:
Las especificaciones de la simulación son:
- La conexión entre SW1 y SW2 siempre tiene un cuello de botella y el nodo SW1 es el inicio del cuello de botella.
- Los switches implementan un scheduler tipo FIFO y una cola tipo drop-tail, con excepción en las simulaciones RED.
- Son m conexiones tipo RAP desde los nodos R1 ... Rm, hasta los nodos P1 ... Pm.
- Las conexiones comparten la banda ancha en el cuello de botella con n flujos TCP desde las fuentes T1 ... Tn, hasta los receptores S1 .. Sn.
- Los datos y los paquetes ACK son similares para RAP y TCP.
- Todas las conexiones cuentan con el mismo delay
- El tamaño del buffer en SW1 tiene cuatro veces mas banda ancha RTT.
- Todas las simulaciones correrán hasta que muestren un comportamiento estático.
- Todos los flujos TCP son sesiones de tipo FTP con una cantidad infinita de información.
- La banda ancha promedio es medida por el número de paquetes durante los últimos tres cuartos del tiempo de la simulación para ignorar el comportamiento transitorio del principio
Los parámetros de la simulación son:
| Packet size | 100 bytes |
|---|---|
| ACK Size | 40 bytes |
| Bottleneck delay | 20 ms |
| B/W per flow | 5 Kbytes/s |
| B/W of Side Links | 1.25 Mbytes/s |
| Tot. Delay of Side Links | 6 ms |
| Simulation Length | 120 sec |
| TCP Maximum Window | 1000 |
| TCP Timeout Granularity | 100 ms |
5. Conclusiones y trabajo futuro
Aunque alcanzar una buena compatibilidad con TCP en una amplia gama de parámetros de la red es extremadamente difícil, RAP alcanza razonablemente este objetivo. Se diseño y evalúo un mecanismo de adaptación de la tasa de transferencia para emular la propiedad de temporización ACK de TCP. Los resultados muestran que la adaptación de la tasa de transferencia la coexistencia de ambos protocolos a un nivel más amplio. La divergencia del control de congestión de TCP respecto al algoritmo AIMD suele ser la causa principal de la falta de equidad de TCP en casos especiales. Este problema se manifiesta con mayor claridad con Reno y Tahoe, mientras que tiene un impacto más limitado en Sack.
Si los gateways RED son debidamente configurados, se puede alcanzar una capacidad de intercambio ideal entre protocolos.
RAP es un componente esencial de la arquitectura de extremo a extremo para la reproducción de flujos unicast en tiempo real a través de redes de mejor esfuerzo. Se ha desarrollado una "adaptación de calidad" mecanismo que ajusta sin problemas la calidad de una reproducción de vídeo codificada en capas, mientras que su velocidad de transmisión es controlada por RAP.
Referencias
-
Reza Rejaie, Mark Handley, Deborah Estrin
RAP: An End-to-end Rate-based Congestion Control Mechanism for Realtime Streams in the Internet
University of Southern California, Information Sciences Institute
http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=752152
OK; 7 pts.
ResponderEliminar