martes, 26 de febrero de 2013

Puntos extras: Simulaciones rendimiento utilizando TCP Ns2

En este estudio especial de dos modelos analíticos de rendimiento TCP (Tahoe, Reno) se comparan con resultados simulados. El objetivo de este ejercicio es simular el control de congestión TCP y el rendimiento. Además, el objetivo es dar una idea de cómo los modelos de análisis puede ser verificado con simulaciones.

Visión general de control de congestión del TCP
TCP implementa una ventana basada en mecanismo de control de flujo, un protocolo de ventana basado significa que el tamaño de la denominada ventana actual define un estricto límite superior en la cantidad de datos no reconocidos que pueden estar en tránsito entre un par receptor-emisor dado.

Al establecer la conexión TCP, el receptor propone un tamaño de ventana en función de su buffer.
En Internet se acepta la existencia de dos problemas:
  • „ Capacidad del receptor.
  • „ Capacidad de la red.
Estos problemas se tratan por separado. Dos ventanas en emisor y receptor (la ventana que ha propuesto el receptor y la ventana de congestionamiento)
El emisor usará el valor mínimo de las dos ventanas.


Modelado de rendimiento de TCP
Los métodos tradicionales para examinar el rendimiento de TCP han sido la simulación, las implementaciones y las mediciones de este. Sin embargo, los esfuerzos también se han hecho para analíticamente caracterizar el rendimiento del TCP como una función de parámetros tales como la tasa de caidas de paquetes y tiempo de ida y vuelta.
Los modelos de medicion son estos
  • modelo sencillo [F99]
(1)

  • modelo complejo [PFTK98] 
(2)

Seguimiento y monitoreo
Con el fin de ser capaces de calcular los resultados de las simulaciones, los datos tienen que ser recogidos de algún modo. Ns2 admite dos funciones de supervisión primaria: seguimiento y monitoreo. Las huellas permiten grabación de paquetes cada vez que un evento tal como caída de paquetes o de llegada se produce en una cola o un enlace.
Los monitoreos proporcionan un medio para cantidades de recogida, tal como el número de paquetes caidos o el número de paquetes en la cola. El monitor puede ser utilizado para recoger estas cantidades para todos los paquetes o
sólo por un flujo especificado (un monitor de flujo).

Simulación de estudio
- Descripción del problema
El propósito de este estudio es comprobar las fórmulas (1) y (2) para el estado de equilibrio de rendimiento TCP con un entorno de simulación adecuado. En [PFTK98] fórmula (2) se ha verificado empíricamente mediante el análisis de los datos de medición recogidos de 37 conexiones TCP. Las siguientes cantidades se han calculado a partir de los restos de medida:
  • Número de paquetes enviados
  • El número de indicaciones de pérdida (o el triple de tiempo de espera de ACK duplicado) 
  • El tiempo promedio de ida y vuelta
  • La duración media de un tiempo de espera.
El valor aproximado de la pérdida de paquetes se ha determinado dividiendo el número total de las indicaciones de pérdida por la cantidad total de paquetes enviados.

Rendimiento de TCP se exploró con los siguientes escenarios:

1. Dos conexiones TCP competencia: un emisor y un remitente UDP que compartir el enlace cuello de botella. La pérdida de paquetes experimentada por el emisor de TCP se modifica mediante el cambio de la tasa de envío del flujo UDP. Aplicación se utiliza FTP sobre TCP y el tráfico CBR sobre UDP (es decir, el tráfico NTECEDENTES es determinista).

2. Dos conexiones competidoras como anteriormente, pero ahora los tiempos entre el remitente de UDP se distribuye exponencialmente. La pérdida de paquetes se modifica cambiando el tiempo promedio entre llegadas de los paquetes UDP.

3. Una población homogénea TCP: La pérdida de paquetes es modificada por el aumento del número de fuentes TCP. Dado que las fuentes TCP tienen tamaños mismas ventanas y mismo es RTT, el rendimiento de un emisor TCP debe ser igual al caudal del agregado dividido por el
número de fuentes TCP.

Los resultados numéricos
Después de cada simulación, el rendimiento real promedio del flujo TCP (basado en los datos de simulación), así como el rendimiento de acuerdo con (1) y (2) se calcula. Por último, los resultados de diferentes simulaciones se representan gráficamente como una función de la pérdida de paquetes de modo que cada gráfico muestra los resultados para un
escenario de simulación particular. Un punto en cada gráfico representa una simulación de 250 segundos. Los puntos sólo se diferencian en la tasa de envío del flujo UDP o en el número de flujos TCP en caso de una población homogénea TCP. Todos los gráficos se representan usando la misma escala para que sea más fácil de comparar los resultados de diferentes escenarios.

Resultados



Promedio
Desviación estándar
Paquete de velocidad baja
0,0101
0,0002
Rendimiento
1,8865
0,0120
Formula (1)
2,1482
0,0237
Formula (2)
2,0847
0,0246

Rendimiento TCP escenario 1

Rendimiento Reno TCP escenario 1




Promedio
Desviación estándar
Paquete de velocidad baja
0,0970
0,0028
Rendimiento
0,3480
0,0065
Formula (1)
0,6092
0,0098
Formula (2)
0,3498
0,0159

Rendimiento TCP en escenario 2

Rendimiento Reno TCP escenario 2




Promedio
Desviación estándar
Paquete de velocidad baja
0,0153
0,0001
Rendimiento
1,3132
0,0036
Formula (1)
1,7011
0,0043
Formula (2)
1,6238
0,0046

Rendimiento TCP escenario 3
Rendimiento Reno TCP escenario 3

Referencias:
http://www.netlab.tkk.fi/tutkimus/cost279/publ/private/Antila2002.pdf

Laboratorio 4: Qos (quality of services)

Problemas regulares
Muchas cosas le ocurren a los paquetes desde su origen al destino, resultando los siguientes problemas vistos desde el punto de vista del transmisor y receptor:

Paquetes sueltos


Los ruteadores 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.

Bitrate

El Bitrate es el número de bits (o datos) que son procesados por unidad de tiempo.
La tasa promedio de bits (bitrate) para un archivos MP3 file es de 128 kbits por segundo o kbps. Un archivo creado con este bitrate deberá tener una buena calidad y por lo general should have good quality and retoma aproximadamente 1 Megabytes de datos por minuto de audio.
Los diferentes bitrates varían la calidad del sonido. Cuanto más alto sea el bitrate, más veces va a ser sampleado el sonido original, de esta manera obteniendo una reproducción mas auténtica y un sonido mucho mejor.

Jitter
Los paquetes del transmisor pueden llegar a su destino con diferentes retardos. Un retardo de un paquete varía impredeciblemente con su posición en las colas de los ruteadores a lo largo del camino entre el transmisor y el destino. Esta variación en retardo se conoce como jitter y puede afectar seriamente la calidad del flujo de audio y/o vídeo.

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.

Retardos

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. Lo que comunmente se le llama LAG

domingo, 24 de febrero de 2013

Clase: Qos (Quality of service): Skype - Infinitum


QoS o Calidad de Servicio (Quality of Service, en inglés) son las tecnologías que garantizan la transmisión de cierta cantidad de información en un tiempo dado (throughput). Calidad de servicio es la capacidad de dar un buen servicio. Es especialmente importante para ciertas aplicaciones tales como la transmisión de vídeo o voz.

Que hay que hacer?

Consiste en hacer un análisis de la calidad de las llamadas entre usuarios, cabe destacar aquí que se trabajo con mi compañero Jonathan desde otra computadora remota.

Para la realizacion de esta tarea usamos.
  • Wireshark
  • Skype
  • Una conexión a infinitum (para el caso de mi compañero usó intercable)
Calidad de servicio
Los factores que se analizaron son los siguientes.
  • Jitter
  • Perdida de paquetes
  • Bit-rate
  • Retardos
Aquí los resultados 
Para capturar los paquetes se utilizo wireshark y como en el proceso se capturaron cosas de las cuales no quería analizar, se aplico un filtro para solo mostrar los paquetes que se enviaron por udp.


Para analizar el jitter wireshark nos da la facilidad de darnos una grafica en donde se muestran los tiempos de las transmisiones.

Como se aprecia en la imagen estan los tiempos, los paquetes que se enviaron y los puertos que trabajaron en esto
Para hacer esto nos vamos al menú Statistics y le damos click a flow graph

Para mostrar esto un poco mejor, tambien el wireshark nos da la facilidad de graficarlo.

La linea negra nos muestra el tamaño de los paquetes con sus respectivos tiempos de llegada.
La linea roja nos muestra el tamaño de los paquetes con sus tiempos

Como se puede apreciar en la imagen hay poca perdida de paquetes se podría decir que nula.

Aquí la gráfica medida en bytes:


Ahora para analizar la perdida de paquetes, skype utiliza el protocolo UDP cuando hay una perdida de los paquetes o paquetes que no son enviados, como este sistema se basa en voz esto no afecta ya que es muy predictiva y por lo tanto no se notaria cuando haya una perdida.

Ahora vemos este resultado en wireshark:

Como se puede ver el .3% de error es lo que tiene en perdida de paquetes.

Ahora para analizar el Bit-rate, nuevamente wireshark nos ayuda con esto.
Aquí el resultado.


En esta imagen podemos observar que este apartado, Avg Mbit/Sec nos muestra como 0.253 es una velocidad decente a mi parecer ya que 32 kbit/s es la calidad para videoteléfono (mínima calidad necesaria).

Ahora para analizar un poco el retardo, muestro la siguiente imagen



En esta imagen podemos apreciar los distintos tiempos de los paquetes y si es que hubo retardos, como se nota todos los paquetes se entregaron bien.


Conclusiones:
Los resultados nos indican que el skype trabajo bien en la red infinitum:
  • jitter bajo
  • pérdidas casi nulas.
  • retardos casi nulos

jueves, 21 de febrero de 2013

Homework 2

To this entry undertook analyze algorithms "String matching" seen in class, these are the algorimo Boyer-Moore and Knuth-Morris-Pratt.

Boyer-Moore
The Boyer-Moore algorithm searches for occurrences of P in T by performing explicit character comparisons at different alignments. Instead of a brute-force search of all alignments (of which there are m - n + 1), Boyer-Moore uses information gained by preprocessing P to skip as many alignments as possible.

The algorithm begins at alignment k = n, so the start of P is aligned with the start of T. Characters in P and T are then compared starting at index n in P and k in T, moving downward: the strings are matched from the end and toward the beginning of P. The comparisons continue until either a mismatch occurs or the beginning of P is reached (which means there is a match), after which the alignment is shifted to the right according to the maximum value permitted by a number of rules. The comparisons are performed again at the new alignment, and the process repeats until the alignment is shifted past the end of T.

The shift rules are implemented as constant-time table lookups, using tables generated during the preprocessing of P.


Knuth-Morris-Pratt.

A string matching algorithm wants to find the starting index m in string S[] that matches the search word W[].

A straightforward algorithm simply tries successive values of m until it finds a match or fails. Each trial involves using a loop that checks S[m+i] = W[i] for each character W[i] in the search word.

Usually, the trial check will quickly reject the trial match. If the strings are uniformly distributed random letters, then the chance that characters match is 1 in 26. In most cases, the trial check will reject the match at the initial letter. The chance that the first two letters will match is 1 in 26^2 (1 in 676). So if the characters are random, then the expected complexity of searching string S[] of length k is on the order of k comparisons or O(k). The expected performance is very good. If S[] is 1 billion characters and W[] is 1000 characters, then the string search should complete after about 1 billion character comparisons (which might take a few seconds).


here the code:

here a image of the result of the code
makes 44 comparasions, and just take a few time

Now the code of the bruteforce

I have an error but this algorithm is more fast that Boyer

Bibliografias:
http://cs.indstate.edu/~kmandumula/presentation.pdf
http://www-igm.univ-mlv.fr/~lecroq/string/node14.html

martes, 19 de febrero de 2013

Laboratorio 3: Redes wifi

Para esta entrada, se pidió medir la intensidad de diferentes redes wifi de cierto lugar y dibujarlas en google maps.

Antes de empezar intentare explicar como se miden las intensidades de las redes wifi.

El dBm es una unidad de medida utilizada, principalmente, en telecomunicación para expresar la potencia absoluta mediante una relación logarítmica.
El dBm se define como el nivel de potencia en decibelios en relación a un nivel de referencia de 1 mW.

dBm
Potencia
Ejemplos
80 dBm
100 kW
Potencia típica de transmisión de una estación de radio FM
60 dBm
1 kW = 1.000 W
Radiación típica de un horno microondas
40 dBm
10 W
Potencia enviada a las antenas de telefonía móvil
33 dBm
2 W
Máxima salida de potencia para un teléfono móvil
30 dBm
1 W = 1.000 mW
Fuga de RF típica de un horno microondas
20 dBm
100 mW
Bluetooth Estándar Clase 1, con un alcance de 100 m.Potencia típica de un punto de acceso inalámbrico “WiFi”
15 dBm
32 mW
Potencia típica de de transmisión del WiFi de los portátiles
4 dBm
2,5 mW
Bluetooth Estándar clase 2, con un alcance de 10 m
0 dBm
1 mW = 1.000 µW
Bluetooth Estándar clase 3, con un alcance de 1 m.
-10 dBm
100 µW
Potencia de señal típica de recepción de una red inalámbrica WiFi(de −10 a −30 dBm)
-30 dBm
1 µW = 1.000 nW

-60 dBm
1 nW = 1.000 pW

-70 dBm
100 pW
Potencia de señal típica de recepción de una red inalámbrica 802.11x ( de −60 a −80 dBm)

El lugar que se utilizo fue mi casa y las redes que se encontraron fueron las siguientes:


El comando para encontrar estas redes fue iwlist donde como pueden apreciar en las imágenes anteriores nos muestra todo de las redes, el comando en concreto fue:
iwlist scan eth1

el eth1 depende de la red en que quieras escanear

Ahora para encontrar las redes que están por la casa, utilice una manera muy rustica que fue ir caminando con mi celular y donde la señal se volviera mas fuerte esa era la casa, con excepción de ciertas redes que se donde están.
Aquí la imagen de las redes encontradas:
 

El circulo amarillo es la red a la que estaba conectado y por ende mi casa, ya por lógica se sacan las demás redes.

Aquí el código la cual pinto los círculos:

Bibliografias:
http://www.wificlub.org/tag/potencia/

Tarea 2: Deteccion de figuras

Para la entrada de esta semana lo que se realizo fue lo siguiente:
  • Una rutina en este caso bfs la cual nos ayuda a darle color a las figuras.
  • El componente más grande debe ser el fondo, y colorearse gris.
  • A los demás dibujos se les asignan otros colores. 
Se realizo la rutina BFS donde encontramos las distintas figuras que componen la imagen, esto lo hace recorriendo los pixeles de toda la imagen, el algoritmo parte de un nodo raiz y luego se van recorriendo los nodos vecinos, introduciendo en una cola. También lleva el conteo de todos los pixeles de la figura detectada para calcular el porcentaje de la forma con respecto al total de pixeles de la imagen.
La imagen con la que se trabajo fue la siguiente:


A esta figura le aplicamos el procesamiento que se le a hecho a las demás imágenes en las tareas anteriores.

Aquí imagen con bordes encontrados


Ahora la binarizamos para juntar los bordes que se encuentren despegados

Ahora pintamos la imagen con la rutina bfs para colorear y le sacamos los porcentajes que ocupan en ese lugar.






Aqui el codigo:

Tarea 3: Monitoreo WiFi

Para la entrada de esta semana, se nos encargo realizar experimentos en la red WiFi y sus dispositivos conectados, en este caso usando sniffing, la finalidad de este experimento es ver cuantos bytes usa un usuario de cierta computadora visitando paginas.

Bien primero para empezar, que es sniffing?
Se trata de una técnica por la cual se puede "escuchar" todo lo que circula por una red. Esto quiere decir que se puede ver todo lo que hace una persona que esta usando su computadora
Esto se hace mediante aplicaciones que actúan sobre todos los sistemas que componen el tráfico de una red, así como la interactuación con otros usuarios y ordenadores. Capturan, interpretan y almacenan los paquetes de datos que viajan por la red, para su posterior análisis (contraseñas, mensajes de correo electrónico, datos bancarios, etc).

Ahora empezaremos a instalar un programa que nos ayudara a "sniffear" a alguien en este caso no queremos sacar contraseñas u otra cosa, como solo queremos observar la cantidad de ancho de banda que gasta sera algo sencillo.

Instalaremos ettercap en nuestras computadoras, hay diferentes sniffers para ubuntu pero usaremos el antes mencionado.

Para instalarlo es algo sencillo y la forma que mencionare se me hace la mas recomendable ya que este programa necesita de muchas librerías.
  • Abrimos synaptic package manager de ubuntu
  • Buscamos ettercap y lo marcamos graphical o text only como ustedes gusten (esto hara que por si solo se marquen las librerias que necesitamos)
  • Y despues le damos aplicar.
Como se puede apreciar en la imagen instalamos el modo gráfico pero también mostrare como se ve en solo texto.

 La otra forma es librería por librería que no lo recomiendo de esa forma pero aquí les dejo la lista de librerías que necesitan:
  • sudo apt-get install build-essential
  • sudo apt-get install linux-headers-`uname -r`
  • sudo apt-get install libpcre3-dev
  • sudo apt-get install libpcap0.8-dev
  • sudo apt-get install libnet1-dev
  • sudo apt-get install openssl
  • sudo apt-get install libssl-dev
  • sudo apt-get install ncurses-bin
  • sudo apt-get install libncurses5-dev
  • sudo apt-get install libnet6-1.3-dev
  • sudo apt-get install libpthread-stubs0-dev
  • sudo apt-get install zlib1g-dev
  • sudo apt-get install libltdl-dev
  • sudo apt-get install pango-graphite
  • sudo apt-get install pkg-config
  • sudo apt-get install libpango1.0-dev
  • sudo apt-get install libatk1.0-dev
  • sudo apt-get install libgtk2.0-dev
  • sudo apt-get install autoconf
  • sudo apt-get install byacc

Bien ahora a observar como se ve este programa y como funciona.

Antes de hacerlo correr prmero tenemos que editar el conf de ettercap en la siguiente imagen se muestra en que linea y que se quita.
solo quitamos el signo de numero # de esa linea

Para hacerlo correr pueden:
Buscarlo en su aplicaciones y darle click o manualmente en terminal tecleando esto corriendolo como super usuario
ettercap -G



Como pueden ver aquí lo corrimos en la terminal como super usuario ya que no nos hará nada si no lo corremos así y ahora podemos realizar el sniffing.

Ahora nos vamos a la pestaña que dice sniff  y le damos click a unified sniffing en donde nos aparecerá lo siguiente.





y en mi caso escogemos eth1 para empezar a sniffear en esa red.

Al realizar esto el programa toma nuestra ip y nos da lo necesario para que nuestra maquina sea el sniffer

Ahora como se podra notar las pestañas han cambiado, le daremos click en la pestaña de hosts y a scan hosts

Nos emepzara a escanear la zona donde este alguien conectado al router y nos mostrara cuantos encontro


En esta ocasión nos encontró 4 ip's como se muestra en la imagen siguiente
 
 Para observar las ip encontradas nos vamos a host -> host list

Ahora como se puede apreciar en la imagen anterior tenemos 3 botones bien primero seleccionaremos el target 1 que sera la computadora a la que estaremos sniffeando y el target 2 sera nuestro router.

En resumen , enviaremos paquetes ARP para engañar el switch y lograr que los paquetes del TARGET 1 pasen por nuestra máquina. Una vez capturado su contenido los reenviamos al router (TARGET 2) para que lleguen a su destino.

Como podemos ver escogimos las siguientes ip
192.168.1.254 que es la de mi computadora
192.168.1.96 la del router

Ahora nos vamos a la pestaña de Mitm y le damos click en arp poisoning y damos click en el recuadro de sniff remote conections

Le damos click a la pestaña de start y le damos a start sniffing y empezara a realizar su trabajo para observar lo que se esta haciendo  le damos a la pestaña view y le damos click a connections

Como podemos ver en la columna de bytes estan registrados todos los procesos que se están usando al momento de abrir una ventana, abrir google, etc

Como podemos ver este registro marcado es la pagina de youtube con un vídeo en reproducción como se puede ver en la segunda imagen como pueden observar el envío de paquetes es demasiado va en 1774679 de consumo de datos e iva en aumento.

Otro ejemplo tenemos google donde los datos son 716 por solo entrar a la pagina


Ahora probaremos el modo texto y como se ve utilizaremos los mismo paso para sacar lo anterior solo que en este caso se mueve con las teclas y no con el mouse


En la siguiente imagen sniffeamos la misma computadora y como podemos ver aquí todo el consumo de datos es solo de abrir y cerrar ventanas de chat en facebook


Aquí tenemos sniffeado facboock de una conversación.

Aquí al final podemos observar la cantidad de datos usados.