Congestión/Tráfico en redes con ns-2

La conexión que se estableció es simple, solo son dos nodos y se crea una conexión udp, por lo que podría pasar por un servicio de VoiP, o al menos es la misma idea:

El codigo para la simulación ns-2, es muy parecido al que se ha estado usando en las entradas anteriorres:



Faltaron las pruebas de rendimiento... :/

Actividad #9 Lab - Ahorro de Energía (lifetime)

Para esta tarea, se realizó un resumen del siguiente documento:

Maximum Network Lifetime in Wireless Sensor Networks with Adjustable Sensing Ranges

Autores: Mihaela Cardei, Jie Wu, Mingming Lu, Mohammad O. Pervaiz

El documento habla acerca de mecanismos para extender o como optimizar la vida útil o tiempo de actividad de una red inalámbrica (cuando se están usando baterías) esto debido al alto consumo de energía al transmitir datos o al tratar de conectar con nuevos nodos.

Debido a que las redes inalámbricas son muy dinámicas en cuanto a la conexión con otros nodos/clientes, es decir la mayoría de las veces no se tiene un límite de usuarios por lo que el consumo de energía puede variar mucho además de esto las variados posiciones que los nodos pueden tomar hacen que el uso de una topología para tener más orden sea más complejo.

Para estos casos, los limitantes son el tamaño (capacidad) de la batería y el peso de esta, generalmente a más capacidad más peso, por lo que actualmente esto impacta directamente en el tiempo de vida de una red de este tipo (sobre todo en dispositivos móviles) ya que siempre se busca la movilidad.

Los mecanismos para extender la vida de estas redes se pueden clasificar en dos tipos:

·         Manejar la activación y desactivación de ciertos nodos.

·         Ajustar la transmisión de datos o el rango que cubre la red.

Algunos problemas que se deben repasar para llevar a cabo el punto central del documento, son los algunos ya conocidos como:

·         Área de cobertura: el objetivo es cubrir cierta área de interés.

·         Puntos/objetivos a cubrir: Dar servicio de cobertura a ciertos nodos.

·         Problemas de cobertura: Determinar el máximo tráfico que puede viajar dentro de la red.

Algunas soluciones propuestas a estos problemas en otras ocasiones, una de ellas es:

·         Una correcta distribución de nodos y protocolo (manejando la activad de la red en rounds), estos nodos se activan para cubrir cierto espacio (donde se requieren conexión) mientras los otros se desactivan porque no se requiere conexión.

El punto aquí es como determinar el número óptimo de nodos para satisfacer las necesidades de la red, como determinar los rounds y en qué punto se debe de cambiar de uno a otro, la posición correcta de estos nodos, la transmisión de datos, todos estos puntos son necesarios con el fin de optimizar el consumo de energía y con esto alargar la vida útil de la red.

El problema planteado (de manera muy general) más formalmente se puede definir de la siguiente forma:

Se tiene cierta cantidad de nodos ubicados de manera aleatoria con el fin de cubrir ciertos objetivos, cada nodo tiene su consumo inicial de energía y la capacidad de ajustar la intensidad de su señal (se definen n opciones). El nodo central tiene la capacidad de conectarse a cualquier otro nodo.

Y se necesita un método para calcular la relación de cobertura entre un nodo y un objetivo (cliente), es decir si la distancia Euclidiana entre el nodo y el cliente no es mayor a una distancia dentro del área de cobertura original.

Con esta información, si la distancia es menor que la cubierta originalmente, se puede modificar para que se disminuya intensidad y así reducir el consumo de energía, en caso de lo contrario se recalcula un nuevo nodo, y se repite el proceso para tratar de disminuir la intensidad de su señal.

La idea de problema se puede aclarar con la siguiente figura:

Donde las s_n son los nodos, los t_n son las clientes/objetivos y las r_n son las opciones de intensidad.

  

Para la obtención de resultados sobre este problema, en el documento se proponen y se aplican tres métodos heurísticos (LP-based heuristic and greedy-based heuristic(centralized and distributed) ) creados por ellos mismos, los métodos se aplican sobre el planteamiento del problema como Programación Entera.

Dos de los métodos se ejecutan en el nodo central, mientras que otro se ejecuta en los nodos con el fin de obtener diferentes perspectivas y nombrar el “más” correcto.

Después de las respectivas simulaciones, los resultados se pueden categorizar de la siguiente forma:

En la figura se muestra el tiempo de vida útil de la red, obtenida de los tres diferentes métodos variando el número de nodos.

En esta figura se muestra como varía la vida útil de la red al modificar la intensidad de los nodos.

Conclusiones

La idea que se propone es buena al tratar de economizar el consumo de energía sobre todo si se trata de dispositivos dependientes de una batería, pero como lo dije en la entrada anterior, los resultados de una simulación pueden resultar engañosos ya que es muy difícil el replicar completamente el comportamiento de cierto medio, por lo que los resultados obtenidos en una simulación pueden no ser los mismos al aplicarse los métodos en un contexto real.

Otro punto, si la idea es disminuir el consumo de energía para alargar la vida útil de la red, según yo resulta contraproducente el realizar cálculos extras para poder aplicar los métodos que se mencionan en el documento, obtener los resultados y tomar decisiones. Estos cálculos extras se reflejaran directamente en el consumo de energía ya que antes no se hacían y al parecer esto no se tomó en cuenta en el documento.

________________________________________________________________________

Enlaces:

http://www.cse.fau.edu/~mihaela/HTML/PAPERS/WIMOB_2005.pdf

Actividad Lab. #8 - Congestión de Redes

Resumen de:

Congestion Control for Scalable Video Streaming Using the Scalability Extension of H.264/AVC

Autores: Dieu Thanh Nguyen and Joern Ostermann

IEEE JOURNAL OF SELECTED TOPICS IN SIGNAL PROCESSING, VOL. 1, NO. 2, AUGUST 2007

Mencionan que en la actualidad la demanda del video streaming ha crecido en gran medida, ya que la mayoría de los servicios que hay en internet ofrecen de diferentes formas contenido presentado de esta forma, como puede ser video streaming de servicios como youtube, dailymotion donde el video se descarga normalmente a nuestra computadora mientras se reproduce o servicios de video on demand donde el video se descarga y se “decodifica” para que lo podamos ver, o también video streaming de transmisiones en vivo, donde puede ocurrir algo parecido al video on demand.

Cada una de estas formas de prestar el servicio de streaming acusa un congestionamiento o saturación de la red, ya que la mayoría de las aplicaciones consumen la mayor parte del ancho de banda que se encuentre disponible dejando sin recursos a otras aplicaciones o usuarios incluso afectando a sí mismos si el ancho de banda no es el adecuado que se ve reflajado como pérdida de paquetes, retrasos, etc.

La propuesta de este paper es una especie de algoritmo para controlar en gran medida el congestionamiento de las redes al utilizar servicios de streaming, la idea que proponen es que este algoritmo se encuentre en funcionamiento directamente en los servidos de las aplicaciones de streaming y no en los clientes (que sería lo más entendible), se busca que este algoritmo sea capaz de optimizar totalmente el flujo de datos teniendo en cuenta las carencias de la red del cliente que se conecte para así no saturar su propia red ni la del cliente, y tener más oportunidades de ofrecer un mejor servicio al momento de la conexión de un gran número de clientes a la vez.

Un aspecto importante a mencionar en el paper es el formato/codificación para video que proponen para mejorar el flujo cuando se hace streaming, que ya desde hace tiempo varias organizaciones han buscado su estandarización y que al parecer a la fecha la norma se quedó en H.264/AVC.

Estos formatos permiten organizar la información contenida en el video de manera que se pueden producir grandes calidades de imagen a menores cantidades de espacio, debido a sus mecanismos de compresión/descompresión por lo que son ideales para aplicaciones para hacer streaming.

Arquitectura del sistema propuesto

Debido a que las aplicaciones de video streaming se ejecutan usando UDP como protocolo de transporte y no TCP, se desaprovechan algunas opciones de este último como el hecho de poder reducir la latencia mediante retransmisión de paquetes, además el protocolo UDP no provee mecanismos para controlar la congestión de la red (TCP si lo hace) y al querer implementar algo para arreglar esto, es necesario que lo que se cree se ejecute en la capa de aplicación del UDP.

Para la estimación del ancho de banda disponible y evitar la congestión de la red, el algoritmo propuesto identifica los cuellos de botella, es decir los puntos en los que la conexión se reduce considerablemente evitando el flujo de la información, con estos embotellamientos detectados procede a disminuir la carga del flujo de información con el fin de no presionar el embotellamiento y causar más caos, y recalcula estos embotellamientos constantemente para decir el tamaño del flujo.

Debido a que la estimación del ancho de banda puede fallar (se calcula el ancho de banda disponible pero la información de este llega retrasada por lo que el flujo de datos a enviar puede no ser el correcto en ese momento), también se propone un mecanismo que actúe en caso de que este error ocurra. La idea es tomar todos los paquetes recibidos y ordenarlos según su prioridad, debido a que el dato de la estimación del ancho de banda puede no ser correcto, estos paquetes se comienzan en enviar de manera que los de mayor prioridad sean los primeros y después los de menor prioridad.

Esto es debido a que el decodificador del video si puede reconstruir la estructura del video a partir de los paquetes con mayor prioridad (lo hace disminuyendo la calidad de video o con breves pérdidas de calidad) y no puede hacer esto partiendo de los paquetes con menos prioridad.

Esto se hace así con el fin de que si el ancho de banda no es el adecuado, solo se pierdan los paquetes de menor calidad y la transmisión del video pueda continuar.

Una imagen de la simulación del sistema con ns-2, donde se espera hacer streaming desde el servidor al cliente, el enlace entre las dos partes de simula utilizando dos routers (R1 y R2) y el cuello de botella será el el menor ancho de banda que produzca alguno de estos dos routers (1200kbit/s). El protocolo de envío de paquetes es UDP.

Los resultados de la simulación anterior comparándolo con los manejos de TCP y UDP se pueden ver en la siguiente gráfica:

Conclusiones

En conclusión se puede decir que la idea de estos tipos es buena, aunque se puede mejorar utilizando un sistema parecido pero ejecutándose en los clientes y que interactúe con el del servidor, de esta manera se puede obtener mayor precisión en los datos para los cálculos de los anchos de banda o el envío de información.

Y aunque a simple vista los resultados pueden ser favorables, un escenario simulado no ofrece con exactitud los mismos factores de un escenario real, por lo que el aplicar este sistema en escenarios reales puede que no arroje los mismos resultados que se muestran anteriormente.

_________________________________________________________________________________

Referencias:

Dieu Thanh Nguyen and Joern Ostermann, "Congestion Control for Scalable Video Streaming Using the Scalability Extension of H.264/AVC", IEEE JOURNAL OF SELECTED TOPICS IN SIGNAL PROCESSING, VOL. 1, NO. 2, AUGUST 2007
Link al paper -> http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=04276656

Actividad #6 : Topologías de Redes con ns-2

Para esta vez la tarea es tratar de lograr topologías de redes parecidas a alguna forma conocida, formé esta con el simulador de ns-2, conocida como "estrella":

El código de ns-2 para lograr esta topología:



Para formar topologías nuevas, partiendo de la anterior, podemos crear los scripts de ns-2 desde un script de python que reciba unos cuantos parámetros y que posterior los ejecute.

Los scripts se crearían a partir de impresiones de texto archivos de txt con la extensión .tcl de ns-2, su ejecución podría ser con alguna llamada al sistema.

Partiendo de querer crear una topología de estrella, la idea podría ser esta:



La salida de este script es la misma que el script mostrado de ns-2, solo con cambios en el numero de nodos que se manejan.

Para crear otras topologías se pueden tomar como referencias otros patrones en la forma de conectar los nodos o inlcusive conectar todos los nodos de manera aleatoria a ver que sale :P.