Real-time streaming en redes P2P: Plataforma SopCast (Mayo 2014)
Transcripción
Real-time streaming en redes P2P: Plataforma SopCast (Mayo 2014)
1 Real-time streaming en redes P2P: Plataforma SopCast (Mayo 2014) Juan Ant. Lajarín González, Estudiante, U.M.H. Abstract— En el contexto actual en el que el tráfico de video en internet supone el 55% del tráfico total, como se presenta en [1], [2], en 2016 se estima que se transporten por Internet 1.200.000 minutos de video (equivalentes a 833 días o a más de dos años) por segundo. La demanda de video en vivo está creciendo en importancia respecto a las otras formas de distribución (se espera que para el 2016 haya en todo el mundo 1500 millones de usuarios de video en Internet y la TV por internet represente un 6% del tráfico mundial). Dada la actual infraestructura de Internet, en donde todas las conexiones son punto a punto (unicast), y la existencia de grandes ráfagas de conexiones (a las que se encuentra expuesta la distribución de video en vivo), surgen varios problemas, entre los que podemos destacar: los problemas de escala, los problemas de costos y a los problemas de cuellos de botella. Además de esto, el hecho de escalar la red (por ejemplo aumentando la cantidad de servidores) sin una estricta planificación, puede causar congestiones en ciertos sectores de Internet, lo que implica una mayor tasa de pérdidas de paquetes y por lo tanto un peor servicio brindado a los usuarios finales, motivo por el cual, escalar una solución de distribución de video, no implica simplemente agregar más recursos, sino que es necesario ubicar dichos recursos lo más cercano al usuario final con el fin de evitar los cuellos de botella. Como solución a estos problemas, aparecen los sistemas de streaming entre pares, o también llamados P2PTV (Peer-to-Peer TV). Estos sistemas crean redes virtuales a nivel de aplicación sobre la infraestructura de Internet, en donde los nodos de la red, llamados pares, en adelante peers, ofrecen sus recursos (ancho de banda, capacidad de procesamiento y capacidad de almacenamiento) a otros nodos de la red, básicamente porque entre estos comparten intereses en común. Como consecuencia, al aumentar la cantidad de usuarios en la red, también aumenta la cantidad de recursos disponibles, solucionando así el problema de escalabilidad. Por otro lado, el ancho de banda requerido por el ISP (o por quien se encuentre a cargo de la distribución del contenido), disminuye considerablemente, sucediendo lo mismo con los costos asociados a la distribución. Además de esto, los nodos que sirven a un peer pueden ser elegidos según un criterio de proximidad, evitando de esta manera los cuellos de botella en la red. Como desventaja, señalar que estos sistemas deben tratar con recursos muy dinámicos (los peers se conectan y desconectan de la red con una alta frecuencia, en forma autónoma y asíncrona), lo que impone restricciones a nivel de control, dado que la red debe ser robusta para soportar estas fluctuaciones. En la actualidad existen algunas redes P2PTV comerciales muy exitosas, tales como: PPlive [3], TVUnetwork [4], Octoshape [5], SopCast [6], etc. En este artículo se ha estudiado la plataforma SopCast mediante la experimentación en laboratorio. Index Terms—live-streaming, network, P2P, proxy, SopCast. I. INTRODUCCIÓN H ay diversas formas de conectarse a una red P2P. ¿Cuáles son esas formas? Podemos tener dos tipos: descarga como usuario estándar de la red o descarga a través de proxy. Pero, ¿Cual consume menos recursos de red? Estos son los temas que se han abordado en este artículo. La optimización de los recursos de la red es un tema interesante para el futuro ya que nos permite un mejor aprovechamiento de las redes compartidas y permite un mejor balanceo de la utilización de las mismas. Para tomar estas decisiones de la mejor forma posible, es necesario recopilar datos suficientemente consistentes para poder sacar conclusiones inequívocas respecto a los métodos a implementar y desarrollar en un futuro próximo, de forma que podamos ofrecer los mejores servicios a un coste computacional y de red asumible para más empresas, beneficiando también al usuario final que podrá formar parte activa de la distribución de contenidos. Una vez explicados los motivos que nos han empujado a la realización de este artículo, pasamos a exponer los objetivos que planeamos conseguir. 1º.- El estudio del protocolo usado por la aplicación SopCast. Analizar los tipos de comunicación y la generación de formato y pieza de la aplicación, así como su funcionamiento para la emisión y recepción de un video en directo. 2º.- El estudio y diseño de diferentes topologías de red usando Streaming-P2P. Estudiar las dos alternativas (estándar y a través de proxy) de descarga y visualización de contenidos online y realizar su implementación. 3º.- Estudiar el rendimiento de la red de dichas topologías bajo distintas condiciones de uso: transmisión, recepción y número de usuarios. II. TRABAJO RELACIONADO A. Streaming P2P Una red P2P (peer-to-peer) es una red de ordenadores en la que todos comparten información, es decir, todos actúan como cliente y como servidor a la vez. De forma que quien tiene 2 información disponible es susceptible de enviarla a otros usuarios de la red. Así, todos los usuarios pueden hacer conexiones con cualquier otro para transferir los datos que éste demanda. Una red P2P aprovecha, administra y optimiza el uso del ancho de banda de los demás usuarios de la red por medio de la conectividad entre los mismos, y obtienen así más rendimiento en las conexiones y transferencias que con la mayoría de métodos centralizados convencionales, donde una cantidad relativamente pequeña de servidores, provee el total del ancho de banda y recursos compartidos para un servicio o aplicación. Algunos programas típicos de compartición de datos a través de P2P son: eMule, Ares y bitTorrent entre otros. El streaming hace referencia a una modalidad de distribución de contenido, en la que el usuario visualiza dicho contenido a la vez que lo está descargando. Esta tecnología funciona a través de un buffer de datos que almacena lo que se va descargando para luego mostrárselo al usuario. La peculiaridad de este método de descarga reside en que la descarga tiene que ser ordenada para una correcta visualización sin interrupciones. Hay diversos programas que permiten hacer el streaming posible, pero quizás el más conocido sea Youtube. Está claro que ambas tecnologías presentan grandes ventajas, por lo que una combinación de ambas podría resultar muy beneficiosa tanto para el cliente como para los servidores de contenido multimedia. Así nace el streaming-P2P. El streaming-P2P permite la compartición de información entre clientes de la red, en este caso, entre los conectados a un mismo stream. Es decir, un ordenador es el emisor, en adelante broadcaster, de dicho stream, y los clientes se conectan a dicho servidor y según van descargando la información del servidor, pueden compartirla con otros. Esto presenta grandes ventajas tanto para clientes como para servidores, maximizando así el uso del ancho de banda (ventaja P2P) entre clientes de forma que es más difícil saturar al servidor, y se permite la visualización del contenido a la vez que se descarga (ventaja streaming). III. SOPCAST Como hemos mencionado anteriormente, el streaming-P2P presenta grandes ventajas, ya que combina dos tecnologías ampliamente implantadas y utilizadas hoy en día. Un ejemplo de esta tecnología y a través de la cual hemos canalizado gran parte del desarrollo de este artículo es SopCast. SopCast es una aplicación P2PTV gratuita, pero de software cerrado, nacida como un proyecto de estudiantes de la Universidad China de Fundan dedicada a la distribución de vídeo en tiempo real usando protocolo “peer to peer”. En concreto, SopCast desarrolla un protocolo de transporte, el cual es una extensión del protocolo BitTorrent [7] optimizado para la transmisión de video en directo. Hemos estudiado los aspectos más importantes del protocolo bitTorrent de una forma resumida, para luego profundizar en el protocolo modificado de SopCast. A. Estructura bitTorrent Una red en bitTorrent está formada por: Peers (pares): Se denomina así a todos los usuarios que están en la red. Leechers (sanguijuelas): Se denomina así a todos los usuarios que están en la red descargando el archivo pero que todavía no tienen el archivo completo. También se llama despectivamente a quienes descargan archivos pero no los comparten. Seeders (semillas): Son los usuarios de la red que poseen el archivo completo. Trackers (rastreadores): Un tracker de bitTorrent es un servidor especial que contiene la información necesaria para que los pares, en adelante peers, se conecten unos con otros. Inicialmente es la única forma de localizar qué usuarios contienen el archivo que se quiere descargar. Swarm (enjambre): El swarm son los usuarios en general que el tracker se encarga de buscar. El nombre es debido a la similitud con las abejas y su comportamiento; en esta analogía, el tracker es el panal de abejas, el enjambre de abejas son los usuarios y la miel es el torrent con el contenido. B. Mecánica del funcionamiento bitTorrent 1º.- Un usuario baja de un servidor web un archivo .torrent que contiene la información del fichero que queremos descargar. Entre otra mucha información contiene la dirección del tracker al que nos tenemos que conectar para unirnos al enjambre de peers (el .torrent generalmente es un archivo muy pequeño, de unos pocos kilobytes). 2º.- Este archivo .torrent se abre con la aplicación P2P, que sabe interpretar dicha información. 3º.- El tracker y el peer se comunican a través de una 'conexión HTTP'. El tracker informa de la lista de todos los peers y seeds que contienen partes del archivo que queremos descargar. El tracker se actualiza con la información del nuevo peer que acaba de ingresar. 4º.- Una vez que el peer sabe dónde tiene que buscar las partes necesarias, este peer se comunica con otros mediante 'sockets UDP' y el archivo empieza a descargarse en el ordenador del usuario. Cada parte descargada se comparte automáticamente con otros peers. El siguiente diagrama ilustra la estructura descrita: Figura 1- Estructura funcionamiento bitTorrent 3 A propósito de entender mejor el funcionamiento de una red P2P se propone la utilización de un simulador gratuito y accesible a través del siguiente enlace: http://mg8.org/processing/bt.html. Como podemos preveer y como se puede experimentar en el simulador el punto fuerte de bitTorrent es que, cuando varios espectadores se conectan a un mismo broadcaster, estos pueden enviarse datos entre sí, realizando balanceo de carga y evitando congestión en el broadcaster. C. Archivos .torrent y su codificación interna Los archivos .torrent contienen información acerca del archivo que queremos bajar. Esta información está codificada mediante Bencoding. Si abrimos con un editor de texto un archivo .torrent nos encontramos con un diccionario que contiene las siguientes claves: info: Un diccionario que describe los archivos del torrent. Puede tener una u otra estructura dependiendo de si el torrent es para bajar un archivo o varios archivos con una jerarquía de directorios. announce: cadena que representa la URL del tracker announce-list: (lista de cadenas opcional). Se usa para representar listas de trackers alternativos. Es una extensión a la especificación original. creation date: (entero opcional) La fecha de creación del torrent en formato de época UNIX. comment: (cadena opcional) Campo libre para el creador del torrent. created by: (cadena opcional) Nombre y versión del programa usado para crear el archivo torrent. El diccionario info que acabamos de citar contiene a su vez las siguientes claves: name: (cadena) El nombre del archivo o directorio donde se almacenarán los archivos. piece length: Como dijimos en la introducción, el archivo que queremos compartir es dividido en piezas. Este parámetro es un entero que representa el número de bytes de cada pieza. Piezas demasiado grandes causan ineficiencia y piezas demasiado pequeñas forman un archivo .torrent más pesado. pieces: Cadena que representa la concatenación de la lista de claves hash de cada parte del fichero compartido. Las claves hash son generadas utilizando SHA-1 con un resumen de 160 bits y un tamaño máximo por parte de 2^64 bits. Este conjunto de claves se utiliza como mecanismo para asegurar la integridad y consistencia de una parte, una vez ha sido completada la descarga de dicha parte. private: (opcional). Es un entero que puede tener valores 0 ó 1 y que indica si se pueden buscar peers fuera de los trackers explícitamente descritos en la meta-información o no. length: (entero) Longitud del archivo en bytes. md5sum: (cadena opcional). Es una cadena hexadecimal de 32 caracteres correspondiente a la suma MD5 del archivo. files: Sólo aparecerá en el caso de que sea un torrent multiarchivo. Es una lista de diccionarios (uno para cada archivo, pero con una estructura diferente a info). Cada uno de estos diccionarios contendrá a su vez información sobre la longitud del archivo, la suma MD5 y una ruta (path) en donde debe ubicarse el archivo en la jerarquía de directorios. D. Conclusiones bitTorrent El protocolo bitTorrent muestra todo su potencial en la cooperación de peers. Introduce los conceptos de dar para recibir (sustentado y típico de la teoría de juegos), de pedir el primero más raro (para maximizar la entropía y por ende la disponibilidad de la red), y del desbloqueo optimista, para dar oportunidad a nuevos peers de establecer una comunicación y cambiar las perspectivas de peers bloqueados. Si bien la política de solicitar la primera pieza más rara funciona para descarga de contenidos estáticos, no conforma los requerimientos de tiempo real, básicos en una red de streaming de video. Además, bitTorrent está pensado para descargar contenidos de tamaño fijo, pero no un flujo continuo e ilimitado. Surge naturalmente en estos tipos de redes, la necesidad de consultar por piezas más próximas a la línea de reproducción. Pero por otra parte, solicitar siempre piezas más próximas a la línea de reproducción es una técnica golosa y no escalable. Se necesita aquí un delicado equilibrio que reside en lograr una calidad de reproducción satisfactoria al ojo humano (no perder piezas de video), pero a su vez cuidando el tiempo de latencia inicial. Es por ello que SopCast deberá introducir algunas modificaciones para optimizar el protocolo de distribución del streaming P2P. IV. EXPERIMENTOS DE LABORATORIO En esta sección hemos investigado las bases del mecanismo de SopCast mediante los experimentos en el laboratorio. A. Tipos de comunicación Hay dos tipos de comunicación: tracker-peer y peer-peer. La comunicación tracker-peer se realiza al comienzo de la sesión para obtener una lista actualizada de canales y peers disponibles para la conexión de datos, este tipo de conexión se realizará periódicamente para el mantenimiento y actualización de la información. La conexión peer-peer es la que se da entre usuarios de SopCast, la que puede ser considerada como comunicación normal, intercambio de datos de vídeo. Figura 2- Red Mallada SopCast P2P La Figura 3 muestra las conversaciones establecidas entre tracker-peer y peer-peer vistas desde un peer de nuestro experimento, en concreto desde el peer con IP: 10.1.52.79. 4 conectar más de ocho peers es mínimo. Según otros estudios [9], [10], los autores alcanzan una conclusión parecida. Observaciones empíricas los llevan a concluir que estar conectado activamente a cuatro peers es lo adecuado. Basándonos en estos estudios [8], [10], crearemos una infraestructura P2P como la que se muestra en la Fig. 5. Esta infraestructura está compuesta por ordenadores personales participando en una red pequeña. En concreto tenemos cuatro ordenadores receptores, y un quinto usado como broadcaster de un canal de live-streaming creado para la asignatura llamado CDN, con un channel ID=155265. Este canal previamente se ha tenido que registrar en la lista de canales de SopCast. Además, uno de los tres ordenadores clientes será usado como Proxy de otro ordenador externo a la red P2P usando VLC. TABLA I IP’S COMPONENTES RED P2P Figura 3- Conversaciones UDP en peer SopCast B. Generación de contenido y formato de la pieza Aplicando técnicas de ingeniería inversa, SopCast se basa en el protocolo bitTorrent como ya hemos indicado anteriormente, con una selección de canal a partir de un webtracker, y transferencia de video a partir del uso de piezas. Utiliza dos formatos de video: Windows Media Video (VC-1) y Real Media Variable Bitrate (RMVB), con tasas que varían de 250 kbps a 400 kbps, utilizando el reproductor de video del usuario. La política de reproducción no es Rarest First, pues se debe cumplir con la restricción de tiempo real. Tampoco se utiliza la técnica de tit-for-tat. Cuando un usuario ingresa a la red, sus peers vecinos (del mismo swarm) le envían piezas forzosamente al primero para minimizar la latencia inicial en la reproducción. El contenido del video codificado es dividido en piezas y distribuido a los peers mediante la red P2P SopCast. HOST IP BROADCASTER PEER 1 PEER 2 PEER 3/PROXY VLC 10.1.52.55 10.1.52.79 10.1.52.66 10.1.52.34 10.1.52.53 V. METODOLOGÍA DE LAS MEDIDAS EN EL LABORATORIO En el artículo [8], se muestra un modelo analítico para algoritmos basados en piezas. Reproducimos la Fig. 4 que muestra el efecto del tamaño del grupo de peer (el número de peers a los que se conecta otro peer) y el tamaño del buffer. Figura 5- Topología red P2P La recolección y decodificación está hecha con Wiresharck [11]. Los nodos corren sobre Windows XP. Hemos utilizado un archivo de video para su la emisión en live-streaming. El video utilizado tiene las siguientes características: TABLA II CARACTERÍSTICAS VIDEO AUDIO Figura 4- Efecto tamaño grupo Peer Podemos observar que el incremento en beneficio de Windows Media Audio Professional (WMAP) Canales: Estéreo Tasa de muestra: 48 MHz Bits por muestra: 32 VIDEO Windows Media Video 9 (WMV3) Resolución: 720x540 Tasa de fotogramas: 29.970089 Formato decodificado: Planar 4:2:0 YUV 5 Si queremos una calidad de vídeo que se vea bien en móviles, podríamos apuntar a un bitrate (tasa de bits) de 200 Kbps. Si queremos dirigirnos a un público de ordenadores de escritorio, necesitaríamos un vídeo de mayor calidad, por lo que podríamos aconsejar un bitrate en torno a los 400 Kbps. Si queremos un vídeo de alta calidad podemos pensar en un bitrate de 800 Kbps. Para vídeo en HD (alta definición), necesitaríamos un bitrate en torno de 1300 Kbps. Nosotros escogemos un video con calidad de escritorio, por lo que según las especificaciones del fabricante nos serviría con un único servidor con capacidad de ancho de banda de subida de 2 Mbps (400Kbps x 5). En los peers bastará con buscar el canal creado en SopCast con la siguiente dirección sop://46.246.89.189:3912/155265 y esperar a recibir el stream. llegan desordenados, se necesita un esquema para mantener el seguimiento de los trozos de video que necesitan ser ensamblados ordenadamente y puestos en buffer, y en el caso de que un trozo se pierda, recuperarlo. Esto explica el coste en UDP. En la siguiente gráfica vemos el coste total de tráfico UDP en la red. VI. RESULTADOS LABORATORIO En naranja se muestran los paquetes/segundo transmitidos por el protocolo UDP y en azul el total de paquetes/segundo transmitidos en una retransmisión con SopCast. Podemos observar que SopCast utiliza el 99,6% del tráfico de nuestra red. Se presentan las observaciones encontradas basadas en el experimento en el laboratorio y en los artículos de investigación [8], [12]. A. Protocolo de transporte El uso del analizador de red Wiresharck, nos ha revelado que SopCast recae en tráfico UDP. En la Fig. 6 se ha dibujado el histograma del tamaño de paquetes. Podemos observar dos picos: uno cae en la región entre 65-127 bytes y el otro en 1024 -1517 bytes. Los paquetes pequeños son reconocimientos de aceptación de la capa de aplicación de los paquetes de datos enviados y recibidos. Los paquetes más grandes, con el tamaño aproximadamente igual al MTU (Maximun Transfer Unit) para paquetes IP sobre Redes Ethermet, son los paquetes de video. 80 70 60 50 40 30 20 10 0 Figura 6- Jerarquía Paquetes Esta figura indica que SopCast enfrenta un alto coste, sobre el 60% en señalización de paquetes contra el 40% de paquetes de video. Este resultado era el esperado ya que el protocolo trabaja en lo más alto de UDP, que no garantiza fiabilidad en la manera que TCP lo hace. Los paquetes puede que lleguen desordenados, aparezcan duplicados, o se hayan perdido sin noticia. Para aplicaciones sensibles en el tiempo, UDP es la elección más razonable, porque se prefiere la eliminación de paquetes a retrasos en los mismos, aunque hay que mantener un control mínimo del estado de los trozos. Desde que los trozos 0 17 34 51 68 85 102 119 136 153 170 187 204 221 238 255 272 289 3000 2500 2000 1500 1000 500 0 Figura 7- Tráfico IP vs UDP B. Intercambio entre Peer y arquitectura Cuando SopCast arranca, requiere algún tiempo para buscar los peers y en consecuencia intenta descargar información de los peers activos. Se han recogido dos tipos de retraso de arranque: el retardo desde que un canal es seleccionado hasta que el reproductor de streaming salta, y el retardo desde que salta el reproductor hasta que la reproducción comienza. El retardo hasta que salta el reproductor es en general de 20 a 30 segundos. Este es el tiempo para que SopCast recoja la lista de peers y los primeros paquetes de video. El retardo del buffering del reproductor es de alrededor de 10 a 15 segundos, lo cual puede variar entre reproductores y no está relacionado con SopCast. En resumen, el tiempo que pasa para un usuario en disfrutar del streaming está entre 30 y 45 segundos. Examinando el tráfico generado por cada nodo, encontramos que la principal tarea de cada nodo receptor es enviar un mensaje de solicitud al servidor del canal SopCast para obtener una lista actualizada del canal. Este servidor ha sido identificado con un localizador de IP, localizándose en Suecia (IP: 46.246.89.189). Antes de que un peer comience a ver el canal, este no hace intercambio de datos con otros peers de SopCast. Después de que el peer seleccione un canal para ver, éste envía múltiples mensajes de solicitud a algunos servidores raíz para recuperar una lista de los peers online para este canal. Los peers son identificados en la lista por sus direcciones IP y números de puerto. Una vez recibida una lista de peer, el cliente SopCast envía pruebas a los peers de la lista para encontrar peers activos para el canal que le interesa. Algunos peers activos puede que también devuelvan su propia lista de peer, ayudando al peer inicial a encontrar más peers. Los peers entonces comparten piezas de video entre ellos. Después de contactar al tracker, los nodos forman una malla 6 C. Técnicas de Buffering Las piezas recibidas son almacenadas en el buffer de SopCast. El buffer es el responsable de descargar las piezas de video desde la red y de enviar las piezas de video descargado a un reproductor de video local. El proceso de streaming en SopCast atraviesa dos buffers: el buffer de SopCast y el buffer del reproductor, como muestra la siguiente figura: Un peer. Upstream 10 10,34 8 D. Estructuras de red El experimento continúa con la medición de los diferentes escenarios de red planteados a continuación. Para poder distinguir el consumo de red de los distintos tipos de usuario hemos contemplado el diseño de 2 escenarios distintos. El primero de ellos intenta cuantificar la capacidad consumida por un broadcaster y los peers. El segundo escenario está diseñado para averiguar el consumo de un peer externo a la red P2P que escucha a través de un VLC. Las pruebas que se van a realizar tienen una duración de 5 minutos cada una, de forma que los resultados son fácilmente trasladables a períodos de actividad mayores. Así, hemos contemplado los siguientes casos: 1º.- Transmitiendo / Recibiendo con SopCast (Escenario 1). • Un peer. • Dos peers. • Tres peers. 2º.- Recibiendo por VLC desde SopCast (Escenario 2). Medimos el total del ancho de banda utilizado por cada usuario tanto en upstream como downstream. Si ampliamos la red, los proveedores de servicios tienen en cuenta estas demandas y hacen caches temporales. 10,34 6 4 2 0,663 0,663 0 Broadcaster Peer Figura 9- Gráfica un especatador Vemos que todo el tráfico de subida del broadcaster es absorbido por el peer y simplemente intercambian datos de señalización y sincronismo, además del streaming. Dos peers Figura 8- Buffer SopCast Upstream Downstream 20 15 MBYTES Cuando la longitud del archivo de streaming excede un determinado umbral en el buffer de SopCast, este lanza un reproductor, el cual descarga el contenido de video desde un servidor web local escuchando por el puerto 8902. La mayoría de reproductores tienen incluidos mecanismos de buffering de video. Después de que el buffer del reproductor se llene hasta el nivel requerido, comienza la reproducción del video. Downstream 12 MBYTES aleatoria conectada que es usada para enviar el contenido mediante peers individuales. La información se envía de padre a hijo peer. Excepto la fuente, cada peer tiene múltiples padres y múltiples hijos. El envío es desempeñado con pull requesting por los peers hijos, significando que un nodo explícitamente solicita los segmentos de interés para sus vecinos de acuerdo con sus notificaciones. Cada peer recibe contenido de todos sus padres y provee contenido a todos sus peers hijos. 16,82 10 10,34 10,34 5 1,22 1,67 1,56 0 Broadcaster Peer Peer Figura 10- Gráfica dos peeres En la emisión con dos peers empezamos a observar que se reduce la subida de datos del broadcaster a la red, descongestionando un poco la red del emisor, mientras que en los peers aumenta la transferencia de subida con las piezas de video que empiezan a compartir. Tres peers Upstream 30 Downstream 25,235 25 20 15 10,175 10,14 10 5 9,57 4,65 1,2 1,56 1,89 0 1) Escenario 1 En este primer escenario se cuantifica el tráfico de red consumido por el broadcaster y la influencia del aumento del número de peers. Vamos a centrarnos solamente en las conversaciones UDP ya que son las portadoras del streaming. Broadcaster Peer Peer Peer Figura 11- Gráfica tres peers En esta simulación se sigue observando la tendencia de los peers a gestionar las piezas de video compartiéndolas con sus 7 vecinos, la progresión será mayor cuanto más peers hayan conectados a una emisión. En comparación con un streaming tradicional vemos que se está ahorrando un 6% de congestión al broadcaster. reconstrucción en el ámbito de la compresión de imágenes. 2) Escenario 2 En este escenario utilizamos un peer como proxy y retransmitimos lo que nos llega en directo por el puerto: 8902 mediante VLC, que desde otro equipo externo a la red P2P escucha esta emisión. Upstream Downstream MBYTES 30 28,148 25,235 20 10 Figura 13- Funcionamiento PSNR 36,728 40 4,72 10,175 1,2 10,14 9,57 1,56 0,1 El PSNR se expresa generalmente en escala logarítmica, utilizando como unidad el decibelio y podemos establecer una relación entre calidad de video y PSNR como se indica en la tabla III. TABLA III 0 RELACIÓN CALIDAD PSNR Valor PSNR Figura 12- Gráfica con Proxy Podemos comprobar como primera observación que debido al protocolo escogido y a la codificación (Video- H.264 + MP3 (MP4)) que realizamos en el proxy para emitir el streaming por VLC, la retransmisión tiene mayor tasa de bits, en torno a 750,61 Kbps frente a los 296,86 Kbps en la red P2P, lo que requerirá mayor ancho de banda de subida al peer, aproximadamente 3,5 Mbps (750Kbps x 5). Además se puede ver como el ordenador, externo a la red P2P, no tiene que usar el enlace de subida para compartir las piezas de video con otros peers, evitando carga en la red local, todo lo contrario que le sucede al proxy, que asume toda la descarga del stream además de la codificación y reemisión. Esta circunstancia nos sugiere replantear la distribución de contenidos: Los operadores ISPs podrían utilizar unos proxys locales ubicados estratégicamente para retransmitir el contenido recibido por la red P2P, evitando congestión a los usuarios y en consecuencia a la red, o bien por parte del suministrador, alquilar un servicio de CDN como Akamai para dar mejor experiencia al usuario. E. Calidad de video 1) PSNR En este apartado usamos el software MSU Video Quality Measurement Tool [13] para hacer una medida comparativa objetiva del video original emitido por el broadcaster y el recibido por el peer. Para ello grabamos el video recibido y utilizamos la herramienta para comparar su Relación Señal a Ruido de Pico o PSNR con el video original. La Figura 13 muestra el funcionamiento convencional del cálculo del PSNR en una emisión de video stream, en el cual vemos que se comparan los frames que no corresponden con el video original y se calcula como medida cuantitativa de la calidad de la PSNR > 33dB 33 dB > PSNR > 30 dB PSNR < 30 dB Calidad Excelente Buena Mala A continuación mostramos la tabla para la interpretación en términos de calidad de video stream respecto al PSNR, usada en otros artículos como [14]. La Figura 14 nos muestra los valores de PSNR que obtenemos con la aplicación MSU comparando el video original y el video recibido por el peer. Figura 14- Medida PSNR De estos resultados sacamos el valor medio del PSNR, que para nuestra comparación de calidad es de 31,32605 dB, estando en el promedio de una buena calidad de video. 2) VQM (Video Quality Metric) VQM mide los efectos percibidos de deficiencia de video incluido el difuminado, el movimiento errático, el ruido global, la distorsión de bloque y la distorsión de color, combinándolas en una única métrica. VQM coge el video original y el procesado y calcula resultados cualitativos que reflejan la predicha fidelidad del video procesado. Para hacer eso, el video ejemplo necesita ser calibrado. La calibración consiste en estimar y corregir el 8 desplazamiento espacial y temporal con respecto a la secuencia original de video. El resultado final es calculado usando una combinación lineal de parámetros que describen cambios perceptuales en la calidad de video comparando características extraídas del video procesado con las extraídas del original. El resultado final se escala en un MOS (Mean Opinion Score), una medida para la calidad de percepción del usuario, definida en una escala de cinco puntos; 5 = excelente, 4 = muy bueno, 3 = bueno, 2 = malo, 1 = muy malo [15]. Obtuvimos los siguientes resultados VQM en los tres peers receptores. MOS 6 5 4,73595 4,52792 Peer Peer Umbral 4,83783 4,32452 4 3 2 1 0 Peer VLC Figura 15- Gráfica comparativa VQM El umbral mínimo para una calidad aceptable corresponde a MOS = 3,5. Los resultados de VQM son altos, solo se ha observado una degradación insignificante al volver a comprimir y emitir el streaming al ordenador con VLC externo a la red P2P. Esto sugiere que SopCast no hace ningún tipo de codificación al video emitido por el broadcaster. Los efectos de una alta tasa de reproducción pueden ser latencias en el video y posibles bloqueos de imagen. El protocolo SopCast, a favor de enviar el video, prefiere un video blocking vaciando el buffer, que degradar la calidad de imagen. Ya que SopCast recae en tráfico UDP, se espera que algunos frames se pierdan, de cualquier modo, SopCast no expermienta una degradación en la calidad de la imagen, significando que en términos generales la experiencia es buena. De manera subjetiva podemos ver el cuadro o frame número 4029 del video original y del video recibido para comparar la calidad del video. VII. CONCLUSIONES La intención de este trabajo era entender, con una serie de experimentos, el comportamiento del popular sistema de streaming llamado SopCast. Mediante medidas pasivas, caracterizamos el comportamiento de Sopcast y la experiencia de usuario. Basándonos en nuestras medidas podemos concluir que: Sopcast puede proveer buena calidad de video a los peers emitiendo desde un PC SopCast, aun usando UDP, no muestra deficiencia en el video recibido respecto al original. Por otra parte y como consecuencia del trabajo realizado, podemos comprender la situación actual de las redes P2P. Las redes P2P son más eficientes que las redes tradicionales modalidad cliente-servidor. Esto ha permitido una mayor oferta de contenidos y a su vez más demanda. La arquitectura de estas redes contrasta con el modelo cliente-servidor, en esta los peers participan activamente en la distribución del video, ofreciendo sus recursos para que todos logren obtener el contenido. La cooperación entre los peers es entonces un elemento crucial y característico en estas redes. Los problemas que pueden surgir a causa de la utilización de las redes P2P pueden ser: Tráfico excesivo e ineficiente. El uso indiscriminado de enlaces costosos. Comunicación congestionada entre peers lejanos. A consecuencia del incremento del tráfico debido a las aplicaciones P2P, surge la metodología P4P (Participación Proactiva del Proveedor en redes P2P). Existe un grupo llamado P4P Working Group que estudia su implementación. El objetivo de la metodología es lograr mediante la comunicación explícita entre aplicaciones P2P e ISPs una mejor performance en el tráfico de contenidos P2P, y un uso más eficiente de los recursos de la red, acercando los contenidos a los usuarios. La tendencia evolutiva está siendo acercar los contenidos al usuario como se puede observar en la Figura 17. Figura 17- Evolución CDN Figura 16- Comparativa frame nº 4029 (Original/Recibido) Como se puede observar la diferencia de calidad de imagen es casi inapreciable a simple vista. Siguiendo la estructura representada en la Fig. 18 podemos observar los componentes y el funcionamiento de P4P: 1º.- Los peers consultan al iTracker por la topología y la política. 2º.- Los peers envían esta información al appTracker. 3º.- El appTracker selecciona los peers, considerando la información del iTracker y los requerimientos de la aplicación. 9 [14] H. A. A. R. A. B. Yoanda Alim Syahbana, «Aligned-PSNR (APSNR) for Objective Video Quality Measurement (VQM) in Video Stream,» IEE, 2011. [15] ITU-T Rec. P.800, «Methods for Subjective Determination of Transmission,» 1996. [16] A. K. A. S. a. Y. R. Y. H. Xie, «P4P: Proactive Provider Participation for P2P. Technical report,» Yale University, Department of Computer Science, 2007. [17] N. p. q. p. a. P2P, «Genbeta,» [En línea]. Available: http://www.genbeta.com/multimedia/netflix-parece-querer-pasarse-alp2p. Figura 18- Figura extraída de [16] Nos aparecen entonces dudas sobre la implementación de la metodología P4P, ya que nos encontramos ante objetivos contrapuestos. Los peers quieren maximizar el tráfico sin preocuparse por los recursos disponibles de la red y los ISP quieren minimizar el tráfico por los enlaces más costosos. En un futuro estaremos atentos a las decisiones que se puedan tomar en torno a las redes P2P y los acuerdos en la metodología P4P. Para concluir, señalar que grandes empresas de distribución de contenidos como Netflix están buscando ingenieros expertos para implantar una red P2P en sus servicios de streaming [17], esto es sin duda una apuesta por esta estructura que puede revolucionar comercialmente el mundo de la distribución de contenidos, ejerciendo presión a los ISPs para llegar a acuerdos sobre distribución de contenidos. AGRADECIMIENTOS Agradezco el trabajo a los compañeros y al profesor que me ha guiado para conseguir los hitos propuestos. VIII. REFERENCIAS [1] «Cisco Systems, Inc. Hyperconnectivity and the Approaching Zettabyte Era.,» 2010. [2] Cisco, «VNI Forecast,» 2012. [En línea]. [3] PPLive, «http://www.pptv.com/,» [En línea]. [4] TVUnetwork, «http://www.tvupack.com/,» [En línea]. [5] Octoshape, «http://www.octoshape.com/,» [En línea]. [6] SopCast, «Página Web de la aplicación SopCast,» [En línea]. Available: http://www.sopcast.com/. [7] Forum, «bitTorrent,» [En línea]. Available: http://forum.bittorrent.com/. [8] A. M. a. H. Z. Shahzad Ali, «Measurement of Commercial Peer-ToPeer Live,» School of Computer Science, 2006. [9] S. T. a. L. Kleinrock, «Analytical Model for BitTorrent,» IEEE Wksp. Networking, 2007. [10] X. Zhang, «Coolstreaming/DONet: A Data-driven,» IEEE INFOCOM, 2005. [11] Wiresharck, «Página Web de Wiresharck,» [En línea]. Available: http://www.wireshark.org/. [12] X. Hei, «A Measurement Study of a Large-Scale P2P IPTV System,» Polytechnic University, Brooklyn, NY, USA 11201, 2007. [13] MSU Video Group, «Web de la aplicación MSU Video Quality Measurement Tool,» [En línea]. Available: http://www.compression.ru/video/. [18] C. L. J. L. Y. L. Xiaojun Hei, «A Measurement Study of a Large-Scale P2P IPTV System,» 2007.