MÁSTER EN INGENIERÍA DE COMPUTADORES – TRANSMISIÓN DE DATOS MULTIMEDIA
1
Estudio y evaluación de técnicas FEC para la recuperación frente a errores Rafael Ubal Tena
Resumen—En este trabajo se da una breve descripción de las principales características de los mecanismos de corrección de errores FEC (Forward Error Correction) y del protocolo de transmisión de datos multimedia RTP (Real-time Transport Protocol). Estos dos ámbitos se tratan por separado y en conjunto, discutiendo la aplicación de técnicas FEC sobre RTP. Además, se describe la implementación de un simulador que modela una red imperfecta (con errores de transmisión) sobre la que se evalúa la eficacia de las técnicas de corrección de errores, utilizando diferentes variantes de FEC y múltiples tasas de error.
I. INTRODUCCIÓN
L
AS redes actuales que forman Internet son en su mayoría redes IP. A pesar de que este protocolo de red ha gozado de actualizaciones, la versión 4 del mismo es la que se emplea más comúnmente, en la mayoría de casos por compatibilidad hacia atrás con recursos hardware y software. Uno de los principales problemas de IPv4 en el ámbito de la transmisión de datos multimedia es su carencia de garantías en cuanto a calidad de servicio. Concretamente, existe un riesgo continuo de pérdida de paquetes, ocasionado principalmente por la congestión de nodos enrutadores o por errores en la transmisión debidos a fenómenos físicos. Además, este tipo de redes no fueron diseñadas en sus orígenes como redes capaces de entregar paquetes en tiempo real, lo cual es asimismo un requisito de las transmisiones multimedia. Las limitaciones de los medios físicos y de los mecanismos fijados durante la juventud de Internet se han paliado con el tiempo mediante el diseño de protocolos de más alto nivel que detecten y actúen frente a eventos de pérdida, desordenación o corrupción de datos, siendo el protocolo de transporte TCP el más ampliamente utilizado. Sin embargo, el requisito del tiempo real impide la utilización de protocolos altamente interactivos, como TCP, cuya sobrecarga haría inviable una recepción de paquetes sobre los que se imponga una cota superior en cuanto al tiempo de transmisión. Por esta razón surge el protocolo RTP (con sus hermanos RTCP y RTSP), comentados en la siguiente sección. Ya que no es posible exigir a protocolos inferiores una cierta calidad de servicio, la filosofía de RTP consiste en monitorizar de forma continua las características de las redes sobre las que se trabaja y variar los parámetros de transmisión adaptándose dinámicamente a la situación del medio y dispositivos de
transmisión. El protocolo TCP soluciona las consecuencias de la pérdida de paquetes a través de retransmisiones de los mismos, lo cual requiere un mecanismo de notificación de recepción: cuando el emisor no recibe reconocimientos en un cierto tiempo, reenvía los paquetes implicados. De nuevo, esta característica resulta inviable en una transmisión de datos multimedia en tiempo real, ya que el retardo adicional de una retransmisión excedería muy probablemente las restricciones temporales preestablecidas. En este sentido, las técnicas de inclusión de redundancia son las que sustituyen a las retransmisiones. Las técnicas FEC, descritas en la siguiente sección, son las más ampliamente utilizadas para este propósito, hasta el punto de que los estándares RFC incorporan la utilización de FEC sobre RTP. En cuanto a los medios de transmisión hacia los que está enfocado RTP, se puede afirmar que pueden ser de naturaleza variopinta: desde redes de área local con una tasa de fallos, retardos y jitter muy bajos, hasta redes de área amplia proclives a ocasionar pérdidas de paquetes y alta variabilidad en su transmisión. Por ello, tanto el protocolo RTP como las técnicas de tolerancia a fallos aplicadas sobre él (FEC) deben contemplar este hecho para actuar con eficacia. Todas estas circunstancias motivan el desarrollo del presente trabajo, en el que se propone una pequeña herramienta para simular una red con una tasa de fallos parametrizable, sobre la cual se transmite un flujo de datos RTSP utilizando tolerancia a fallos en forma de paquetes FEC con un código de redundancia variable. Mediante esta herramienta, se pretende obtener el código FEC idóneo, o lo que es lo mismo, la cantidad de información redundante apropiada, para redes de diferente naturaleza y, por tanto, con diferentes tasas de error. El resto de este trabajo sigue la siguiente estructura. La sección II describe brevemente los protocolos FEC y RTP. La sección III presenta la herramienta construida y la metodología de simulación. Por último, la sección IV incluye unas notas concluyentes a este trabajo.
II. ESTÁNDARES Y PROTOCOLOS A. Forward Error Correction (FEC) Forward Error Correction es un sistema de corrección de errores para transmisiones de datos en el que el emisor añade
MÁSTER EN INGENIERÍA DE COMPUTADORES – TRANSMISIÓN DE DATOS MULTIMEDIA datos redundantes que permiten al receptor detectar y corregir errores sin la necesidad de solicitar de nuevo los datos. La principal ventaja de este mecanismo reside en la elusión de retransmisiones, a costa de incrementar el volumen de datos enviados (y por tanto el ancho de banda necesario). Las técnicas FEC son una alternativa a la corrección de errores en medios donde la retransmisión es demasiado costosa, como por ejemplo aplicaciones en tiempo real, o imposible, como soportes físicos de almacenamiento (CD, memorias FLASH, etc). El volumen de información redundante y su disposición determina el código FEC, que puede variar según las condiciones del medio de transmisión. Asimismo, el código FEC determina el número máximo de errores que se pueden corregir. 1) Evolución de técnicas FEC La primera técnica FEC que se publicó [1] utilizaba codificación algebraica. En este caso, el codificador interpone bits de paridad entre la secuencia de datos utilizando un algoritmo algebraico determinado. Una técnica FEC posterior fue la conocida como codificación convolucional [2], que trabaja sobre flujos de datos, en lugar de hacerlo sobre bloques. La principal característica de estos códigos FEC es que la codificación de una secuencia de bits está altamente influenciada por bits anteriores, por lo que el algoritmo de decodificación los tiene en cuenta para estimar la secuencia más probable de bits correctos a la hora de recomponer la secuencia original. Originalmente, la decodificación convolucional tenía el inconveniente de ser espacialmente costosa, y generalmente ocasionaba desbordamiento de buffers en implementaciones deficientes. Más tarde, A. Viterbi desarrolló una técnica de decodificación convolucional [3] que supuso a partir de entonces el estándar de decodificación FEC. Este algoritmo compara los bits recibidos con los bits que podrían haberse generado para cada posible transición desde estados previos del decodificador. Basado en métricas de similitud, se escoge la secuencia más cercana a que podría ser la original, la cual se devuelve como flujo de bits decodificado. El algoritmo de Viterbi, basado en programación dinámica, tiene la ventaja de hacer un uso eficiente de la memoria utilizada, desechando flujos de bits anteriores que tienen poca probabilidad de ser reutilizados. 2) Turbo-Coding En 1993, C. Berrou desarrolló la técnica FEC más potente hasta el momento, llamada turbo-coding [4]. Con esta técnica, los sistemas de comunicación pueden alcanzar el límite máximo teórico de la capacidad de los canales, caracterizada anteriormente por Shannon, y considerada inalcanzable durante mucho tiempo. Una de las características de tubo-coding es que el codificador debe incluir combinaciones de, como mínimo, dos codificadores FEC. Entre ellos se pueden encontrar tanto
2
codificadores algebraicos como convolucionales. Sin embargo, en cualquier caso, la codificación global se procesa en bloques, cuyo tamaño viene dictado por un codificador intermediario (interleaver), que separa a cada uno de los componentes. Los bits de información son codificados por el primer componente codificador directamente, mientras que el segundo componente codificador opera con una versión desordenada de ellos. Con ello producimos los bits de paridad del primer y el segundo codificador. La señal a enviar por el canal estará formada por los bits sistemáticos que coinciden con los de información y los bits de paridad de ambos componentes codificadores. En recepción, la turbo decodificación iterativa está formada por dos componentes decodificadores convolucionales en paralelo que decodifican los bits recibidos por su correspondiente componente codificador. El primer componente decodificador produce además cierta información no relacionada con los bits de entrada, que permite al segundo componente decodificar los mismos bits recibidos con una tasa de error menor. El proceso se reitera hasta que se obtiene la tasa de error deseada, teniendo en cuenta que por cada iteración se aumenta el grado de complejidad del turbo decodificador convolucional. El método de la turbo codificación ha pasado a formar parte de estándares, como UTRA (UMTS Terrestrial Radio Access), debido a su gran potencia de recuperación de errores en comunicaciones. B. Real-Time Transport Protocol (RTP) El protocolo RTP define un formato estándar de paquetes para transmitir audio y vídeo en Internet. Fue publicado originalmente en el RFC 1889 y, más tarde, en el RFC 3550 [5], dejando obsoleta la primera versión. El estándar define el uso de RTP bien con conexiones TCP en un puerto arbitrario, o bien con conexiones UDP en puertos pares. En este último caso, el siguiente puerto impar se utiliza para comunicaciones de control con RTCP (RTP Control Protocol). Inicialmente, RTP se diseñó como un protocolo multicast, pero ha acabado utilizándose en muchas aplicaciones unicast, principalmente en streaming de audio/vídeo (junto con el protocolo RTSP) y videoconferencias. Las aplicaciones que utilizan RTP son poco sensibles a la pérdida de paquetes, pero sí lo son a los retardos de la comunicación, por lo que la implementación de RTP sobre el protocolo de transporte UDP es una opción más sensata que sobre TCP. Los paquetes RTP dan información sobre el tipo de contenido multimedia que se está transmitiendo, números de secuencia de paquetes, marca de tiempo real que representa el instante de presentación de los datos (time-stamping) y monitorización de entrega. En sí mismo, el protocolo RTP no garantiza calidad de servicio, entrega de paquetes a tiempo u ordenación de paquetes a la llegada. Sin embargo, el protocolo asociado RTCP da información de la calidad de recepción, con lo que la
MÁSTER EN INGENIERÍA DE COMPUTADORES – TRANSMISIÓN DE DATOS MULTIMEDIA tasa de transmisión de datos puede ajustarse a los parámetros de la red monitorizada. A continuación se pasa a describir brevemente los protocolos RTCP y RTSP, ambos estrechamente ligados a RTP: 1) Real Time Control Protocol (RTCP) El protocolo RTCP [5] está ligado a cualquier conexión RTP, y da información sobre la utilización de la red por la que se transmiten los datos multimedia. Los paquetes RTCP no transportan datos en sí mismos, sino que se envían periódicamente a todos los participantes de una sesión de streaming multimedia, de forma que todos obtengan pistas sobre la calidad del servicio que la red está proporcionando a sus demandas. RTCP recoge estadísticas de una conexión multimedia, tales como el número de bytes enviados, paquetes perdidos, jitter (variación del retardo), etc. Las aplicaciones de envío pueden hacer uso de esta información ajustando la calidad de los datos enviados, bien cambiando la resolución de las imágenes o la tasa de bits del audio, o bien ajustando los parámetros de compresión del codificador. 2) Real Time Streaming Protocol (RTSP) El protocolo RTSP, publicado en el RFC 2326 [6], se utiliza asimismo generalmente junto con RTP, y permite que los clientes controlen el flujo de datos multimedia generado por el
3
servidor, utilizando órdenes similares al VCR (play, pause…). También soporta el acceso basado en tiempo a los ficheros multimedia del servidor. Las órdenes RTSP tienen una sintaxis similar a HTTP, con la principal diferencia de que el servidor RTSP mantiene información de sesión. Para ello, existe un mecanismo de asignación de identificadores de sesión, que permite cerrar y abrir conexiones conservando información entre ellas, incluso eludiendo el protocolo TCP. Las órdenes principales de RTSP son las siguientes: • DESCRIBE: Una petición de este tipo incluye una URL (rtp://…) y obtiene como respuesta la descripción del contenido asociado. • SETUP: Especifica cómo se transportarán los datos que se enviarán. Para ello, se incluye típicamente el puerto local de recepción RTP y metainfomación RTCP. La respuesta del servidor confirma los parámetros y añade otros, como el puerto RTP del servidor. • PLAY: Comienza la reproducción del medio especificado. Esta orden puede desencadenar la transmisión de uno o más flujos multimedia. • PAUSE: Para temporalmente la reproducción, reanudándola con la orden PLAY siguiente. • RECORD: Utilizada para enviar un flujo al servidor, de forma que éste lo almacene. • TEARDOWN: Terminación de la sesión actual. Para todos los flujos asociados a esta sesión y libera los datos de la
Figura 1: Captura del tráfico RTSP con Ethereal
MÁSTER EN INGENIERÍA DE COMPUTADORES – TRANSMISIÓN DE DATOS MULTIMEDIA sesión en el servidor. C. FEC sobre RTP El RFC 2733 [7] propone la aplicación de técnicas FEC sobre el protocolo RTP. Este protocolo está destinado a funcionar sobre cualquier tipo de redes IP, incluyendo las redes de área amplia (WAN). Es en estas redes donde existe un gran riesgo de pérdida de paquetes, debido principalmente a posibles congestiones de notos intermedios. Por otra parte, la transmisión de datos multimedia (por ejemplo, voz) tiene restricciones temporales que no permiten solicitud de retransmisión en caso de pérdidas. RTP es, por tanto, un protocolo muy susceptible de incorporar técnicas FEC, que añaden redundancia al flujo de datos enviado, compensando así la imposibilidad de aplicar el mecanismo de reenvíos. La aplicación de FEC sobre RTP consiste en escoger un conjunto de paquetes RTP y combinarlos utilizando la operación xor. Para ello, se deben extender los datos de los paquetes RTP originales de forma que alcancen una longitud igual a la del paquete más largos. Las cabeceras de los paquetes RTP se combinan de forma selectiva, aunque también utilizando la operación xor. Este proceso queda detallado en la sección 6 del RFC. El estándar deja la libertad de escoger un código FEC libre según la implementación. Se llama código a las combinaciones específicas de paquetes RTP que se utilizan para construir la secuencia de paquetes FEC. El código FEC puede variar incluso dinámicamente, adaptándose a características variables del medio de transmisión. Para la especificar qué paquetes RTP están asociados a un paquete FEC, este último incorpora una cabecera de 24 bits, de los cuales, el bit i indica que el paquete RTP con número de secuencia N+i se utilizó en la operación xor, siendo N el número de secuencia del propio paquete FEC. En este RFC, se propone enviar el flujo de paquetes FEC de forma independiente respecto al flujo RTP original, con la ventaja de que los usuarios que no implementen FEC sean capaces de ignorar la información redundante y conservar la original. Sin embargo, el flujo de datos original puede reconstruirse únicamente a partir de paquetes FEC, evitando el envío de los paquetes RTP, pero obligando al receptor a implementar este estándar. Las diferentes secciones del RFC 2733 enumeran la nomenclatura utilizada a lo largo de la especificación, describen la metodología de incorporación de redundancia, incorporan una serie de ejemplos de códigos FEC y fijan el formato de los paquetes FEC. Adicionalmente, las secciones 9 y 10 añaden un posible algoritmo a implementar en el receptor (incluyendo el código en C) y dan un ejemplo de sesión RTP en el que se aplica el protocolo especificado en sus secciones anteriores. III. ENTORNO EXPERIMENTAL Para este trabajo, se ha perfilado un entorno experimental
4
que permite evaluar la eficacia de las técnicas FEC a la hora de corregir errores sobre un flujo de datos RTSP real. Con este objetivo, se ha seguido la siguiente metodología: • En primer lugar, se ha capturado tráfico RTSP real. Para ello, se ha descargado el software libre QuickTime, reproductor de vídeo de Apple, y se ha introducido la siguiente URL, que hace referencia a un flujo de datos RTSP: rtsp://stsv01.st.ehu.es/MSR.mov • A continuación, hemos descargado el software, también libre, Ethereal, una aplicación que permite capturar, analizar y clasificar el tráfico que atraviesa la tarjeta de red local. Con Ethereal, seleccionamos el tráfico RTSP entrante, correspondiente al vídeo recibido con QuickTime, y lo volcamos en un fichero. • Este fichero sirve como entrada a la herramienta construida, que simula tres elementos principales: i) un emisor de datos con capacidad de incluir redundancia FEC, ii) una red imperfecta que introduce errores de transmisión y iii) un receptor capaz de reconstruir los paquetes recibidos, siempre que la información FEC lo permita. El objetivo de este estudio es analizar varios códigos FEC actuando sobre datos RTSP que se transmiten sobre una red cuya tasa de fallos puede especificarse en cada experimento. Variando la redundancia FEC y la frecuencia con que ocurren los errores en el medio de transmisión, mediremos el grado de pérdida de datos en forma de bytes erróneos y paquetes erróneos. A continuación, se detalla este proceso y se describe la herramienta desarrollada, así como los resultados obtenidos a partir de ella. A. Captura de tráfico RTSP Para generar tráfico RTSP entrante, escogemos una URL aleatoria, obtenida en Google, y la introducimos en QuickTime. Por otra parte, iniciamos una captura de tráfico con Ethereal, como se muestra en la Figura 1. Adicionalmente, Ethereal permite filtrar el tráfico capturado. Al encontrarnos en una máquina con más aplicaciones abiertas que comparten tarjeta de red, e incluso una misma aplicación generando diferentes tipos de tráfico, debemos seleccionar únicamente el tráfico RTSP. Esta acción se consigue introduciendo en el campo Filter la siguiente cadena: ip dst eq 192.168.123.100 and rtsp
De esta forma, indicamos que sólo queremos visualizar tráfico que tenga como IP destino la de nuestra máquina, y que además sea tráfico RTSP. El resultado de la aplicación del filtro lo almacenamos en un nuevo fichero, de nombre stream.cap. Una vez disponemos del flujo de datos sobre el que experimentar con técnicas FEC, debemos volcarlo en un fichero cuyo formato sea analizable por nuestra aplicación.
MÁSTER EN INGENIERÍA DE COMPUTADORES – TRANSMISIÓN DE DATOS MULTIMEDIA
Nombre
Tamaño Descripción (bytes) fec 1 0 si el paquete es RTSP y 1 si es FEC error 1 1 si el paquete contiene error, 0 si no seq 2 Número de secuencia del paquete (0 para FEC) length 2 Tamaño del paquete feclength* 1 Número de paquetes RTSP a partir de los que se construyó un paquete FEC fecseq0* 2 Número de secuencia de fecseq1* 2 paquetes RTSP a partir de los ... ... que se construyó un paquete fecseqfeclength-1* 2 FEC data length Datos del paquete *Estos campos sólo se encuentran cuando fec es igual a 1. Tabla 1: Formato de los ficheros FecRtsp
Ethereal tiene una opción descrita como Follow TCP Stream, mostrada al pulsar con el botón derecho sobre la lista de paquetes. Con esta opción, podemos eliminar la información de control introducida por el nivel físico, el nivel de red y el protocolo TCP, obteniendo un simple flujo de datos correspondiente al flujo RTSP. Además, el cuadro de diálogo resultante ofrece la opción de representar el contenido de la información en diferentes formatos, entre los cuales escogemos el de C Arrays. Con este formato, los datos se representan en forma de vectores con la sintaxis del lenguaje C, estando cada vector formado por los bytes de un solo paquete. Esto resulta idóneo para nuestros objetivos, puesto que no sólo obtenemos una representación en texto plano de los datos analizable mediante scripts, sino que además quedan delimitados los bytes correspondientes a diferentes paquetes, lo cual es una información que habríamos perdido eliminando las cabeceras TCP. Los vectores C los almacenamos en un fichero, stream.c, que servirá como referencia para los programas construidos. Sin embargo, requieren una conversión al formato de fichero, esta vez binario, que se utilizará a lo largo de los experimentos. Este formato, así como el proceso de conversión, se describe a continuación. B. Formato de ficheros internos Los ficheros manejados internamente siguen un formato específico, denominado formato FecRtsp en lo sucesivo. Los ficheros FecRtsp representan una secuencia de paquetes FEC o RTSP. La siguiente tabla muestra el formato empleado, a su vez, para cada uno de los paquetes de dicha secuencia:
Encadenando estructuras de datos con este formato, cada uno de los programas utilizados lee ficheros, los procesa, y
5
genera otros que a su vez pueden servir como entrada de un nuevo proceso. Concretamente, los programas desarrollados y su forma de operar es la siguiente: • buildstream.py: Éste es un script en Python que transforma la salida de Ethereal, en forma de vectores C, en un fichero FecRtsp. Se utiliza para convertir el fichero stream.c en stream.sender. • stream.py send: El programa stream.py, con la opción send, lee un fichero que contenga una captura de paquetes RTSP y añade redundancia FEC, utilizando un código FEC determinado. Además se introducen errores aleatoriamente, simulando el envío de paquetes por una red. Se utiliza para convertir stream.sender en stream.network, todos ellos en formato FecRtsp. • stream.py recv: Con esta opción, se simula la recepción de paquetes en el extremo opuesto de la conexión RTSP. El receptor intenta reconstruir los paquetes RTSP originales a partir de la información FEC introducida. Se utiliza para convertir stream.network en stream.recv. • stream.py comp: Por último, esta opción permite comparar dos archivos FecRtsp, obteniendo estadísticas sobre el número de bytes y el número de paquetes perdidos y no reconstruidos. Se utiliza para comparar stream.sender con stream.recv.
MÁSTER EN INGENIERÍA DE COMPUTADORES – TRANSMISIÓN DE DATOS MULTIMEDIA
6
Figura 2: Porcentaje de bytes perdidos
A continuación, se describen con detalle los procesos de incorporación de redundancia, inyección de errores de transmisión y recomposición de paquetes, todos ellos localizados en el programa stream.py. C. Envío del flujo RTSP (stream.py send) La parte del script stream.py dedicada a la simulación del envío del flujo RTSP pretende generar un fichero FecRtsp conteniendo una serie de paquetes RTSP y FEC con una serie de errores forzados. El código FEC y la tasa de errores de la red vienen especificados en la línea de órdenes, durante la llamada al script. Los códigos FEC implementados se corresponden con diferentes grados de redundancia. Suponiendo que los paquetes a, b, c... son los que forman el flujo RTSP y que f(x,y...) es la función de construcción de paquetes FEC, los códigos implementados se pueden representar así: • Código 0; 0% de redundancia: a b c d ... • Código 1; 50% de redundancia: a b f(a,b) c d f(c,d) ... • Código 2; 75% de redundancia: a b c f(a,b,c) d f(a,c,d) f(a,b,d) d ... • Código 3; 100% de redundancia: a b f(a,b) c f(b,c) d f(c,d) ... Por otra parte, el parámetro que especifica la tasa de inyección de errores es la inversa del tiempo medio que transcurrirá entre un error y el siguiente. El programa genera números aleatorios con distribución exponencial para calcular el número de bytes íntegros antes de que ocurra un nuevo error. Las tasas de error analizadas varían entre 10-5 y 10-2.
El script de Python se basa en la clase Packet, que modela un paquete RTSP o FEC. Sus métodos principales son read y write, utilizados respectivamente para leer y escribir un paquete en un archivo FecRtsp. El proceso a seguir en el envío se basa en leer paquetes del archivo de origen y escribirlos en el fichero destino, incluyendo paquetes FEC según el código especificado. Para crear un paquete FEC a partir de dos o más paquetes RTSP, se utiliza la función Packet.buildfec. Asimismo, para escribir un paquete en el archivo destino, se utiliza la función Packet.WriteWithError, una extensión de Packet.write que inyecta errores según la tasa de error especificada. Los errores se inyectan tanto en los paquetes RTSP como en los paquetes FEC. La función Packet.buildfec recibe una lista de paquetes RTSP, y convierte el paquete actual en un paquete FEC generado a partir de los paquetes de dicha lista. La longitud del paquete FEC será la máxima de todos los paquetes RTSP. Para generar los datos, se rellenan primero con 0 todos los paquetes hasta que tengan la misma longitud, y, a continuación, se realiza la operación xor sobre todos ellos. Disponiendo de la lista de paquetes RTSP y del paquete FEC resultante, cualquiera de ellos puede reconstruirse a partir del resto, realizando el mismo proceso. La función Packet.WriteWithError escribe un paquete en el fichero introduciendo errores en los bytes que corresponda. Para ello, se mantiene un contador que indica el número de bytes restantes hasta que se produzca un error. Cada byte íntegro que se escribe en el fichero de salida provoca una disminución del contador. Cuando éste llega a 0, el siguiente byte contendrá un error y el contador toma un valor aleatorio con distribución exponencial y con la inversa de la tasa de error como media.
MÁSTER EN INGENIERÍA DE COMPUTADORES – TRANSMISIÓN DE DATOS MULTIMEDIA
7
Figura 3: Porcentaje de paquetes perdidos
D. Recepción del flujo RTSP (stream.py recv) El proceso de recepción de los datos consiste en almacenar en un buffer los diez últimos paquetes recibidos (permitiendo códigos FEC que actúen hasta sobre diez paquetes). Cuando se recibe un paquete RTSP o FEC erróneo, éste se descarta. En las simulaciones, la existencia de error viene determinada por el campo error del formato FecRtsp, aunque en la realidad, esta condición se determinaría haciendo una comprobación del checksum en un nivel inferior del protocolo TCP/IP. Cuando se recibe un paquete FEC, se comprueba si hubo algún paquete RTSP erróneo, almacenado en el buffer, que sea posible reconstruir a partir de aquél. En tal caso, una llamada a la función reconstruct se encarga de esta tarea. Esta función se aplica sobre el paquete FEC recibido, y tiene como argumentos una lista de paquetes entre los cuales se podrían encontrar los paquetes RTSP erróneos. E. Comparación de los flujos RTSP (stream.py comp) La última utilidad del script creado es la de comparar los flujos de datos generados por el emisor y los obtenidos por el receptor tras el proceso de recomposición con técnicas FEC. Introduciendo como parámetros los ficheros que representan ambos flujos de datos, el programa muestra estadísticas que permiten analizar la eficiencia de las técnicas FEC en cuanto a paquetes y bytes reconstruidos. Para ello, el programa extrae en la salida estándar una lista de cuatro valores de esta forma: totalbytes
errbytes
totalpackets
errpackets
Estos valores representan el tamaño en bytes del flujo original (sin la redundancia FEC), el número de bytes erróneos
recibidos, el número total de paquetes del flujo original y el número de paquetes erróneos recibidos, respectivamente. F. Resultados A continuación se presentan una serie de resultados (Figuras 2 y 3) obtenidos tras la puesta en marcha del script de simulación desarrollado. Para generarlos, se ha experimentado con varias tasas de inyección de errores, intentando representar redes más fiables (como redes Ethernet locales) o redes menos fiables (como redes de área amplia o redes inalámbricas). Concretamente, se ha variado la tasa de error desde 10-5 (un error cada 105 bytes transferidos, con distribución exponencial) hasta 10-2 (un error cada 100 bytes). Por otro lado, para cada tasa de error se ha experimentado con diferentes códigos FEC, representados desde el código 0 (0% de redundancia) hasta el código 3 (100% de redundancia), descritos anteriormente. Las dos variables monitorizadas y representadas en estas gráficas son el porcentaje de bytes perdidos y el porcentaje de paquetes perdidos. 1) Porcentaje de bytes perdidos: Observando la primera de las gráficas de la Figura 1, podemos ver que para una tasa de error de 10-5, el código FEC 1 (redundancia del 25%) ya consigue recuperar la totalidad de los errores inducidos por la red, llegando a un 0% de bytes perdidos. Para las tasas de error de 10-4 y 10-3, observamos una caída del porcentaje de bytes perdidos conforme aumentamos la redundancia FEC. Es importante recordar que los errores introducidos en la red afectan tanto a paquetes originales como a paquetes FEC. Sin embargo, cuanta más redundancia FEC se introduzca, existe mayor probabilidad de encontrar un paquete
MÁSTER EN INGENIERÍA DE COMPUTADORES – TRANSMISIÓN DE DATOS MULTIMEDIA RTSP/FEC no afectado por ningún error que permita reconstruir un determinado paquete RTSP original. La tasa de error de 10-2 es muy agresiva, ya que provoca una alta probabilidad de que incluso caigan varios errores en un mismo paquete. En este caso, la redundancia FEC no obtiene prácticamente ningún beneficio, puesto que en todos los casos se obtiene prácticamente un 1% de bytes perdidos (igual a la tasa de error). 2) Porcentaje de paquetes perdidos: En la primera de las cuatro gráficas de la Figura 3, podemos realizar la misma observación que en la monitorización del porcentaje de bytes perdidos: para tasas de errores pequeñas, el código FEC 1 ya soluciona todos los problemas de transmisión. La red con tasa de fallos de 10-3 es la que muestra más beneficios con un aumento de la redundancia FEC. Observando la gráfica correspondiente, podemos ver que, si no se introdujera ninguna técnica de recuperación de errores, los paquetes perdidos ascenderían al 42%. Sin embargo, una redundancia FEC del 100% es capaz de disminuir el porcentaje de paquetes perdidos al 17%. Por último, la última de las cuatro gráficas no aporta información adicional respecto a las cuatro anteriores. De ella se desprende de nuevo que una tasa de errores de 10-2 es demasiado alta como para compensarla con técnicas FEC.
100%) para paliar completamente el problema. Sin embargo, un aumento de redundancia se traduce en una disminución agresiva del número de errores observados por el receptor. Para tasas de error de 10-3, redundancias razonables simplemente reducen suavemente el total de errores percibidos, mientras que una tasa de 10-2 se traduce en una transmisión irreparable mediante FEC. Como trabajo futuro, se puede proponer la extensión de la herramienta diseñada para modelar los retardos de los paquetes, así como el jitter dependiente de los diferentes tipos de redes. Con estas ampliaciones podría evaluarse la forma en que afectan las citadas variables a un flujo de datos multimedia, como por ejemplo, la medida en que un jitter determinado afecta al retardo mínimo que deben sufrir los paquetes (y por tanto el tamaño de los buffers en el receptor) dependiendo también del tamaño de los paquetes. En este y otros estudios, la captura de los datos multimedia realizada mediante Ethereal podría ser reutilizable.
REFERENCIAS [1]
[2] [3]
3) Conclusión De entre las dos métricas utilizadas, la segunda de ellas (porcentaje de paquetes perdidos) es la que tiene sentido en una transmisión de datos convencionales, por ejemplo ficheros. En este caso, un paquete erróneo deja de superar la prueba del checksum y es descartado por el propio protocolo TCP/IP. Sin embargo, en una transmisión de datos multimedia, podría resultar de utilidad la primera métrica (porcentaje de bytes perdidos), ya que un paquete erróneo, e imposible de recuperar, puede continuar conteniendo información válida para el receptor. Esto podría darse, por ejemplo, en una transmisión de vídeo, en la que un byte erróneo puede suponer un píxel erróneo en la imagen final. En tal caso, tiene más sentido obtener el paquete e interpretarlo erróneamente que descartarlo a priori.
IV. CONCLUSIONES En este trabajo, se ha construido una herramienta de simulación de redes con diferentes tasas de errores y se ha estudiado la influencia que tiene la aplicación de diferentes códigos FEC sobre cada una de ellas. Los resultados han demostrado que, para redes con una tasa de errores de 10-5, un código FEC de baja redundancia soluciona los errores de transmisión en su totalidad. Como término medio, redes con tasa de error de 10-4 necesitan aumentar en gran medida la redundancia (incluso superando el
8
[4]
[5] [6] [7]
C. E. Shannon. “A Mathematical Theory of Communication”. The Bell System Technical Journal, Vol. 27, pp. 379–423, 623–656, July, October, 1948. P. Elias, “Coding for noisy channels”, IRE Convention Record, pt.4, pp.37-47, 1955 Andrew J. Viterbi. Error bounds for convolutional codes and an asymptotically optimum decoding algorithm. IEEE Transactions on Information Theory 13(2):260–269, April 1967. Berrou C., Glavieux A., and Thitimajshima P. (1993). “Near Shannon limit error-correcting coding and decoding: Turbo-Codes,” ICC’93, Geneva, Switzerland, pp. 1064-1070, May. RFC 1889 and 3550 - RTP: A Transport Protocol for Real-Time Applications. RFC 2326 - Real Time Streaming Protocol (RTSP). RFC 2733 - An RTP Payload Format for Generic Forward Error Correction.