Como se especificó en la entrada:
la tarea de esta semana consistió en analizar la calidad del servicio QoS de una aplicación en internet
Para mi tarea establecí las siguientes condiciones:
- Stream de video desde http://www.youtube.com
- Conexión cableada a internet mediante interfaz ethernet
- Red infinitum
- Banda ancha promedio de 2.88Mbps de bajada al momento del experimento
- Video a 480p de resolución.
Los parámetros a analizar son:
- Latencia
- Jitter
- Perdida de paquetes
- Tasa de transferencia
Los resultados esperados de acuerdo a la teoría investigada son:
- Latencia: menor a 150ms
- Jitter: menor a 50ms
- Perdida de paquetes: menor o igual al 3% del volumen de datos transmitido
- Tasa de transferencia:
- Video a 480p con codec FLV o WebM = 1Mbps aprox.
- Audio con codec AAC o Vorbis = 128Kbps
- Valor teórico esperado = 1152Kbps o 1.2Mbps aprox.
1. Medición de latencia y Jitter
Metodología
Como primer herramienta para calcular la latencia utilicé el comando ping a la url www.youtube.com.
Escribí un pequeño script en python para automatizar la tarea pues realicé la medición con 300 paquetes.
Se midió la latencia para esos 300 paquetes y se calculo el promedio y la desviación estándar. Después a partir de las 300 mediciones de la latencia se calculó el jitter promedio.
Ejecución
Pantalla de resultados
Resultados
La ejecución produce dos archivos los cuales posteriormente grafiqué, obteniendo lo siguiente
| Latencia | Jitter |
|---|---|
 |  |
- Latencia promedio: 47.115ms
- Jitter promedio: 17.425ms
Podemos ver como la latencia permanece estable, con un promedio de 47ms lo cual significa que el primer parámetro de medición de QoS esta en excelentes condiciones.
Lo mismo pasa con el Jitter, ya que la medición permanece debajo de 20ms lo cual también es excelente.
2. Medición pérdida de paquetes
Después de un rato de pensar que tenía problemas, me sorprendió descubrir que estuvé en un error desde el principio. Intentaba obtener los paquetes de Youtube filtrando UDP y descubrí que youtube utiliza TCP para sus transmisiones. Así que en realidad en un stream de video de Youtube no hay muchas pérdidas ya que el protocolo TCP al detectar un paquete perdido simplemente lo retransmitirá.
Entonces, para comprobar que todo esté en orden voy a medir la cantidad de retransmisiones de paquetes que se hacen durante la transmisión.
Metodología
Primero dediqué la mayor parte de mi banda ancha a Youtube, es decir, cerré otras páginas web abiertas. Despues busqué por el video seleccionado, y esperé.
Después abrimos Wireshark y vamos al menú: Capture > Interfaces
Seleccionar intefaces
En la ventana emergente seleccionamos la interfaz a escuchar, en mi caso es eth0, y presionamos el botón start.
Elegir la interfaz a escuchar
En la ventana principal, en el campo de texto que dice Filter escribimos TCP
Después rápidamente regresé al navegador, abrí el video, lo configuré a 480p y comencé la reproducción, después solo esperé a que el video terminara de reproducirse.
Resultados
Una vez terminada la reproducción, presionamos el botón Stop the running live capture, nos vamos al menú Statistics > Conversations, en la ventana emergente seleccionamos la pestaña TCP y en la tabla ordenamos los resultados de mayor a menor utilizando la columna Bytes A←B. Así la primera fila será la conversación con más bytes transmitidos, la cual debe ser el stream de video. Hacemos click en esa fila y presionamos botón Follow stream para filtrar solo los paquetes TCP que pertenecen a la comunicación con Youtube.
Conversaciones TCP
Una vez hecho ésto, veremos que en la ventana principal veremos los paquetes de la comunicación con Youtube, veremos también que el campo de texto Filter ha cambiado, ahora dice algo parecido a tcp.stream eq 11 (donde el último número puede variar ya que pertenece a un id interno de wireshark para clasificar las conversaciones). Dejamos ese filtro y escribimos después and tcp.analysis.retransmission. Con ello filtraremos los paquetes que fueron retransmitidos durante la reproducción.
Paquetes retransmitidos
En la parte de inferior de la ventana veremos dos valores, Packets y Displayed, estos valores nos ayudarán a calcular la pérdida de paquetes.
Packets indica la cantidad total de paquetes transmitidos durante toda la conversación, el cual fue de 21062. Displayed muestra la cantidad de paquetes retransmitidos filtrados, el cual fue de 913 , entonces, haciendo una regla de 3 obtenemos que el porcentaje de paquetes perdidos fue de 4.33%.
Para garantizar una buena calidad en el servicio se necesita tener una cantidad de paquetes perdidos menor o igual al 3% del volumen de datos transmitido, el resultado de esta medición nos indica que la cantidad de paquetes perdidos fue 1.33% arriba de lo permitido, por lo que ya esta fuera de los límites recomendados. Sin embargo la medición permanece por debajo del porcentaje permitido para las líneas ADSL el cual es de 5% del volumen de datos transmitido.
3. Medición tasa de transferencia
Metodología
La tasa de transferencia se analiza desde el menú Statistics > Conversations, en la ventana emergente seleccionamos la pestaña TCP y la tabla la ordenamos de mayor a menor utilizando la columna Bytes A←B. Así la primera fila será la conversación con más bytes transmitidos, la cual debe ser el stream de video.
Análisis de la tasa de transferencia
Resultados
Aqui nos interesan 3 columnas, las marcadas como Bytes A←B, Duration y bps A←B.
La columna Bytes A←B nos indica la cantidad de bytes transmitidos, el cual fue de 14 660 397bytes o 13.95MB aproximadamente, éste es el tamaño del video.
La columna Duration indica la duración de la conversación TCP en segundos, la cual fue de 440.21s, o aproximadamente 7.33 minutos.
La columna bps A←B muestra la tasa de transferencia, la cual fue de 266421.81bps o 266.422Kbps.
Aquí es donde obtuvimos los peores resultados, el valor teórico lanza una tasa de transferencia de 1.2Mbps aproximadamente, de acuerdo a los parámetros de codificación de Youtube; la medición práctica nos indica una tasa de transferencia de 266.422Kbps, es decir, aproximadamente un 22% de lo esperado.
El resultado no sorprende en realidad, ya que la duración real del video reproducido es de 5:33 minutos y la duración de la conversación fue de 7.33 minutos, 2 minutos de retraso.
También podemos ver que el valor teórico recomendado para la configuración del video recomendado es muy alto, posiblemente se utilizó un códec diferente para el video seleccionado.
Conclusiones
- Latencia
- Esperado: menor a 150ms
- Obtenido: 47.115ms
- Jitter:
- Esperado: menor a 50ms
- Obtenido: 17.425ms
- Perdida de paquetes:
- Esperado: menor o igual al 3% del volumen de datos transmitido
- Obtenido: 4.33% del volumen de datos transmitido
- Tasa de transferencia:
- Esperado: 1152Kbps o 1.2Mbps aprox.
- Obtenido: 266.422Kbps
Mientras la conexión con el servidor de Youtube se mantuvo muy limpia, la transmisión del video fue insatisfactoria.
Una alta pérdida de paquetes y tasas de transferencia tan bajas pueden ser indicador de una alta congestión en los servidores de la compañía.
Se concluye entonces que, bajo las condiciones establecidas para el experimento, la calidad en el servicio es insatisfactoria, lo que repercute en la experiencia de usuario.
Referencias:
- http://ask.wireshark.org/questions/5597/how-to-capture-traffic-from-youtube
- http://blog.davidvassallo.me/2011/01/07/identifying-network-latency-jitter-issues-w-wireshark/
- http://www.cardinalpeak.com/blog/?p=1054
- http://www.nessoft.com/kb/article/what-is-jitter-57.html
- http://www.wireshark.org/lists/wireshark-users/200802/msg00231.html
- http://ask.wireshark.org/questions/5675/how-to-analyse-througput-packet-loss-rtt-rather-than-go-through-the-graph-of-built-in-feature-of-wireshark
- http://www.wireshark.org/docs/dfref/t/tcp.html
Muy completo; 10 pts.
ResponderEliminarMuy bueno el análisis mi hermano, pero el script no funciona !! Podrías revisarlo
ResponderEliminar