martes, 30 de abril de 2013

Reporte - Control de Congestión.

Para esta semana se nos encargo una simulación en Ns-2 sobre control de congestión y realizar un reporte.

Anteriormente, realice un post sobre ns-2, donde inicie con algo básico, por si es necesario algo de retro alimentación.

Control de Congestión.

Primero, se realizaron las siguientes pruebas:

Prueba 1:

Ya que el nodo 1, enviaba mas paquetes que los demás nodos, como se muestra en la siguiente imagen:
Después que se saturaba de paquetes, se cerraba el nodo (se cerraba y se mostraba con el nodo en color rojo), y así evitar congestionamiento, como se muestra la siguiente imagen:

Prueba 2:

En este método  cuando se congestiona con tantos paquetes, solo lo que hace es reducir el proceso de envió  baja y se estabiliza, y en teoría, se vuelven "normales" las tasas de envió.

Simulación

Y el código es el siguiente:

Código:

Al código esta vez se agrego código para controlar la congestión, esta documentado donde se muestran cuales son los métodos para controlar.

Resultados de Pruebas:

Vídeo de Prueba 1:

Mostrando cuando se cierra el nodo y se controla la perdida de paquetes, así evitamos que la simulación pierda paquetes durante todo el proceso

Vídeo de Prueba 2:

Se muestra como baja el proceso de envió, así evitando perdida de paquetes y se estabiliza. 

lunes, 29 de abril de 2013

Resumen - Ahorro de Energía.

Tema: A Centralized Energy-Efficient Routing
Protocol for Wireless Sensor Networks

SIVA D. MURUGANATHAN, DANIEL C. F. MA, ROLLY I. BHASIN, AND
ABRAHAM O. FAPOJUWO, UNIVERSITY OF CALGARY

Introducción: 

Las Redes de sensores inalámbricos constan de cientos o miles de nodos de baja potencia que operan con capacidades computacionales y de detección limitadas.

La evolución de las tecnologías inalámbricas de micro-sensores integrados han hecho que estos nodos esten disponibles en gran número y a un bajo costo, para ser empleados en aplicaciones de seguridad militar, en vigilancia del medio ambiente, etc.

En contraste con los sensores tradicionales, las redes de sensores ofrecen una proposición flexible en términos de la facilidad de implementación y múltiples funcionalidades.

En el caso de nodos de sensores inalámbricos modernos, sus dimensiones físicas permiten un gran número de nodos de sensores para ser desplegados al azar en terrenos inaccesibles.

Los nodos en una red de sensores inalámbricos también son capaces de llevar a cabo otras funciones tales como el procesamiento de datos y de enrutamiento.


Modelos de Redes y Radio

1.- El modelo de red y Arquitectura

La base de BCDCP radica en que la estación base es un nodo de alta energía con una gran cantidad de suministro de energía.

Por lo tanto, BCDCP utiliza la estación base para controlar la tarea de detección coordinado realizado por los nodos sensores.

Aquí se muestra un modelo de red de sensores con las siguientes propiedades:

• Una estación de base fija que se encuentre lejos de los nodos de sensores.
• Los nodos sensores disponen de energía finita
• Los nodos están equipados con funciones de control de potencia.
• Cada nodo detecta el medio ambiente a una tasa fija.
• Todos los nodos sensores son inmóviles.

Los dos elementos clave que se consideran en BCDCP son los nodos sensores y la estación base.

2.- El Modelo de Radio

Un nodo sensor típico se compone de cuatro componentes principales: una unidad de procesador de datos, un micro-sensor; un sub-sistema de comunicación por radio que consiste en un transmisor/receptor de la electrónica, antenas, y un amplificador y una unidad de fuente de alimentación.

Aunque la energía se disipa en todos los tres primeros componentes de un nodo sensor, se considera que las disipaciones de energía asociados con el módulo de radio ya que el objetivo central es desarrollar un protocolo de capa de red de eficiencia energética para mejorar la vida de la red.



Estación de base controlado
Protocolo Clustering Dinámico

El BCDCP es un sensor inalámbrico de protocolo de enrutamiento, es un componente esencial con capacidades computacionales complejos, por lo que los nodos de sensores son simples y rentables.

Opera en dos fases principales: la configuración y comunicación de datos.


1.- El esquema de direccionamiento

En las redes tradicionales, a los nodos se le asignan direcciones fijas, sin embargo, debido a los altos costos, el esquema de direccionamiento fija podría no ser adecuado para redes de sensores inalámbricas.

Además, ya que el usuario final está más interesado en las consultas basadas en atributos tales como "Envíame el número de vehículos estacionados en el lote número 7," es más probable que utilice un esquema de direccionamiento basado en los nodos, atributos y posiciones geográficas.

Por lo tanto, para BCDCP se uso una clase basada en abordar de forma <Location ID, Tipo de nodo ID>.
El ID identifica la ubicación de un nodo que lleva a cabo actividades de detección en una región determinada de la red.

2.- La fase de configuración

Las principales actividades de esta fase son la configuración del clúster, la selección de cabeza de racimo, formación de ruta de acceso, y la programación para cada cluster.

Durante cada fase de configuración, la estación base recibe información sobre el estado actual de la energía de todos los nodos de la red.

Basado en esta información, la estación base calcula primero el nivel de energía media de todos los nodos y, a continuación elige un conjunto de nodos, denotado S, cuyos niveles de energía están por encima del valor medio.

Las cabezas del clúster se elegirán del conjunto S, que asegura que sólo los nodos con suficiente energía quedan seleccionadas como jefes de racimo, mientras que aquellos con bajo consumo de energía puede prolongar su vida mediante la realización de tareas que requieren bajos costos de energía.

En BCDCP, se llevaron a cabo tareas o pruebas, por medio de un algoritmo iterativo.
Este algoritmo divide primero la red en dos sub-grupos, y procede más mediante el fraccionamiento de los sub-grupos en grupos más pequeños.

El algoritmo se asegura que los jefes de racimo seleccionados se colocan de manera uniforme en todo el campo de detección mediante la maximización de la distancia entre las cabezas de racimo en cada paso de la división.


3.- La fase de comunicación de datos

La fase de comunicación de datos consta de tres actividades principales:

  • La recolección de datos
  • Fusión de datos
  • Enrutamiento de datos

Utilizando el esquema de creación TDMA, cada nodo sensor transmite la información detectada a su cabeza de racimo.
Puesto que los nodos sensores están geográficamente agrupados, estas transmisiones consumen un mínimo de energía debido a pequeñas separaciones espaciales entre la cabeza y los nodos sensores.

Una vez que se han recibido los datos de todos los nodos de sensores, la cabeza de racimo realiza la fusión de datos en los datos recogidos, y reduce la cantidad de datos en bruto que necesita ser enviado a la estación base.


Los datos comprimidos, junto con la información requerida por la estación base para identificar correctamente y decodificar los datos del cluster, son entonces enviados de nuevo a la estación base a través de la ruta de enrutamiento.


Evaluación del Desempeño

Para evaluar el desempeño de BCDCP, se simulo el rendimiento usando Matlab y se comparó su desempeño con otros clustering basado en protocolos de enrutamiento.
El rendimiento se mide por indicadores cuantitativos de la disipación de energía promedio, la vida útil del sistema, los mensajes de datos totales entregadas con éxito, y el número de nodos que están vivos.

A lo largo de las simulaciones, se considero varias configuraciones de red al azar con 500 nodos en los que se asigna a cada nodo de una energía inicial.


Conclusión:


En este artículo se propone un protocolo centralizado clustering basado en BCDCP que utiliza la estación base de alta energía para realizar la mayoría de tareas de uso intensivo de energía.

Mediante el uso de la estación base, los nodos sensores se ven exentas de la realización de tareas de cálculo intensivo de energia tales como la configuración del clúster, la selección de cabeza de racimo, la formación de ruta de enrutamiento y TDMA creación horario.

El rendimiento del protocolo BCDCP se evalúa por simulación y comparación con otros protocolos basados ​​en la agrupación (Leach, Leach-C, y PEGASIS).

Los resultados de simulación muestran que BCDCP supera a sus comparativas mediante la colocación de las cabezas de racimo uniformemente a lo largo de todo el campo del sensor, la realización de agrupación equilibrada, y el uso de una-a-CH CH esquema de enrutamiento para transferir los datos fusionados a la estación base.

Por lo tanto, se concluye que BCDCP proporciona un esquema de enrutamiento energéticamente eficiente adecuado para una amplia gama de aplicaciones de detección.


Referencias: 


Referencia de documento:

lunes, 22 de abril de 2013

Resumen - Control de Congestión

Tema: Improving TCP Congestion Control over Internets with Heterogeneous
Transmission Media

Christina Parsa and J.J. Garcia-Luna-Aceves
Computer Engineering Department
Baskin School of Engineering
University of California

Introducción

La "Transmisión de extremo a extremo de los datos fiables" es un servicio muy necesario para muchas de las aplicaciones actuales se ejecutan a través de Internet (por ejemplo, WWW, transferencia de archivos, correo electrónico, acceso remoto), que hace que TCP sea un componente esencial de la actual Internet.

Los problemas de rendimiento de las implementaciones TCP actuales de Internet en los medios de transmisión heterogéneos se derivan de las limitaciones inherentes en la recuperación de errores y mecanismos de control de congestión que utilizan.

El efecto secundario desafortunado de este enfoque es que no hay estimaciones y se realizan en períodos de congestión.

Dado que todos los métodos Reno y Tahoe no pueden realizar estimaciones de RTT durante períodos de congestión, una estrategia es la de un temporizador de retardo de envío donde se utiliza para evitar las retransmisiones prematuros.

Reno y Tahoe implementan TCP y muchas soluciones alternativas proponen el uso de pérdida de paquete como una indicación primaria de la congestión; un emisor TCP aumenta su tamaño de la ventana, hasta que se produzcan pérdidas de paquetes a lo largo de la ruta de acceso al receptor TCP.

Por otra parte, la fluctuación periódica y amplia de tamaño de la ventana típica de Reno y Tahoe provoca grandes fluctuaciones de retraso, por lo que la variación del retardo en los extremos de la conexión genera un efecto secundario que es inaceptable para aplicaciones sensibles al retardo.

Bajo tales condiciones, el control de la congestión sobre la base de acuse de recibo (ACK) contando como en TCP, Reno y Tahoe resultados en subutilización significativa de la mayor capacidad de enlace hacia delante debido a la pérdida de ACK en el enlace inverso más lenta.

Las pérdidas ACK también conducen al tráfico de datos muy explosivas en el camino hacia adelante.
Por esta razón, se necesita un mejor algoritmo de control de congestión que es resistente a las pérdidas de ACK.

En este trabajo, proponen TCP Santa Cruz, que es una nueva implementación de implementable TCP.

TCP Santa Cruz detecta no sólo las etapas iniciales de la congestión, pero también puede identificar la dirección de la congestión, es decir, se determina si la congestión se está desarrollando en el camino hacia delante y después hacia adelante aísla el rendimiento de eventos tales como la congestión en el camino inverso.

La dirección de la congestión se determina calculando el retraso relativo de que un paquete de experiencias con respecto a otro; este retraso relativo es la base de nuestro algoritmo de control de congestión.

TCP Santa Cruz proporciona una estrategia de recuperación de errores mejor que Reno y Tahoe hacen al proporcionar un mecanismo para llevar a cabo estimaciones RTT para cada paquete transmitido, incluyendo retransmisiones.


1. TCP Santa Cruz - Descripción del protocolo

TCP Santa Cruz proporciona una mejora a través de TCP Reno en dos áreas principales: el control de la congestión y la recuperación de errores.

El algoritmo de control de congestión TCP introducida en Santa Cruz determina cuando existe congestión o está desarrollando en la ruta de datos hacia adelante - una condición que no puede ser detectada por una estimación del tiempo de ida y vuelta.

Este tipo de monitoreo permite la detección de los estados incipientes de congestión, lo que permite la ventana de congestión para aumentar o disminuir en respuesta a señales de alerta temprana.

Además, TCP Santa Cruz utiliza cálculos retardo relativo para aislar el rendimiento hacia adelante de cualquier congestión que pueda estar presente a lo largo de la ruta inversa.

Los métodos de recuperación de errores introducidos en TCP Santa Cruz realizan oportunas retransmisiones de paquetes perdidos, eliminar las retransmisiones innecesarias para los paquetes recibidos correctamente cuando se producen pérdidas múltiples dentro de una ventana de datos, y proporcionan estimaciones RTT durante períodos de congestión y de la distribución (es decir, eliminar la necesidad de algoritmo de Karn).


1.1. Control de la congestión

a) La eliminación de ambigüedad RTT utilizando retardos relativos

Mediciones de tiempo de ida y vuelta por sí solos no son suficientes para determinar si existe congestión a lo largo de la ruta de datos.

La figura 1 muestra un ejemplo de la ambigüedad que tienen lugar cuando se consideran únicamente las mediciones de RTT.

La congestión es indicada por una cola a lo largo de la trayectoria de transmisión.
El ejemplo muestra la transmisión de dos paquetes de datos y los ACKs que regresan desde el receptor.

La verdadera causa del aumento de RTT para el segundo paquete es la congestión a lo largo del camino de retorno, no la ruta de datos.

Nuestro protocolo resuelve esta ambigüedad mediante la introducción de la noción de la demora relativa.





Demora relativa es el aumento y disminución de la demora que los paquetes de experiencia con respecto a la otra cuando se propagan a través de la red.
Estas medidas son la base de nuestro algoritmo de control de congestión.


b) Algoritmo de control de congestión

En cualquier momento durante una conexión, las colas de la red (y específicamente la cola de cuello de botella) están en uno de tres estados: incrementan en tamaño, disminuyendo de tamaño, o el mantenimiento de su estado actual.

El diagrama de estados de la Figura 4 muestra cómo el cálculo del retardo relativo hacia adelante permite la determinación del cambio en el estado de la cola.

El objetivo en el TCP Santa Cruz es para permitir que las colas de la red (específicamente la cola de cuello de botella) para crecer a un tamaño deseado, el algoritmo específico para lograr este objetivo se describe a continuación.

Los valores de retardo relativos positivos y negativos representan cola adicional o menos en la red, respectivamente.

El algoritmo de control de congestión de TCP Santa Cruz opera mediante la suma de los retardos relativos desde el comienzo de una sesión, y a continuación, la actualización de las mediciones a intervalos discretos, con cada intervalo igual a la cantidad de tiempo para transmitir una ventana completa de datos y recibir los ACKs correspondientes .

En otras palabras, el algoritmo intenta mantener la condición siguiente:


Donde nti es el número total de paquetes en cola en el cuello de botella a la hora de ti, Nop es el punto de trabajo (el número deseado de paquetes, por sesión, para ser puesto en cola en el cuello de botella); MWi-1 es la cantidad adicional de hacer cola durante una presentación la ventana anterior Wi-1, y nt1 = MW0.

1.2. Recuperación de Errores

a) Mejora de la estimación de RTT

TCP Santa Cruz ofrece una mejor estimación de RTT sobre los enfoques tradicionales TCP midiendo el tiempo de ida y vuelta (RTT) de todos los segmentos de transmisión para el cual se recibe un ACK, incluyendo retransmisiones.

Esto elimina la necesidad de que el algoritmo de Karn (en el que no se hacen mediciones de RTT para las retransmisiones) y las estrategias de temporizador backoff (en la que el valor de tiempo de espera se duplicó prácticamente después de cada tiempo de espera y de la distribución).

Para lograr esto, TCP Santa Cruz requiere que cada paquete ACK de retorno para indicar el paquete exacto que causó el ACK que se generan y el remitente debe tener una marca de tiempo para cada paquete transmitido o retransmitido.

Los paquetes se pueden identificar de forma única por especificando un número de secuencia y un número de copias retransmisión.

b) Ventana ACK

Para ayudar en la identificación y la recuperación de paquetes perdidos, el receptor TCP en Santa Cruz devuelve una ventana ACK al remitente para indicar cualquier agujero en la corriente secuencial recibido.

En el caso de múltiples pérdidas por ventana, la ventana TCP ACK permite-SC para retransmitir todos los paquetes perdidos sin tener que esperar por un tiempo de espera de TCP.

La ventana ACK es similar a los vectores de bits utilizadas en los protocolos anteriores, tales como NETBLT y TCP-SACK.

A diferencia de TCP SACK, el enfoque de este documento proporciona un nuevo mecanismo por el que el receptor es capaz de informar sobre el estado de todos los paquetes en la transmisión actual.

La ventana ACK se mantiene como un vector en el que cada bit representa la recepción de un número especificado de bytes más allá de la ACK acumulativo.
El receptor determina una granularidad óptima para los bits en el vector e indica este valor al remitente a través de un campo de un byte en la cabecera.

Esto ayuda a evitar la retransmisión innecesaria de paquetes recibidos correctamente después de un tiempo de espera cuando la sesión entra en arranque lento.

c) Política de retransmisión

La estrategia de retransmisión es motivada por pruebas como los informes de seguimiento de Internet por Lin y Kung, que muestran que el 85% de los tiempos de espera de TCP se debe a la "no-disparo".

"No-disparo" se produce cuando un paquete es retransmitido por el remitente sin intentos anteriores, es decir, cuando tres ACKs duplicados no llegan a la remitente y por lo tanto mecanismo de retransmisión rápida de TCP nunca ocurre.

En este caso, no hay retransmisiones pueden ocurrir hasta que hay un tiempo de espera en la fuente.

Por lo tanto, se necesita un mecanismo para recuperar rápidamente las pérdidas sin que sea necesario esperar tres ACKs duplicados desde el receptor.

Dado que TCP Santa Cruz cuenta con un presupuesto mucho más ajustado del tiempo RTT por paquete y que el TCP Santa Cruz remitente recibe información precisa sobre cada paquete recibido correctamente (a través de la ventana ACK), TCP Santa Cruz puede determinar cuando un paquete se ha caído sin esperando algoritmo de retransmisión rápida del TCP.

TCP Santa Cruz puede retransmitir y recuperar rápidamente un paquete perdido una vez que cualquier ACK sea transmitido posteriormente y sea cumpla una restricción de tiempo.

1.3 Implementación propuesta

TCP Santa Cruz se puede implementar como una opción de TCP que contiene los campos representados en la Tabla 1.

La opción TCP Santa Cruz puede variar en tamaño de 11 a 40 bytes,

2. Resultados de rendimiento

Se muestran los resultados de rendimiento para una configuración básica con una sola fuente y un enlace cuello de botella, y luego una sola fuente de tráfico cruzado en el camino de retorno, y, finalmente, el rendimiento a través de enlaces asimétricos.

Se midio el rendimiento de TCP Santa Cruz a través de simulaciones que utilizan la red "ns" simulador
El simulador contiene implementaciones de TCP Reno y TCP Vegas.

TCP Santa Cruz se llevó a cabo mediante la modificación del código fuente TCP Reno existente para incluir los nuevos regímenes de recuperación de errores y evitar la congestión.

2.1 Con guración Básica Cuello de botella

Nuestro primer experimento muestra el rendimiento del protocolo en una red simple, representado en la Figura 7, que consiste en una fuente TCP enviando paquetes de datos 1 Kbyte a un receptor a través de dos enrutadores intermedios conectados por un enlace de cuello de botella de 1,5 Mbps.

El BWDP de esta configuración es igual a 16.3Kbytes, por lo tanto, con el fin de acomodar una ventana completa de los datos, los routers se establecen para mantener los paquetes 17.

Las figuras 8 (a) y (b) muestran el crecimiento de ventana de congestión de TCP Reno y la acumulación de cola en el enlace de cuello de botella.

Los routers empiezan a caer los paquetes una vez que la cola está llena, con el tiempo Reno da cuenta de la pérdida, retransmisiones y reduce la ventana de congestión a la mitad.
Esto produce oscilaciones sube y baja, tanto en el tamaño de la ventana y de la longitud de la cola cuello de botella.

En contraste, las Figuras 9 (a) y (b) muestran la evolución de la ventana de congestión del remitente y la acumulación de cola en el cuello de botella para TCP Santa Cruz.

Estas cifras demuestran la fortaleza principal de TCP Santa Cruz: la adaptación del algoritmo de control de congestión para transmitir en el ancho de banda de la conexión sin congestionar la red y sin desbordamiento de las colas de cuello de botella.

La Figura 9 (b) muestra la longitud de la cola en el enlace de cuello de botella para TCP Santa Cruz alcanza un valor de estado estacionario entre 1 y 2 paquetes.

El algoritmo mantiene este valor de estado estacionario durante la duración de la conexión.

Conclusión

Se presento TCP Santa Cruz, que implementa un nuevo enfoque para el control de congestión de extremo a extremo y fiabilidad, y que puede ser implementado como una opción TCP.

TCP Santa Cruz hace uso de una marca de tiempo sencilla devuelto desde el receptor para estimar el nivel de formación de colas en el enlace de cuello de botella de una conexión.

El protocolo aísla con éxito el rendimiento hacia adelante de la conexión de eventos en el enlace inverso teniendo en cuenta los cambios en el retardo a lo largo de sólo el enlace directo.

El protocolo proporciona rápida y eficiente de recuperación de errores mediante la identificación de las pérdidas a través de una ventana ACK sin esperar tres ACKs duplicados.

Una estimación del RTT para cada paquete transmitido permite que el protocolo para recuperarse de retransmisiones perdidos sin el uso de estrategias de temporizador-backoff, eliminando la necesidad de algoritmo de Karn.

Los resultados de simulación muestran que TCP Santa Cruz proporciona un alto rendimiento y bajo retardo de extremo a extremo y la varianza del retardo a través de redes con un simple enlace cuello de botella, las redes con la congestión en el camino de retorno de la conexión, y redes que exhiben camino
asimetría.

Hemos demostrado que el TCP Santa Cruz elimina las oscilaciones en la ventana de congestión, pero todavía mantiene una alta utilización de enlace.

Referencias


[1] H. Balakrishnan, S. Seshan, and R. Katz. Improving reliable transport and handoff performance in cellular wireless networks. ACM Wireless Networks, Dec. 1995.

[2] L. Brakmo, S. O’Malley, and L. Peterson. TCP Vegas: New techniques for congestion detection and avoidance. In Proc. SIGCOMM’94, pages –, London, UK, Aug./Sept. 1994. ACM.

[3] L. Brakmo and L. Peterson. TCP Vegas: End-to-end congestion avoidance on a global internet. In IEEE Journal of Selected Areas in Communication, October, 1995.

[4] D. Clark, M. Lambert, and L. Zhang. NETBLT: A high throughput transfer protocol. In Proc. SIGCOMM, pages 353–59, Stowe, Vermont, Aug. 1987. ACM.

[5] K. Fall and S. Floyd. Simulation-based comparisons of tahoe,reno, and SACK TCP. In Computer Communication Review, volume 26 No. 3, pages 5 – 21, July, 1996.

[6] S. Floyd and V. Jacobson. Random Early Detection gateways for congestion avoidance. IEEE/ACM Transactions on Networking, 4(1):397–413, Aug 1993.

[7] R. Jacobson, R. Braden, and D. Borman. Rfc 1323 TCP extensions for high performance. Technical report, May 1992. Technical Report 1323.

[8] V. Jacobson and S. Floyd. TCP and explicit congestion notification. In Computer Communication Review, volume 24 No. 5, pages 8 – 23, October, 1994.

[9] P. Karn and C. Partridge. Improving round-trip time estimates in reliable transport protocols. In Computer Communication Review, volume 17 No. 5, pages 2 – 7, August 1987.

[10] S. Keshav. Packet-pair flow control. http://www.cs.cornell.edu/skeshav/papers.html.

[11] T. Lakshman, U. Madhow, and B. Suter. Window-based error recovery and flow control with a slow acknowledgement channel: a study of TCP/IP performance. In Proceedings IEEE INFOCOM ’97, number 3, pages 1199–209, Apr 1997.

[12] D. Lin and H. Kung. TCP fast recovery strategies: Analysis and improvements. In Proceedings IEEE INFOCOM ’98, Apr. 1998.

[13] L.Kalampoukas, A. Varma, and K. Ramakrishnan. Explicit window adaptation: a method to enhance TCP performance. In Proceedings IEEE INFOCOM ’98, pages 242 – 251, Apr. 1998.

[14] M. Mathis and J. Mahdavi. Forward acknowledgment: Refining TCP congestion control. In Proc. SIGCOMM’96, pages 1–11, Stanford, California, Sept. 1996.

[15] M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow. TCP selective acknowledgment options. Technical report, Oct. 1996. RFC 2018.

[16] S. McCanne and S. Floyd. ns-lbnl network simulator. http://wwwnrg.ee.lbl.gov/ns/.

[17] C. Parsa and J. Garcia-Luna-Aceves. Improving TCP performance over wireless networks at the link layer. ACM Mobile Networks and Applications Journal, 1999. to appear.

[18] N. Samaraweera and G. Fairhurst. Explicit loss indication and accurate RTO estimation for TCP error recovery using satellite links. In IEE Proceedings - Communications, volume 144 No. 1, pages 47 – 53, Feb., 1997.

[19] W. R. Stevens. TCP/IP Illustrated, Volume 1. Addison-Wesley, 1996.

[20] J. Waldby, U. Madhow, and T. Lakshman. Total acknowledgements: a robust feedback mechanism for end-to-end congestion control. In Sigmetrics ’98 Performance Evaluation Review, volume 26, 1998.

[21] Z. Wang and J. Crowcroft. Eliminating periodic packet losses in the 4.3-Tahoe BSD TCP congestion control algorithm. In Computer Communication Review, volume 22 No. 2, pages 9 – 16, April, 1992.

[22] Z. Wang and J. Crowcroft. A new congestion control scheme: Slow start and search (Tri-S). In Computer Communication Review, volume 21 No. 1, pages 32 – 43, Jan., 1991.


Referencias de documento

martes, 16 de abril de 2013

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

martes, 9 de abril de 2013

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.