Laboratorio - Ns2: Simulación de Trafico

Para esta semana, se nos encargo, simular trafico en Ns-2 y monitorear las medidas de desempeño, como lo son Jitter, Retraso, Latencia, etc.

Ya e realizado algunas simulaciones básicas sobre Ns-2, asi que seria bueno dar una visita rapida, para entender lo básico.

Generando Trafico 

La propiedad para generar trafico, fue usar Tmix.

El módulo TMix en ns-2 toma un conjunto de vectores de conexión y emula el comportamiento de toma de nivel de la aplicación de origen que ha creado la conexión correspondiente.

Esta emulación reproduce fielmente el patrón esencial de la toma de lecturas y escrituras que la solicitud original realizada sin conocimiento de lo que la aplicación original era en realidad.

Simulación 

Para esta practica, tome como ejemplo, la topología que realice en la entrada anterior, la cual la explique anteriormente y que es una simulación de una topología estrella, es algo basico.

Tomando como referencia un ejemplo que vi en Internet, la simulación toma los datos de los archivos "inbound.cv" y "outbound.cv", donde son los listados que se le dan al programa donde incluyen, tiempos, pesos de paquetes, etc, y son archivos muy pesados, así que para leerlos tuve algo de problemas.

Y el código de la topología es la siguiente:

Código Topología:

Medidas de desempeño:

Para la medición de desempeño de la topología, medí el Jitter, la Perdida de paquetes y el Retraso.

Son programas que fueron realizados en el lenguaje de programación Awk.

El código de las mediciones, son el siguientes:

Código Jitter

Código Loss Packing

Código Delay

Y los resultados son los siguientes:

Resultados: 

Para correr las mediciones, es de la siguiente manera:

$ awk - f "nombre_medicion".awk "archivo_salida".tr

*En la medicino de Jitter nos muestra lo siguiente:

El trafico que se usa es CBR, y se dan como resultados la fluctuación del trafico que se genera.

*En la medición de Perdida de paquetes nos muestra lo siguiente:

Nos muestran los paquetes enviados y los paquetes perdidos.

*En la medición del Delay nos muestra lo siguiente:


4.800000 -5.800000
4.800000 -5.800000
4.800000 -5.800000
4.800650 -5.800650
4.800738 -5.800738
4.800810 -5.800810
4.800810 -5.800810
4.800978 -5.800978
4.800978 -5.800978
4.801138 -5.801138
4.801138 -5.801138
4.801138 -5.801138
4.801618 -5.801618
4.801778 -5.801778
4.801778 -5.801778
4.804598 -5.804598
------------------------------

4.993678 -5.993678
4.993783 -5.993783
4.993838 -5.993838
4.993934 -5.993934
4.994079 -5.994079
4.994646 -5.994646
4.994938 -5.994938
4.995258 -5.995258
4.996398 -5.996398
4.996412 -5.996412
4.997576 -5.997576
4.998787 -5.998787
4.999934 -5.999934
4.999998 -5.999998
5.000000 -6.000000
5.000000 -6.000000
5.000000 -6.000000

Gráfica:

Nos da como resultado muchos números, pero hay un promedio de retardo de: 4.800000 a 6.000000

Y aquí un vídeo de la simulación, generando trafico

Vídeo:

Va algo rápido el vídeo, pero por lo largo de la simulación.

Referencias

• http://nsnam.isi.edu/nsnam/index.php/Manual:_Tmix:_Internet_Traffic_Generation
• http://cs.unc.edu/~lovewell/research/tutorial/tmix/index.html

Laboratorio - Ns2: Topologia y Ruteo

En esta ocasión, se realizo otra practica en Ns-2, pero con la idea de realizar una topología que sea usada en la vida real.

Anteriormente, realice una simulación de lo mas básico sobre Ns-2, por si quieren regresar a ver como se realizo y así tener una mejor idea.

Simulación

La siguiente topología, la realice tomando en cuenta la topología "estrella", usada usualmente en redes de computadoras y que utilice como guía varios ejemplos para realizar esta practica.

La topología funciona de la siguiente manera:

Para la simulacionutilice el método de ruteo "Distance Vector", que es usado por los protocolos de ruteo RIP y también EIGRP

Tenemos una topología estrella, y es muy simple, 7 nodos, los cuales están conectados hacia un nodo central, que es el nodo del numero 2.

Los nodos están conectados y envían lo siguiente:

El nodo 0 esta conectado al nodo central 2 y envía información al nodo 4, envía 1Mb a 10 ms.

El nodo 5 esta conectado al nodo central y este envía información al nodo 6, envía 1Mb a 10 ms.

El nodo 1 esta conectado al nodo central y este envía información al nodo 3, envía 1Mb a 10ms.

Ahora el código es el siguiente:

Código:

Compilamos y tenemos como resultado lo siguiente:

Damos iniciar, y tenemos la simulación funcionando.

Y aquí un viseo de la demostración.

Vídeo:

En el vídeo se muestra cuando se inicia la simulación, donde pasan los datos de nodo a nodo, y el tiempo que tardan.

Laboratorio - Simulación ns-2/ns-3

Para esta entrada, se encargo diseñar, ejecutar y reportar una simulación con NS-2/NS-3, pero primero, una introducción a NS.

NS es un simulador de redes basado en eventos discretos, se usa principalmente en ambientes educativos y de investigación. 

Permite simular tanto protocolos unicast como multicast y se utiliza intensamente en la investigación de redes móviles ad-hoc.

Implementa una amplia gama de protocolos tanto de redes cableadas como de redes inalámbricas.

Simulación

Para la simulación, utilice un ejemplo que encontré en la pagina NS by Example, el cual es el siguiente:

El ejemplo 3, es una secuencia de comandos OTcl que crea una configuración de red simple y corre el escenario de simulación en la Figura siguiente.

Figura: Una topología de red simple

La red consta de 4 nodos (n0, n1, n2, n3) como se muestra en la figura anterior.
Los vínculos entre las dos caras n0 y n2, y n1 y n2 con 2 Mbps de ancho de banda y 10 ms de retraso.

La conexión dúplex entre N2 y N3 tiene 1,7 Mbps de ancho de banda y 20 ms de retraso.
Cada nodo utiliza una cola DropTail, el tamaño máximo es 10.

Un agent "tcp"está unido a n0, y establece una conexión TCP a un "sumidero" agente unido a n3.

Por defecto, el tamaño máximo de un paquete que un "tcp" puede generar 1 Kbyte.
A tcp "sumidero" agente genera y envía paquetes ACK al remitente (tcp agente) y libera a los paquetes recibidos.
Un "UDP" agente que se une a n1 está conectado a un "nulo" agente unido a n3.

A "null" agente sólo libera los paquetes recibidos.

A "ftp" y generador de tráfico"cbr" se unen a "tcp" y "udp" agentes respectivamente, y el "cbr" está configurado para generar un KByte a la velocidad de 1 Mbps.

El "cbr" está configurado para iniciarse en 0,1 segundos y dejar en 4,5 segundos, y "ftp" está configurado para iniciarse en 1,0 segundos y dejar en 4,0 seg.


Ahora, el código es el siguiente:

Código:



Ahora, para compilar el programa, tenemos lo siguiente:

ns simu.tcl

Compilamos, y se genera la ventana y podremos ver la simulación, tenemos lo siguiente:

Damos click a play, y veremos la simulación.

Aquí un vídeo de la demostración.

Vídeo de simulación

En el vídeo se muestra cuando se inicia la simulación, donde pasan los datos de nodo a nodo, y el tiempo que tardan.

Referencias:

• http://es.wikipedia.org/wiki/Ns_(simulador)
• http://www.nsnam.org/
• http://www.isi.edu/nsnam/ns/
• http://www.isi.edu/nsnam/nam/index.html
• http://nile.wpi.edu/NS/

Puntos extras - NS-2

Tema: Traffic Pattern Based Performance Comparison of Two Reactive Routing Protocols for Ad Hoc Networks Using NS2

Investigación echa por Suresh Kumar, R K Rathy y Diwakar Pandey.

Introducción

Ad-hoc es una colección de nodos inalambricos móviles formando una red temporal sin cable con infraestructura wire-line.

La comunicación entre los nodos se basa en radio a radio multi-hoping.

Ad-hoc son redes caracterizado por el cambio de topología frecuente debido a la movilidad de nodos. Los nodos pueden unirse y abandonar la red en cualquier momento.

Los sistemas inalambricos de la red han ganado importancia en los últimos años años mediante la combinación de la potencia de un gran número de ordenadores situados en lugares diferentes.

Todos los nodos de dichas redes se comportan como routers y tomar parte en el descubrimiento y mantenimiento de rutas a los otros nodos en la red.

De modo que el algoritmo de enrutamiento debe ser dinámico y debe ser adaptable a los cambios en la topología frecuentes debido a la movilidad del nodo.

Muchos algoritmos fueron propuestos en el documento que se puede utilizar en redes ad-hoc para la búsqueda de rutas.


En este artículo presentamos comparación de rendimiento de dos protocolos: protocolo DSR, protocolo de enrutamiento y el protocolo AODV, para llevar a cabo sus méritos relativos.

Ambos están en los protocolos de gran demanda y e inician sus actividades de enrutamiento sólo cuando sea necesario.

La motivación de esta comparación es entender su mecanismo interno de trabajo y poner de manifiesto las situaciones en que uno es preferible de usar que el otro.




Configuración de simulación 

Para la simulación se utilizo NS-2 y se cuento con el apoyo para la simulación de múltiples redes inalámbricas.

El protocolo mantenía un buffer de envío de paquetes de 64, contenía todos los paquetes de datos en espera de una ruta, tales como paquetes de descubrimiento de ruta.

Todos los paquetes de datos enviados por la capa de enrutamiento se ponen en cola en la cola de la interfaz hasta que la capa MAC puede transmitir.

La cola de la interfaz tenia un tamaño máximo de 50 paquetes y se mantiene como una cola de prioridad con dos prioridades en orden FIFO.

Los paquetes de enrutamiento obtienen mayor prioridad que los paquetes de datos.

Se generaron 50 escenarios (5 para cada tiempo de pausa) y cuatro patrones de tráfico con diferente número de fuentes para cada tipo de tráfico (CBR y TCP).

La simulación se ejecuto utilizando los anteriores escenarios y los patrones de tráfico para ambos protocolos.

Para superar el efecto de la aleatoriedad en la salida hemos tomado las medias de los resultados a obtener sus valores reales.

El objetivo de la simulación era evaluar las diferencias en el rendimiento de estos dos protocolos reactivos de encaminamiento.

Las simulaciones se llevaron a cabo variando el número de fuentes de tráfico como 10 y 40.

El tiempo de pausa era variado de 0 sec (alta movilidad) a 900 sec (sin movilidad) en un intervalo de 100 sec.

Los resultados de la simulación mostraron algunas diferencias importantes entre las características de los protocolos de enrutamiento.

La presencia de una gran movilidad implico frecuentes fallos de enlaces y cada protocolo de enrutamiento reacciona de manera diferente durante los fallos de enlace.

Los diferentes mecanismos básicos de trabajo interno llevaron a las diferencias de rendimiento en los protocolos.


Conclusión


La observación general de la simulación es que, por aplicación métricas orientadas tales como la fracción de entrega de paquetes y el retardo, AODV supera DSR en situaciones de estrés (carga alta y / o de alta movilidad), con aumento de las diferencias de rendimiento con el estrés en aumento (más carga y, de alta movilidad).

En resumen, se puede decir que para un escenario robusto la movilidad es alta, el área es grande, la cantidad de tráfico de red es más y es para un período más largo, AODV funciona mejor.

En las situaciones normales en las que una red es de carácter general, con tráfico moderado y movilidad moderada, el protocolo DSR sería la elección correcta para las aplicaciones UDP, ya que ofrece más paquetes en el destino con más bajos los gastos generales de enrutamiento.

Para las aplicaciones TCP AODV se encuentra para ser una mejor opción, además se encontró que para los resultados son comparables con los obtenidos por DSR para el tráfico CBR.

Los resultados dan vista mucho más cerca del rendimiento de los protocolos para la fracción de entrega de paquetes, el retardo promedio, y las métricas de pérdida de paquetes que por ellos.



Referencia

• http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5234702

Reporte - Experimento de QoS

En este reporte, hice un experimento de QoS (Calidad de Servicio) donde mi utilizare mi Red para monitorear la calidad.

Para lo siguiente, utilice la herramienta de Wireshark: 

(En la entrada anterior trabaje con la herramienta y mencione algunas cosas fundamentales para utilizarlo y esta es la entrada: Reporte - sniffer: monitorear contenido)

Primero, que es QoS? 

QoS o Calidad de Servicio, son las tecnologías que garantizan la transmisión de cierta cantidad de información en un tiempo dado. 

Es especialmente importante para ciertas aplicaciones tales como la transmisión de vídeo o voz.

Ahora, la aplicación para realizar el experimento de QoS sera DailyMotion

Nota*: Mi red fue el medio de conexión para realizar el reporte.

Experimento de QoS.

Primero que nada, para este análisis utilice Dailymotion para capturar los paquetes perdidos (Packet loss), retardo en las entregas (Delay) y el ancho de banda (Band width).

Verificando paquetes perdidos:

Entramos al programa y primero que nada, usamos el filtro TCP (En este caso, para recibir paquetes de Daily Motion), debemos de tener lo siguiente: 

Después, nos aparece todos los paquetes recibidos al momento de ver un vídeo en Dailymotion, también nos aparece cuando se hace la conexión a la pagina, etc, muestra lo siguiente:

Ahora, para saber cuantos paquetes perdidos (Packet loss), checamos el IO Graph y aplicamos los filtros (tcp.analysis.lost_segment y tcp.analysis.duplicate_ack) nos muestra una pequeña linea de los paquetes perdidos y los paquetes duplicados, se muestra lo siguiente:

Como interpretamos esto?

La linea rosa, nos muestra una gran cantidad de paquetes duplicados y eso significa que hubo varios paquetes perdidos como lo muestra la linea roja, se muestra en un tiempo de 8 segundos.

Verificando el retardo de entrega de paquetes (Delay)

Ahora, para mostrar el tiempo que tardan el flujo de paquetes, para esto, debemos de seleccionar Time-Secuence Graph (tcptrace) , y nos aparecen dos ventanas, como las siguientes:

Nos vamos a la opción Cross y lo aplicamos, ahora, podremos dar click a los paquetes que se capturaron y nos muestra el tiempo cuando fue capturado, tenemos lo siguiente:

Con los círculos (color rojo) se muestra el paquete seleccionado, se da click sobre el punto de la gráfica y nos enseña que paquete se selecciono y abajo nos muestra en que segundo se capturo.

En la siguiente imagen se muestra que un paquete después de casi 6 segundos se capturo el siguiente paquete:

Verificamos que hubo un cierto retraso al momento de capturar los paquetes.

Verificando el Ancho de Banda (Band width)

Para mostrar el ancho de banda, nos vamos a la opción de Follow Graph y veremos lo siguiente:

Como se interpreta esto?

Se muestra el paquete y el flag ACK, muestra el total de Bytes y muestra el ancho de banda, que es el siguiente:

En el circulo amarillo nos muestra el ancho de banda y que es el numero 1024, es una estimación ya que no son datos exactos que proporciona Wireshark.

Conclusiones:

No existe (Bueno, al menos no encontré) una herramienta formal para tener un resultado exacto sobre QoS y para esto, tuve que interpretar los datos que nos muestra Wireshark y así mostrar gráficas y resultados cuando se realizo el experimento en la red.

Calidad de Servicio 

 Hubo algunas perdidas de paquetes en el transcurso que se abrió la pagina, se visualizo el vídeo y se cerro la pagina.

En  el retardo de entrega de paquetes hubo problemas en ese aspecto, hubo algo de tiempo prolongado  al capturar los paquetes.

Y en el ancho de banda, el dato no es tan exacto, así que el resultado es normal.

Referencias:

• http://en.wikipedia.org/wiki/Quality_of_service

Laboratorio - Medidas de QoS

En esta entrada explicare algunas medidas de Calidad de Servicio que utilice para mi entrada sobre el QoS.

(Enlace de mi entrada sobre experimento de QoS: Reporte - experimento QoS).

Ancho de banda (bandwidth)

El ancho de banda es la medida de datos y recursos de comunicación disponible o consumida expresados en bit/s o múltiplos de él (ciento setenta y dos, Mbit/s, entre otros).


El uso de herramientas, como Wireshark, son útiles para el calculo del ancho de banda, no proporcionan datos extremadamente certeros, solo sirven como comprobación y comparación con las mediciones realizadas.

Una idea para calcular el ancho de banda, puede ser de la siguiente manera:

Transferimos un archivo de tamaño conocido, mediante el sniffer (Wireshark) y calculamos el tiempo en que tarda en transferirse completamente y haciendo la siguiente cuenta obtenemos el ancho de banda de la siguiente manera:

W (Bps) = carga útil (Bytes) / tiempo de transmisión (seg)


Retardo (delay)

Puede ocurrir que los paquetes tomen un largo período en alcanzar su destino, debido a que pueden permanecer en largas colas o tomen una ruta menos directa para prevenir la congestión de la red. En algunos casos, los retardos excesivos pueden inutilizar aplicaciones tales como VoIP o juegos en línea

Como se verifica en Wireshark?

Dentro del menú Statistics > TCP Stream Graphs, nos encontramos con un tipo de gráficas basado en el número de secuencia respecto al tiempo.

Este tipo de gráfica es el Time-Secuence Graph (tcptrace).

Una vez seleccionado un segmento cualquiera de la conexión TCP que nos interese de la lista de paquetes, llamamos a las gráficas de TCP para mostrar los resultados deseados.



Pérdida de paquetes (packet loss)

Paquetes sueltos

Los rute-adores pueden fallar en liberar algunos paquetes si ellos llegan cuando los buffers ya están llenos. Algunos, ninguno o todos los paquetes pueden quedar sueltos dependiendo del estado de la red, y es imposible determinar que pasará de antemano. La aplicación del receptor puede preguntar por la información que será retransmitida posiblemente causando largos retardos a lo largo de la transmisión.

Entrega de paquetes fuera de orden

Cuando un conjunto de paquetes relacionados entre sí son encaminados a Internet, los paquetes pueden tomar diferentes rutas, resultando en diferentes retardos. Esto ocasiona que los paquetes lleguen en diferente orden de como fueron enviados.

Este problema requiere un protocolo que pueda arreglar los paquetes fuera de orden a un estado isócrono una vez que ellos lleguen a su destino.

Esto es especialmente importante para flujos de datos de vídeo y VoIP donde la calidad es dramáticamente afectada tanto por latencia y pérdida de sincronía.

Errores

A veces, los paquetes son mal dirigidos, combinados entre sí o corrompidos cuando se encaminan. El receptor tiene que detectarlos y justo cuando el paquete es liberado, pregunta al transmisor para repetirlo así mismo.

Como se verifica en Wireshark?

Partiendo de una captura cualquiera y llamando a IO Graph mediante Statistics > IO Graphs, se puede aplicar una serie de filtros y que nos muestre lo siguiente:

Los filtros que se pueden utilizar para verificar lo anterior, son los siguientes:

• tcp.analysis.lost_segment: Filtro para perdida de paquetes o segmentos.
• tcp.analysis.retransmission: Mecanismo de rentransmision.
• tcp.analysis.fast.retransmission: Mecanismo de rentransmision rápida.
• tcp.analysis.duplicate_ack: Análisis de ACKs duplicados.

Para interpretar los datos dados por la grafica es facil, podemos decir que:

Si se reciben tres o más ACKs duplicados, se asume la pérdida de un segmento o paquete lost_segment esto desencadenala retransmisión de dicho segmento perdido fast.retransmission.



Referencias:

• http://en.wikipedia.org/wiki/Quality_of_service
• http://www.daboweb.com/2011/01/27/herramientas-para-la-interpretacion-de-capturas-de-red-710/

Laboratorio - Cobertura de redes

Para esta semana se encargo realizar un mapa sobre las coberturas de red Wifi que estuvieran a nuestro alcance en un espacio publico, y demostrarlo con ayuda de Google Maps

*Nota: Trabaje en Windows y con el programa WirelessMon

Primero que nada, primero con la ayuda del programa antes mencionado, detecte las señales de los routers que estaban cerca del área, después detecte la fuerza de señal de las redes Wifi detectadas.

Lo que detecto el programa fue lo siguiente:

*Nota:
El programa detecta como color azul en donde estoy conectado a la red, de color verde los disponibles, y los de color rojo no disponibles, pero aun así detectaba la fuerza de señal que emiten.


Aquí una imagen donde mostraba la fuerza de red donde estaba conectado:

Ahora, lo que sigue es mostrar la fuerza de señal con ayuda de Google Maps, donde mostrare con colores la fuerza de señal.

Quedo de la siguiente manera:

Colores:

El color azul, es la red que estaba conectado y donde la fuerza era mayor, los colores como el naranja o negro eran las mas cercas.

Los otros colores muestran las demás redes que estaba cercas, lógico, la señal era mas débil.