Actividad #4 - Métricas de Calidad de Servicio

El experimento que se realizó para la clase, LINK_EXPERIMENTO contempla las siguientes métricas para medir la calidad de servicio de la conexión a internet.

Latencia o ping
Se puede explicar como el tiempo de respuesta entre dos puntos cuando se están enviando paquetes, que puede ocurrir debido a que toman la ruta menos corta para llegar al destino, que toman una ruta muy congestionada o también debido a su posición en las colas de envío/recepción.

Latencias muy grandes pueden resultar en pérdidas de conexión, especialmente durante una sesión de excesiva transmisión de datos como, llamadas VoIP, juego online, videos en streaming, etc.

Durante el experimento las latencias obtenidas con ping, era muy alto, tal vez por eso la sesión de hangout se cortaba a cada rato y aunque se recuperaba la conexión se volvía a perder.

Cantidad de paquetes perdidos
Se refiere a la cantidad de paquetes que tras ser enviados, no llegan a su destino debido a errores durante la encapsulación o a una incorrecta ruta de destino.

Esto se puede ver reflejado en llamadas VoIP como deformaciones/errores/manchas en la imagen o ruidos extraños en las voces. (al menos eso fué lo que me paso a mi :P).

Estas manchas o píxeles de colores estuvieron presentes la mayoría de la sesión del experimento.

Jitter
Los paquetes enviados desde cierta parte pueden llegar con diferentes retrasos hacia su destino, este retraso varía dependiendo de la posición del paquete en la cola que se va formando durante una transmisión de datos.
Según wikipedia, jitter se le denomina a la forma en que varía temporalmente el envío de señales digitales.
Básicamente es un cambio indeseado de cierta señal, que se considera como un ruido que afecta a esta señal provocando retraso en la recepción de los paquetes.

En el experimento esto se veía reflejado como lag durante la videollamada de hangout, la imagen se movía más lento de lo normal y la voz no iba acorde al movimiento de los labios, estaba muy retrasado y desfasado.

Una posible solución a esto, es la de crear un pequeño buffer de los paquetes y mostrarlos con un retraso para tener algo mas normalizado, pero contando con un retraso para poder obtener y organizados todos o la mayoría de los paquetes

_________________________________________________________________________________
Referencias:
http://en.wikipedia.org/wiki/Quality_of_service
http://www.ciscopress.com/articles/article.asp?p=357102
http://www.slideshare.net/prestonj_jag/calidad-de-servicio-en-redes

Experimento QoS

Estas pruebas se realizaron para medir la calidad de los servicios de la conexión a internet durante una sesión de Hangout de Google, en donde solo estaban conectados dos participantes.

Las métricas que se usaron para la medición del QoS fueron:

• Latencia(ping)
• Cantidad de paquetes perdidos
• Jitter

Estas están descritas en la entrada del laboratorio relacionada con esto: 

Cabe resaltar que durante los últimos días he estado teniendo dificultades con mi conexión a internet, por lo que la sesión de hangout era intermitente (conectaba y desconectaba a cada rato) y esto se puede ver reflejado en las pruebas.

Para las pruebas de QoS se hizo uso de la aplicación Wireshark y algunas herramientas de Windows.

Latencia

En la primera actividad se utilizó la herramienta que todos conocen para medir el ping o latencia en Windows, desde la terminal se escribe el comando "ping" seguido de la ip con la que se desea hacer la prueba, esto nos arrojará primeramente si estamos conectados o no, y posteriormente si lo estamos nos dara el tiempo de respuesta que tarda en hacer el envío y recepción de paquetes.

 Una gran latencia puede repercutir en la pérdida de la conexión, como en este caso tal vez eso estaba afectando a la sesión de hangout.

Cantidad de paquetes perdidos
Esto es fácil de entender, simplemente cuando se establece una conexión se estan constantemente enviando y recibiendo paquetes, la pérdida de paquetes ya sea por errores de encapsulación o porque su destino no es seguido correctamente,hace que la sesión se afecte por decir esto se puede reflejar en la videollamada de hangout como pérdidas parciales del video enviado o recibido, o audio entre cortado.
Para esta prueba se uso wireshark  y el filtro "tcp.analyse.lost_packets" y aquí esta el resultado:

Cómo se puede observar en la imagen, había constantes errores duarante la sesión de la videollamada y esto repercute en pérdida de la calidad de la imágen y el sonido.

Jitter
Como se mencionó en el lab, durante una conexión se envían y reciben un montón de paquetes con al información y jitter se refiere a la cantidad de paquetes que sufren un retraso durante su envío o recepción debido a su posición en las colas de envío o recepción.
La prueba si hizo con wireshark y aquí los resultados:

Esto se puede reflejar en la videollamada cuando se registra un lago en los movimientos que realice la persona o lag en la voz de la persona, donde lag me refiero a retrasos.

Esto afecta en gran medida en los videojuegos, debido a que grandes retrasos en los paquetes afectan en la visualización en tiempo real de las imágenes y hace frustante la sesión.

Transmisión de Datos
Otra prueba que hice fue la transmisión de bits durante la sesión, con esto se puede dar cuenta de la velocidad de transmisión de tu conexión, lo que aparentemente tu contratas como ancho de banda. Debido a la sesión intermitente la transmisión solo se realizaba en ocasiones como se puede ver en el siguiente gráfico:

Hubo ocasiones en que la transmisión era buena, pero en otra era pobre y en ocasiones nula.

Actividad #3 Lab: Coberturas de WiFi

Para esta entrada la actividad era monitorear la cobertura de las señales wifi disponibles en un punto "público", yo lo realice cerca de mi casa, donde había una buena cantidad de señales wifi.

Utilicé un dispositivo móvil con android para poder checar mejor la cobertura de las señales y poder tener un aproximado de su ubicación para poder dibujarlos en un mapa de google.

En el dispositivo móvil me apoye de una app llamada Wifi Analyzer que ayuda a mostrando la intensidad y la calidad de las redes wifi, además de otra información como el canal en que se difunde la señal, tipo de seguridad, etc. Si a alguien le interesa la app, aquí dejo el link a google play: Wifi Analyzer.

Aquí dejo unas capturas de la app funcionando, donde se muestra las intensidades de las distintas redes e información como la calidad, nombre, intensidad, etc.

intensidades de las señales disponibles

información más detallada de las redes disponibles

Y aquí una imagen del mapa de google con las coberturas de las redes dibujadas encima (con posiciones aproximadas):

Experimentos de Monitoreo WiFi

Lo que hice para esta entrada y para llevar a cabo una pequeña prueba con el wifi, fue un "ataque de des-autenticación" conocido como Ataque de Denegación de Servicios, que lo que hace des-autenticar  a un usuario en una red inyectando una gran cantidad de paquetes y con esto su conexión a internet se ve afectada dejándolo sin acceso a ninguna página.

Los pasos que seguí, son:

Primero conseguir una computadora con tarjeta wifi que soporte el cambio de operación de modo managed a modo monitor (batalle bastante en encontrar una compu compatible, en general las tarjetas intel no funcionan para esto, la que me funcionó fue una atheros que vienen en las netbooks acer).

Usando las herramientas de airmon, airodump y aireplay conseguí realizar todo, se pueden instalar en Ubuntu pero yo opté por usar otra distribución muy utilizada para auditorías y monitoreo wireless llamada Backtrack, que en sí es lo mismo solo que aquí ya vienen todas las herramientas necesarias. Y al igual que Ubuntu la puedes correr desde un usb, así lo hice yo porque la compu no era mía.

Para poner la tarjeta en modo monitor, ponemos en el terminal: airmon-ng start tarjetadwifi

Observamos las redes disponibles con : airodump-ng tarjeta_en_modo_monitor

Observamos el tráfico de la red que vamos a usar con:
airodump-ng --mac_punto_acceso  tarjeta_monitor

Identificamos a la víctima( su dirección mac).

Y procedemos a inyectar los paquetes para que dejarlo sin acceso a internet con:
aireplay-ng -0 0 -a mac_ap -c mac_víctima tarjeta_monitor

También podemos dejar sin acceso a internet a toda la red, esto solo incluyendo la mac del punto de acceso:

aireplay-ng -0 0 -a mac_ap tarjeta_monitor

Y por último los resultados en la compu que fue la víctima:

Al intentar acceder a las páginas solo se quedaban cargando pero nunca entraban y en ocasiones en el icono de conexión de red aparecía que la conectividad era nula.

Puse fotos de todo porque Backtrack me daba problemas al intentar sacar una captura de pantalla, era algo relacionado con la interfaz gnome.
Para esto usé dos compus (la mía y una prestada que funcionara el modo monitor) y la red wifi de mi casa.

_________________________________________________________________________________

Enlaces:

http://foro.elhacker.net/wireless_en_linux/guia_completa_aircrackng-t231434.0.html

http://www.backtrack-linux.org/

Actividad 2 - Infographic (conexión alámbrica)

Protocolos

La idea era crear un protocolo de transmisión de datos que funcionara en algún lado.

El protocolo que yo trate de establecer es sencillo y se puede orientar su uso en algún chat básico, muy básico.

Las reglas que manejé:

1. Al conectarse algún cliente, notificar su nombre de usuario al servidor.
2. El servidor debe de replicar el nombre de usuario a todos los clientes conectados.
3. Cuando algún cliente mande un mensaje, el servidor lo debe de replicar a todos los demás clientes y dejar claro quien lo esta enviando.
4. Cuando algún cliente se desconecte, el servidor debe de notificarlo a los demás clientes indicando quien se desconecto.

Una captura del programa/s donde se ejecutan estas acciones:

El código, para el servidor:

El código para el cliente:

Actividad #1 Laboratorio - Estándares

               USB 3.0           vs             Thunderbolt

 

  

Hace poco tiempo hubo una pequeña disputa por establecer cual estándar de estos dos posibles, reemplazaría al ya conocido USB 2.0. Este sustituto debería de reemplazar totalmente al anterior USB 2.0 en todos sus aspectos y debería de ser capaz de mejorarlos inclusive ofrecer nuevas opciones.

Cada uno defendía sus características (mas adelante las menciono), pero las mas importantes que tenían eran que los USB 3.0 físicamente son iguales a los USB 2.0 por lo que ofrecen retro-compatibilidad sin modificar nada (con la restricción de las limitaciones del USB 2.0) y los Thunderbolt físicamente son iguales a los puertos display-port, pero no ofrecen retro-compatibilidad con puertos que no esten preparados con esta nueva tecnología.

Características USB 3.0 (en cuanto a transferencias de datos)
Es la segunda revisión que se le hace a este periferico, diseñada en el 2008:

• En la primera versión(USB 1.0) las velocidades iban de 1.5Mbits/s hasta 12Mbits.
• En la segunda versión(USB 2.0) las velocidades se actualizaron e introdujeron un nuevo sistema llamado Hi-Speed que alcanzaba los 480Mbits/s.
• En la tercera versión se actulizaron otra vez las velocidades con nuevo sistema llamado Super-Speed y ahora alcanzan los 5Gbits/s.

Características Thunderbolt (transferencias de datos)
Fue lanzado en Febrero del 2011, principalmente en computadoras de Apple, ya que es más común el puerto display-port en estas computadoras.

Su velocidad de transmisión máxima es de 10Gbits/s, el doble del estandar USB 3.0 donde aparentemente le lleva ventaja.

Comparaciones y Conclusiones
El detalle está en sus velocidades de transmisión de datos, ya que los dos hacen prácticamente las mismas cosas.
Aparentemente en este apartado el Thunderbolt tendría la ventaja, pero debido a que su implementación generalmente solo es en computadoras Apple su mercado se reduce.

El USB 3.0 aún con menos velocidad de transferencia, su mercado puede ser más grande debido a que puede implementarse en cualquier computadora o dispositivo. Además del plus del poder contar la opción de seguir utilizando tus conexiones USB 2.0.

En un artículo que hace tiempo leí (no recuerdo su nombre ni donde fue) decía que el USB 3.0 originalmente no se llamaría así, si no que usaría otro nombre raro, pero que se declinó esta idea debido a que sería más factible para el usuario final relacionarlo con USB 2.0 y sus funcionalidades. Además de que lo verían como una actualización y no como un nuevo dispositivo.

En conclusión, actualmente el USB 3.0 sigue ganando terreno al Thunderbolt que yo personalmente solo lo he visto en computadoras Apple, la retro-compatibilidad con USB 2.0 ayuda mucho ya que no tenemos que deshacernos de nuestros dispositivos con este estándar en caso de hacernos de esta nueva tecnología o comprar nuevos dispositivos.
Yo creó que al final Thunderbolt es una buena opción pero desaparecerá.

Las empresas deberían de trabajar más en conjunto y no tanto individualmente como lo vienen haciendo para mejor este tipo de cosas. Se podría crear un apartado en la comisión que regula este tipo de cosas que cancele o anule la incursión de nuevos dispositivos/perifericos que se asemejen a alguno ya existente.

_________________________________________________________________________________

Referencias:

http://en.wikipedia.org/wiki/USB_3.0

http://en.wikipedia.org/wiki/Thunderbolt_(interface)

RFC 6127 - IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios

El RFC que elegí, habla de la coexistencia sin conflictos de los protocolos IPv4 e IPv6. Aquí dejo el link del documento que use como referencia: RFC 6127

Aparentemente esta cosa fue escrita con el fin de no batallar en un futuro (se creó en Octubre 2008) con el uso de los dos estandares (IPv4 e IPv6) par que estos pudieran trabajar conjuntamente sin fallas y que un futuro más lejano la versión IPv6 se quedara trabajando sola.

La idea es hacer que trabajen los dos en conjunto y que poco a poco la versión IPv6 valla desplazando a la IPv4 y que esto no sea un esto un gran problema......

Según el documento, cuando se diseño la IPv6 se hizo con el propósito de que soportara trabajar en redes y nodos donde se estuviera ejecutando IPv4, este método es conocido como "dual-stack [RFC 4213]" y es el mismo que se ha estado usando para desarrollar y proveer especificaciones y herramientas para este propósito hasta la actualidad.

Con el tiempo, se ha demostrado que la implementación del estándar IPv6 lleva tiempo y no esta siendo tan rápido como se pensaba, y si a esto se le agrega que el conjunto de direcciones IPv4 esta casi agotado, los ISP´s están ocupados buscando nuevos de diseños en sus redes que permitan la incursión de ambos estándares.

En el documento, se menciona que el método dual-stack es el mas usado para la interoperacion entre los dos estándares, pero no es el único ya que también se estan provando otros con el fin de facilitar todas estas actividades, relacionados con modelos multicapa para la traducción de direcciones IPv4 u otros asociados con la traducción de direcciones entre IPv4 e IPv6.

Según yo, estos métodos nuevo que se están probando pueden ayudar en mucho a la transición de IPv4 al IPv6, ya que permite la comunicación entre ambos y el desplazo poco a poco de la versión más antigua sin la necesidad de la desaparición total del IPv4, que no falta mucho para que suceda.

Se mencionan también algunos escenarios en donde se pueden aplicar lo que se busca con este documento:

• Crear una red de un tamaño muy grande que necesite muchas más direcciones de las que están disponibles en el espacio de direcciones privadas [RFC 1918].
• Crear una red donde se manejen únicamente direcciones IPv6 por facilidad de manejo en comparación de una donde se manejen los dos tipos de direcciones, pero que se siga necesitando acceso al Internet IPv4 para solamente un usuario.
• Tener acceso a un servidor con direcciones privadas IPv4 privadas por medio de direcciones IPv6.
• Accesar a servidores con direcciones IPv6 por medio de clientes IPv4.

En todos los casos se necesita la manipulación de los dos tipos de direcciones y su correcta convivencia, por lo que es necesario el surgimiento de métodos que permitan el manejo de estas situaciones al menos hasta que se desplace totalmente al IPv4.

En el aspecto de seguridad para estas situaciones destacan la importancia de la traducción de las direcciones de un estándar a otro y viceversa, ya que pueden impactar direcctamente con las NAT´s, DNS o Tunneling.

Por dar un ejemplo del impacto de esto en los servidores de DNS, una mala traducción de una dirección hacia el otro estándar podría hacer que al tratar de acceder a una página web la mala traducción de las direcciones enviara a otra página web al usuario.

Conclusión

En conclusión, la transición del mundo hacia el IPv6 continuará siendo lenta ya que cada vez se usan más y más dispositivos que ocupan una dirección ip y que al no estar totalmente establecido el IPv6 se recurre al uso del IPv4 y que posteriormente esta dirección necesitará reemplazo por una del IPv6. Todo esto hace ver que la implementación del IPv6 no esta siendo como se pensaba y que se requerirá de un mayor tiempo, además que se requiere el surgimiento de nuevos métodos para controlar y manipular la convivencia de los dos estándares en situaciones concretas.

A manera de sugerencia, se podría establecer una regla para que todas las nuevas estancias relacionadas con Internet se agreguen al nuevo estandar IPv6 forzosamente, esto con el fin de acelerar el proceso de transición.

_________________________________________________________________________________

Referencias:

Documento RFC 6127

http://datatracker.ietf.org/doc/rfc6127