Nadeem Aboobaker, David Chanady, Mario Gerla, M. Y. Sanadidi
Introducción
El trabajo que estoy resumiendo introduce el protocolo SMCC (Stream Media Congestión Control), un protocolo de manejo de congestión adaptativo para streaming multimedia en el cual la tasa de transmisión de paquetes en una conexión es ajustada de acuerdo a la parte de ancho de banda dinámica que corresponde a la conexión. Este protocolo no exhibe la tasa pronunciada de oscilaciones característica de TCP, por lo que proporciona un control de congestión más adecuado para el streaming en aplicaciones multimedia.
Además el protocolo SMCC es equitativo, compartiendo el ancho de banda igualmente con las demás conexiones SMCC. Una ventaja importante es la robustez cuando la pérdida de paquetes se debe a errores aleatorios, lo que es típico de conexiones inalámbricas y se está convirtiendo en una preocupación más grande debido a el acceso a Internet inalámbrico emergente. Además, proporcionan simulaciones utilizando el simulador NS-2.
Protocolo SMCC
El protocolo propuesto en el paper:
- Adapta la tasa de envío dependiendo de la parte correspondiente de ancho de banda de la conexión.
- Es equitativo con aplicaciones existentes.
- No sufre de oscilaciones pronunciadas en la tasa de envío como la mayoría de los protocolos.
No existe una ventana de congestión en SMCC, aunque ajusta su tasa de envío, copiando la fase de TCP para evitar congestiones con un sondeo de ancho de banda (un paquete extra es enviado por ronda mientras no se detecte congestión). Cuando se encuentra congestión, la tasa de envío es reducida al actual Bandwidth Share Estimate (BSE) ó estimado de parte de ancho de banda, y se continua con el sondeo linear. La tasa de envío nunca baja hasta 1 paquete por ronda, igual que en TCP, amenos que el BSE actual dicte ese valor.
Operaciones en el Envío
Después de una configuración utilizando un three-way handshake entre el servidor SMCC y el cliente, el transmisor comienza a enviar datos multimedia. En la implementación del paper, se asume que la red puede manejar la tasa de envío de baja calidad, y utiliza esa tasa como la tasa inicial de envío. El tiempo de ida y vuelta inicial estimado es juntado a partir del proceso del handshake. Después de cada RTT, el transmisor incrementa la tasa de envío por un paquete. Esto tiene el efecto de copiar la fase de evitar la congestión de TCP. El transmisor reajusta su RTT estimado cada tiempo de ida y vuelta, solicitando una confirmación para el primer paquete cada ventana RTT nueva.
Cada que se recibe un NACK, se reinicia la tasa de envío al BSE contenido en el mensaje NACK, y continua el sondeo linear. El transmisor puede determinar si hay suficiente tiempo para retransmitir el paquete perdido, basado en la información que obtiene del cliente acerca del buffer actual del receptor.
Operaciones en el Receptor
Con cada paquete recibido, el cliente puede recalcular el BSE. Al recibir un paquete, que el transmisor solicita ser comprobado, el receptor envía un ACK para ese paquete. Entonces, este intercambio de mensajes es usado para poner el RTT del lado del transmisor. Cuando un paquete perdido es detectado, un mensaje NACK es enviado conteniendo el estimado de ancho de banda actual. Es la responsabilidad del transmisor determinar si el paquete debe ser retransmitido.
Cálculo del Ancho de Banda
La ventaja del acercamiento con el protocolo SMCC es que mide la tasa en el camino de ida de la conexión, filtrando los efectos de la congestión en el camino de vuelta. Básicamente el cliente calcula la parte de ancho de banda de la conexión usando el método Receiver Based Packet Pair (RBPP). RBPP requiere el uso de dos paquetes enviados consecutivamente para determinar el ancho de banda que le corresponde a una conexión. El agregado del SMCC al número de secuencia del RBPP es fundamental para no sobre estimar la cantidad de ancho de banda e incrementar la equidad del SMCC.
Una segunda restricción es aplicada para asegurarse de que la compresión de tiempo no ocurra en paquetes consecutivos. Se define la compresión de tiempo como lo que ocurre cuando la diferencia entre el tiempo de llegada de los paquetes es menor a la diferencia entre los tiempos de envío de los paquetes. Si los paquetes han tenido compresión de tiempo, no son usados en el cálculo del BSE, debido a que el estimado sería muy agresivo. El intento es estimar el ancho de banda hasta la tasa de envío instantánea del servidor, aunque haya más ancho de banda disponible.
Si dos paquetes recibidos consecutivamente han pasado las dos pruebas anteriores, son usadas para calcular el ancho de banda como sigue:
$Ancho de Banda ={s_{2}}/ {(a_{2} - a_{1})}$
Donde $s_2$ es el tamaño del segundo paquete, $a_1$ y $a_2$ son los tiempos de llegada del primer y segundo paquete respectivamente.
Conclusión:
El paper presenta el protocolo SMCC, un protocolo de control de congestión basado en conceptos de estimación de ancho de banda que proporciona cambios en la tasas de envío y buena utilización cuando fluctúa el ancho de banda disponible de la red.
El protocolo tiene la característica de ser justo, es decir es equitativo con otros flujos SMCC, compartiendo el ancho de banda. Es razonablemente amigable con TCP, particularmente en conexiones con pérdidas.
También, aunque SMCC dicta la tasa de envío de una aplicación de streaming multimedia, no es así con la calidad del stream. La adaptación con la calidad es una situación separada. No solo depende de la tasa de envío actual, pero también del buffer del receptor, y las preferencias de usuario y perfil.
Referencia:
Falta tu crítica propia. 6 pts.
ResponderEliminar