11.3.1.Introducción
Las aplicaciones de red en tiempo real dependen de parámetros de red tales como ancho de banda, retardo, jitter (variación del retardo entre paquetes) y pérdida de paquetes para su correcta operación. El grado de sensibilidad y
tolerancia a estos parámetros varía de una aplicación a otra. Aplicaciones críticas como la cirugía remota requieren de una altísima confiabilidad de tales parámetros así como también garantía en la entrega. En cambio otras aplicaciones como la mayoría de la multimedia convencional requieren diferentes niveles de calidad de servicio en términos de dichos parámetros. Las redes de conmutación de paquetes, tal el caso de Internet, no fueron diseñadas para proveer garantía de servicio por conexión como lo hacen las redes de conmutación de circuitos como la de telefonía. Como resultado de ello, en las redes IP los paquetes de un flujo particular pueden alcanzar su destino a través de diferentes caminos y experimentar diferentes cantidades de retardo, jitter y pérdida de paquetes a lo largo de su recorrido.
La arquitectura actual de Internet se basa en el modelo de servicio de “best- effort”, el cual ha trabajado muy bien para aplicaciones tradicionales como e-mail, ftp, telnet y web. La mayoría de estas aplicaciones se basa en el protocolo de control de transmisión (TCP), el cual provee entrega confiable de paquetes pero no garantiza retardo ni jitter comprometidos. Por el otro lado, para soportar aplicaciones de tiempo real sobre una red WAN se requiere una clasificación del tráfico y garantías de nivel de servicio. Se han formulado muchas propuestas para proveer múltiples clases de servicios para tanto flujos individuales como flujos agregados con una calidad acorde a dichos flujos. Una vez implementados, dichas clases de servicios habilitarán a Internet a entregar el volumen creciente de datos de tiempo real y misión crítica a los usuarios finales. En este punto, la calidad de servicio se puede definir como la capacidad de proveer aseguramiento de recursos y diferenciación de servicios en una red.
11.3.2.Aplicaciones de tiempo real y necesidad de soporte QoS
Siempre ha habido y continúan habiendo muchos debates entre quienes son partidarios de la implementación de QoS y sus oponentes, quienes sugieren agregar más ancho de banda a las redes (overprovissioning) para solucionar los problemas relacionados con la congestión, pérdida de paquetes y retardos dado que cada vez los precios para agregar ancho de banda son más bajos. Sin embargo algunas aplicaciones en tiempo real como Voz sobre IP (VoIP), videoconferencia y telemedicina requieren garantías no sólo de mayor ancho de banda sino también de delay, jitter y pérdida de paquetes. En presencia de otras aplicaciones como tráfico WWW, telnet y transferencia de archivos del tipo “bulk” en la misma red, los paquetes de las aplicaciones de tiempo real pueden experimentar variaciones grandes e impredecibles de delay, jitter y pérdida de paquetes especialmente en
ausencia de esquemas de prioridades de tráficos. Una de las ventajas de instalar mecanismos de QoS es proveer prioridad y protección a los streams de los tráficos seleccionados. En estos últimos tiempos se ha establecido un debate entre QoS y overprovisioning, y algunos apuestan a mecanismos mixtos entre ambos que son más económicos y no tan rígidos como mantener una red controlada por QoS que requiere la configuración de múltiples servidores de políticas y reservas así como también elementos de control de admisión en los extremos de la red. Otro argumento que se da usualmente a favor de QoS es la diferencia de anchos de banda entre los backbones y los extremos de Internet. En las redes que conforman los extremos de Internet generalmente hay más congestión que en los backbones. Además hay una clara necesidad de contar con mecanismos de prioridades y protecciones para los paquetes de aplicaciones de tiempo real y misión crítica en los routers extremos.
Las aplicaciones multimedia usualmente son sensibles al delay extremo a extremo y a las variaciones de delay (jitter), pero muchas de ellas pueden tolerar ciertos niveles de pérdida de paquetes. Y por otro lado TCP está diseñado para brindar la mayor seguridad en la entrega confiable de datos sin tener en cuenta al delay ni jitter. Otras aplicaciones de tiempo real como transacciones o administración remota requieren garantías en delay y pérdida de paquetes. Por ejemplo, las llamadas VoIP requieren un máximo delay extremo a extremo de 150-300 ms para una apropiada comprensión de la voz.
Dentro del modelo actual de “best-effort” de Internet, se han desarrollado algunos protocolos para soportar las aplicaciones multimedia, tales como Real Time Protocol (RTP), Real Time Control Protocol (RTCP) y Real Time Streaming Protocol (RTSP), como así también el estándar H.323 para aplicaciones de videoconferencia. Muchas aplicaciones multimedia también emplean técnicas de adaptación para lidiar con las condiciones de red inesperadas.
11.3.3.Características del tráfico de Streaming
El caso en estudio es un streaming en vivo de HDTV sin comprimir, con transporte de audio y video. Las aplicaciones de audio/video streaming pueden retardar su punto de reproducción (playback) de acuerdo al máximo delay de la red y así superar el inconveniente del jitter, pudiéndose ocasionar buffer overflows y pérdida de datos.
En general, las principales características del tráfico de audio/video streaming como tráfico del tipo real-time, son las siguientes:
Son aplicaciones interactivas. Envuelven una secuencia de interacciones y transferencias de información entre los puntos extremos de la aplicación. Un caso típico es el uso de los comandos Rev/Fwd/Pause/Stop en las aplicaciones de video. Estos tipos de aplicaciones pueden depender de parámetros de QoS como ancho de banda, delay, jitter y pérdidas. Como otro ejemplo, las llamadas de telefonía IP necesitan un delay extremo a extremo menor a 300 mseg, a pesar que en realidad se produce una degradación con delays mayores a 150 mseg. En las conversaciones de voz el jitter es aceptable hasta un valor de 75 mseg. Para compensar el jitter se usan jitter buffers pero los mismos incrementan el delay extremo a extremo y deben ser usados con mucho cuidado. Por otro lado, las aplicaciones no interactivas no interactúan entre los puntos extremos. Ejemplo de este tipo de aplicaciones son el backup de datos y las transferencias de datos masivas. Estas aplicaciones típicamente tienen requerimientos de ancho de banda para proveer una performance razonable.
Son aplicaciones inelásticas. El tráfico multimedia es del tipo “soft real-time” y puede tolerar alguna degradación en QoS por un breve período de tiempo y operar con una calidad más baja, en contraposición con las aplicaciones del tipo “hard real time” como la videoconferencia que no pueden funcionar para nada si sus necesidades de QoS no son encontradas en la red durante todo el tiempo.
Son aplicaciones tolerantes. No se debe confundir las aplicaciones elásticas con tolerantes: mientras que las primeras no imponen ningún requerimiento de QoS, las segundas imponen requerimientos de QoS pero con rangos o niveles que permiten que las aplicaciones corran incluso si los niveles óptimos de QoS no son alcanzados. Las aplicaciones tolerantes son generalmente inelásticas con rangos de requerimientos de QoS, pero si sus límites de QoS son violados entonces no pueden ejecutarse en forma correcta. Otro ejemplo de tales aplicaciones es la telefonía IP. Así, las aplicaciones “hard real time” son un ejemplo de aplicaciones intolerantes, porque son aplicaciones que especifican valores fijos para sus requerimientos de QoS y no pueden ejecutarse si estos valores no son obtenidos. Un ejemplo de aplicaciones tolerantes es VoD: la aplicación puede tolerar pérdidas y una cierta cantidad de delay y aún así ser capaz de correr ininterrumpidamente. Cabe destacar que algunas técnicas de compresión de video como MPEG pueden tolerar pérdidas en frames
y usan relaciones entre frames sucesivos para predecir los frames pérdidos.
Son aplicaciones adaptivas. Estas aplicaciones tratan de mantener la calidad percibida en niveles aceptables, incluso bajo condiciones pobres de la red. Esto puede ser alcanzado por medio de la disminución de la velocidad de transmisión o de la resolución de la transmisión, o incluso por medio del uso de técnicas de compresión y corrección de errores. Las aplicaciones adaptivas pueden usar también buffers extra para compensar las condiciones transitorias desfavorables de la red y permitir una degradación elegante en la performance. La mayoría de las aplicaciones de audio y video en Internet son adaptivas. Por otro lado las aplicaiones no adaptivas no tienen la capacidad de lidiar con condiciones transitorias desfavorables de la red: ellas pueden tolerar cierta degradación de QoS pero esto afecta directamente la calidad percibida por el usuario final. En la mayoría de los casos, las aplicaciones adaptivas son tolerantes y las aplicaciones no adaptivas son intolerantes, pero también se pueden encontrar otras combinaciones.
La calidad de una transmisión de video es sensible a la pérdida de datos dado que la mayoría de las técnicas de compresión buscan reducir las redundancias entre frames sucesivos. El efecto de las pérdidas en la calidad de video es también influenciado por parámetros tales como las técnicas de codificación usadas, velocidad de pérdidas, patrón de pérdidas y tamaño del paquete de transmisión. Los efectos de las pérdidas de paquetes grandes a menudo son más pronunciados que los efectos de los paquetes más pequeños. La calidad de video del usuario final también depende del tipo de frame que se pierde, por ejemplo en la codificación MPEG la pérdida de los frames I o P es siempre más severa que la pérdida de los frames B. En el caso de los streams multimedia consistentes de flujos de audio y video, la sincronización entre flujos es importante para la calidad total. Además se debe garantizar calidad para el audio y video en estos casos.
Un estándar común usado para medir la calidad de la voz y el video es el llamado “mean opinion score” (MOS, recomendación ITU-T P.800), el cual envuelve un gran número de personas y toma el promedio estadístico de sus opiniones acerca de la calidad de la multimedia transferida.
11.4.Requerimientos de QoS