Real-time streaming en redes P2P: Plataforma SopCast (Mayo 2014)

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.