nueva página del texto (beta)
Artículo en XML
Referencias del artículo
Traducción automática
Enviar artículo por email
Citado por SciELO 
Similares en
SciELO 
Permalink
Introducción
Internet ha marcado una evolución en los últimos años, permitiendo el acceso y el intercambio de información de manera ágil, con características de flexibilidad en la tecnología de acceso y con capacidades de integración a nivel de servicios. La tendencia actual de Internet es fomentar la colaboración y el trabajo en comunidad a través de servicios construidos bajo el concepto de la Web 2.0. Estos servicios se agrupan o integran en plataformas tales como redes sociales, la cuales a pesar de crearse con fines de entretenimiento, han dado origen a las denominadas comunidades académicas virtuales VAC (Virtual Academic Communities), empleadas como instrumento de apoyo tecnológico a los procesos de E-Learning (Yue y Yi, 2009) que se definen como instrucciones entregadas en un dispositivo digital destinadas a apoyar el aprendizaje, donde el hardware de entrega puede ir desde computadoras de escritorio o portátiles a tablets o teléfonos inteligentes, pero la meta de las instrucciones es apoyar el aprendizaje individual o el desempeño organizacional (Clark y Mayer, 2016). Por lo anterior, es importante conocer el comportamiento de diferentes servicios de las VAC, como los foros, chats, blogs, wikis o servicios más complejos, como es el caso del servicio de videochat.
Actualmente existe el interés por incorporar este tipo de servicios multimedia en plataformas de E-Learning o T-Learning, donde este último se define como aprendizaje a través de televisión interactiva, esto es, tener acceso interactivo a materiales de aprendizaje ricos en video mediante un televisor (Campo et al., 2013) de tal manera que no es necesario recurrir a la vinculación de servicios externos. Teniendo en cuenta lo anterior, se eligió construir un modelo de tráfico para el servicio de videochat sobre una VAC. Para el estudio del modelo de este servicio, se utilizaron técnicas de emulación a través de la herramienta OPNET Modeler, entendiéndose emulación como la ejecución de simulaciones híbridas con tráfico real.
La simulación hibrida se conforma por el tráfico analítico y la simulación por eventos discretos DES (Discrete Event Simulation). Para el primero de estos, se usa el tráfico background, que afecta el desempeño del tráfico explícito al introducir retrasos adicionales, sin embargo, cada paquete de este tipo, también conocido como tráfico de fondo, no es explícitamente modelado, por consiguiente no generará un evento en cada estado del paquete y no tiene una porción de memoria para guardar todas las características del paquete (Lu y Yang, 2012), por consiguiente, la simulación será más rápida y usará menos recursos de memoria. Lo anterior con el fin de caracterizar y simular el comportamiento de la red a un nivel abstracto, donde en cada ejecución se calcula el efecto de dicho tráfico background sobre el tráfico de interés.
En cuanto a la construcción del modelo DES, se monitorizó el servicio de videochat, capturando las trazas de tráfico real. Luego, se caracterizó el servicio identificando cada uno de los actores, los protocolos y sus fases de conexión, transmisión de datos y desconexión. Con este proceso se obtuvo el comportamiento del servicio y el modelo estadístico denominado tráfico explícito, que describe el flujo de tráfico entre los diferentes actores, para su posterior programación a través de la herramienta de simulación. Finalmente se crea una red simulada o virtual, sobre la cual se ejecutó el modelo anteriormente obtenido.
El tráfico real se tomó desde los dispositivos reales que intervienen en el servicio de videochat, este se llevó hasta la red virtual mediante el módulo software SITL (System In The Loop) de OPNET Modeler, el cual proporciona una interfaz para conectar hardware de red o aplicaciones de software en vivo a una simulación OPNET de eventos discretos (Lu y Yang, 2012), permitiendo que el tráfico real fluya sobre la red virtual hasta alcanzar su destino; esto es, los dispositivos reales interactuando entre sí a través de la red simulada. Así, mediante estas técnicas de emulación donde se combinan entidades simuladas con componentes reales, se obtiene un mayor realismo y se proporciona a los usuarios la oportunidad de interactuar en la red y ajustar los parámetros del modelo mediante repeticiones de los experimentos. El tráfico real puede circular por redes simuladas complejas que sirven de interconexión entre los dispositivos reales, creando modelos de tráfico más exactos y evitando la necesidad de contar con toda una infraestructura de red. La simulación DES captura todos los mecanismos y efectos de los protocolos y servicios, reduciendo drásticamente los cálculos necesarios para modelar el tráfico en la red, y manteniendo los recursos necesarios para capturar en detalle parámetros específicos de interés. Mediante estos entornos de emulación se obtiene una mayor precisión con un consumo de recursos asequible.
Las contribuciones de este artículo son los procesos de construcción de la plataforma de emulación y de un modelo de tráfico de un servicio, el cual se constituye por el modelo estadístico y el emulado. Además se muestran los requisitos que existen en este campo para trabajar con servicios masivos. Para la evaluación del servicio de videochat se inició con la obtención del tráfico explicito, se construyeron los escenarios de evaluación y se analizó el rendimiento del servidor encargado de ejecutar la herramienta de emulación. Finalmente se analizaron los efectos que se generan sobre los modelos de tráfico.
El presente artículo se organizó de la siguiente forma: En la sección 2 se presentan los diferentes enfoques de construcción de los modelos de tráfico. En la sección 3 se describe el servicio de videochat. En la sección 4 se presenta la caracterización del tráfico con cada uno de sus procesos. En la sección 5 se describe el entorno de experimentación utilizado, incluyendo la red real y la red simulada. En la sección 6 se exponen los diferentes escenarios de prueba. En la sección 7 se presentan los resultados y finalmente en la sección 8 se presentan las conclusiones y los trabajos futuros.
Construcción de los modelos de tráfico
Es de interés conocer los modelos de tráfico de los diferentes servicios para tener la capacidad de dimensionar adecuadamente las infraestructuras de red. La construcción de modelos de tráfico y las pruebas de evaluación de los servicios es un gran reto para los diseñadores de redes e investigadores, donde la fidelidad riñe con la velocidad. Su estudio se puede abordar mediante bancos de pruebas, modelos analíticos, simulaciones o entornos de emulación.
Los bancos de prueba son una representación a escala del entorno real del servicio, que permite capturar con precisión las transacciones detalladas de la red, la desventaja de este enfoque son los costos en infraestructura. PlanetLab (Lo et al., 2014) es un ejemplo de la colección de máquinas distribuidas a través de Internet como un laboratorio para que los investigadores desarrollen nuevos servicios. Los modelos analíticos presentan la formulación matemática de los servicios para desplegarse sobre las redes, pero cuando el sistema se vuelve demasiado complejo, se requiere hacer supuestos para mantener los modelos manejables, lo cual va en contraposición a los detalles de implementación (Hui et al., 2014).
En los procesos de simulación se puede combinar en sus experimentos tráfico analítico y tráfico explicito, presentando las ventajas de la velocidad de ejecución y la flexibilidad por estar conformada solo por entidades virtuales, aunque existen dentro de la comunidad dudas acerca de la fiabilidad y la precisión de las simulaciones (Pawlikowski, 2003). La dificultad reside en convencer a los proveedores de servicios acerca de la necesidad para realizar cambios sobre su infraestructura, ofreciendo como argumento solo datos basados en simulaciones. Este hecho impulsó a crear modelos diferentes. Así, surge la emulación como alternativa, ya que es más objetiva al involucrar en sus experimentos entidades reales y es viable al contar con suficientes recursos como dispositivos y tiempo. Su costo computacional es intermedio entre las simulaciones y los bancos de pruebas (Lubke et al., 2014).
En Patel y Jhaveri (2015) se presenta una plataforma de emulación que permite ejecutar una red virtual de cientos de nodos en una sola máquina de usuario final, enfocándose en un solo tipo de redes. Surgen propuestas de investigación orientadas hacia la creación de emuladores a la medida, como la descrita en Gökturk (2007), que puede convertirse en un problema adicional, ya que se aleja del propósito de esta investigación que propone comprobar la capacidad de emulación para un servicio liviano, cuando se lleva a entornos masivos.
En Álvarez et al. (2010) los autores presentan las técnicas de emulación como una alternativa a emplear, previa a una implementación real, teniendo como escenario de experimentación los servicios de Internet a gran escala. Además, es importante resaltar que la emulación no solo puede usarse en estos entornos como una gran alternativa, sino para servicios no masivos.
NS-3 y OPNET Modeler son las herramientas de emulación de mayor interés sobre la comunidad de investigadores, el principal problema de NS-3 es que no es un producto terminado, ya que por ser de código abierto no garantiza un soporte completo; por su parte, OPNET Modeler requiere una licencia de pago. Con estas herramientas se han desarrollado diversos trabajos en el campo de la emulación. En NS-3, por ejemplo, para redes IPv6 (Álvarez et al., 2010), redes Wimax (Furlong y Guha, 2010) y redes LTE (Molloy et al., 2014). Para OPNET Modeler, Beuran (2012) propone el uso del módulo Software-in-the-Loop en la construcción de modelos, para evitar así la validación de los mismos. En Hassan y Helmy (2014) OPNET Modeler se utilizó para implementar una plataforma de pruebas en tiempo real para el streaming de video móvil mediante el componente SITL, con el fin de evaluar el protocolo de transmisión adaptativa y dinámica sobre HTTP DASH (Dynamic Adaptive Streaming Over HTTP). Para la presente investigación, se amplió el escenario de experimentación, ya que aparte de trabajar con el módulo SITL, se trabajó también con tráfico analítico y explícito.
Finalmente, en el Laboratorio del Grupo de Investigación de Sistemas de Distribución Multimedia DMMS (Multimedia Distribution Systems) de la Universidad de Oviedo, se desarrolló una metodología para la construcción de entornos de emulación, que se empleó como soporte al trabajo presentado (Álvarez et al., 2011). Asimismo, como estudio de caso en este trabajo se presenta un servicio de videochat.
Servicio de videochat
El servicio de videochat se implementó a través de un servicio Web y se diseñó para utilizarse solo por usuarios autorizados. El ancho de banda total que consume el servicio es de 444 Kbps (audio 44 Kbps). El servidor empleado de streaming fue el FMS (Flash Media Server), que obedece a una arquitectura cliente-servidor. La comunicación se hace mediante una conexión persistente, usando el protocolo de mensajería en tiempo real RTMP (Real Time Messaging Protocol). Este protocolo usa TCP a nivel de capa de trasporte y soporta el flujo de streaming del servidor FMS (Campo et al., 2010).
El protocolo RTMP tiene tres variaciones: RTMP simple, que funciona sobre TCP y utiliza el puerto 1935, RTMPT (RTMP Tunneled) que es encapsulado dentro de peticiones HTTP, para atravesar cortafuegos y RTMPS (RTMP Secure) que funciona como RTMP, pero sobre una conexión HTTPS segura; este último fue el que se empleó para esta investigación.
El servicio de videochat consta de tres actores o roles: Un Administrador, quien se encarga de gestionar el servicio, de permitir o restringir el acceso y de controlar el intercambio de información de audio, video o texto entre los diferentes actores. Un Locutor, quien presenta desde un computador una temática a todos los actores, usando una cámara web y un micrófono. Un Cliente, quien recibe el flujo de audio y video. Además de las anteriores funcionalidades, todos los actores pueden intercambiar información entre sí, a través de texto. Para mantener la confidencialidad de los datos y de las transmisiones por la red, todas las comunicaciones entre el servidor y los diferentes actores se realizan empleando comunicaciones seguras a través del protocolo HTTPS.
El Administrador inicia el servicio ingresando a través de una URL en el navegador, que presenta un formulario de validación con usuario y contraseña. Al acceder al servicio se muestra una página donde es posible crear un Locutor y acceder a las URL de los otros dos actores (Figura 1). Una vez que el Administrador habilite el servicio de videochat, el Locutor y el Cliente pueden acceder al servicio mediante las URL correspondientes. El Locutor debe ingresar su usuario y contraseña, mientras que los Clientes ingresan digitando un nombre en el formulario que les presenta el servicio. La emisión de audio y video la inicia el Locutor y con ello el servicio entra en operación.
Caracterización del tráfico
En este apartado se describe el proceso de construcción del modelo de tráfico para el servicio de videochat. Se inicia con las capturas de las trazas de tráfico, a partir de las cuales se identifican las fases y el comportamiento que presenta el servicio. Se continúa con el modelado donde se describe el proceso de obtención de las funciones de distribución de probabilidad PDF (Probability Density Function) y finalmente la validación, donde se muestra que el tráfico generado estadísticamente, permite describir el tráfico real del servicio.
Captura del tráfico
Se inicia con la puesta en funcionamiento de la red real, donde el servicio de videochat se ejecuta sin la red simulada. En este entorno de red se realizan las capturas del tráfico mediante el analizador de protocolos tcpdump, el cual se ejecuta en cada uno de los equipos de los actores. El proceso general del intercambio de información entre los diferentes actores se puede dividir en: fase de conexión, fase de transmisión de datos y fase de desconexión (Figura 2).
La fase de conexión se presenta únicamente al inicio del servicio. El Administrador a través de un navegador ingresa su nombre de usuario y contraseña, posteriormente crea un Locutor y habilita el servicio de videochat. El Locutor y los Clientes acceden al servicio una vez que se encuentre habilitado. En esta fase, el tráfico que se genera entre cada actor y el servidor es del orden de los 6 a los 10 paquetes, con un tamaño promedio de 600 bytes por paquete, donde este tráfico es demasiado pequeño para estudiar el comportamiento estadístico de la red.
La fase de transmisión de datos la inicia el Locutor, quien transmite la información de audio y video hacia el Administrador, que habilita el envío de dicha información a los Clientes. Haciendo un análisis temporal del comportamiento de los datos, se observa que el envío de paquetes se realiza en instantes de tiempo, esto se debe a que el tráfico tiene un comportamiento a ráfagas. En la Figura 3, se verifica este efecto mediante la variación del número de paquetes en función del tiempo. Las ráfagas de tráfico se analizan obteniendo los componentes de cada una de ellas, como son: el tamaño de los paquetes, el tiempo entre los paquetes, el número de paquetes que conforman una ráfaga y el tiempo entre ráfagas.
La fase de desconexión corresponde al intercambio de paquetes por medio de los cuales un actor abandona el servicio. Cualquiera de los actores puede dar por terminada su participación en la sesión de videochat, para esto basta con desconectarse del servicio. Este proceso genera un tráfico menor en número de paquetes y en tamaño, respecto a la fase de conexión.
Modelado de tráfico
En este apartado se describe el proceso de modelado para la fase de transmisión de datos, debido a su mayor complejidad y mayor volumen de tráfico generado. El propósito es llevar el tráfico real hasta el entorno de simulación. Así, a partir de las trazas de tráfico capturadas para la fase de transmisión de datos, se observa que el Locutor inicia la transmisión de la información (Figura 2); el servidor de videochat la recibe y reenvía hacia el Administrador y hacia el Cliente. Además, el Servidor reenvía tráfico hacia el propio Locutor. Todo el tráfico se captura por el analizador de protocolos en forma de series a través del tiempo. La información tabulada en este formato no es de utilidad, por lo que se debe obtener una conducta basada en variabilidad descrita a través de un comportamiento probabilístico.
Para esta investigación se siguieron dos enfoques, el uso de las PDF y el uso de scripts directamente. La caracterización de cada componente de tráfico de la fase de transmisión de datos se realiza mediante una PDF encargada de describir el comportamiento de cada uno de ellos, su validación se realiza a través de la prueba de bondad de ajuste de Kolmogorov-Smirnov (K-S). Los scripts corresponden a los archivos de texto, que contienen los datos de las fases de conexión y desconexión que se obtienen mediante capturas y posteriores filtrados en tcpdump, es decir, son las entradas a la herramienta de simulación.
Así, en la fase de conexión del Administrador donde se envían 6 paquetes, resulta más práctico programar la herramienta mediante dos scripts, uno que entregue 6 valores para el tamaño de los paquetes y otro con 5 valores para el tiempo entre estos, donde no es práctico encontrar una PDF por ser tan pequeño el número de paquetes que se intercambian en esta fase. En contraste, para la fase de transmisión de datos, donde el orden del número de paquetes es de las decenas o centenas por segundo, es más viable encontrar las PDF que describan cada componente de esta fase (Tabla 1).
Existen diferentes PDF que caracterizan el comportamiento de un componente, por ejemplo, el tamaño de los paquetes del Servidor al Cliente, ya que puede describirse mediante una distribución Normal desplazada (media diferente de cero) o una de Weibull (Tabla 1). Como criterio de selección de una distribución sobre otra, se usa el valor estadístico Dn global K-S, que calcula la distancia máxima entre la distribución acumulada de la muestra Fn(x) y la función de distribución que se ajusta al comportamiento de la muestra F(x) (OPNET Modeler, 2010).
Validación del tráfico
Una vez modelado el tráfico para cada una de las fases del servicio, a través de las diferentes PDF y scripts, los componentes de las fases deben programarse como parámetros de entrada a la herramienta de simulación, obteniendo así un escenario basado en tráfico explícito.
Para validar este modelo, se crean escenarios básicos para cada pareja de actores de la Tabla 1, por ejemplo, un escenario básico entre el Locutor y el Servidor de videochat, consta de un computador, al cual se le asigna el nombre de Locutor, un router o un switch y un servidor. Con el Locutor, es necesario cargar cada uno de los scripts de las fases de conexión y desconexión, además de los parámetros definidos por las diferentes PDF en la fase de Transmisión de Datos (columnas 2 y 5 de la Tabla 1). Es necesario configurar el servidor de videochat con las capacidades para enviar y recibir datos hacia y desde el Locutor.
Una vez configurado el escenario básico, se capturan las trazas de tráfico generadas en la herramienta de simulación y se analizan mediante las pruebas de bondad y ajuste K-S, que permiten obtener las PDF de cada parámetro. Finalmente se compara estadísticamente el tráfico real generado por el servicio de videochat, con el generado por la herramienta de simulación. Un escenario construido de esta forma corresponde a un modelo de simulación por eventos discretos basado en tráfico explícito.
En la Figura 4, se presentan los histogramas del tráfico real con la distribución teórica que mejor se ajusta a su forma. De los 16 casos que contiene la Tabla 1, se eligieron a modo de ilustración, 4 diferentes (uno por cada parámetro).
En la Figura 5a, se presenta la función de distribución acumulada (CDF) para la validación del tamaño de los paquetes del Locutor al servidor, comparando valores simulados con los valores reales. En la Figura 5b, se presentan las diferencias absolutas, el valor máximo y promedio de estas diferencias entre las mismas CDF, como sustento adicional al estadístico Dn, cuyo valor es de 0.04 (Tabla 1), de la confiabilidad del proceso de validación, ya que de acuerdo con la Tabla 1, el tamaño de los paquetes siguen una distribución normal desplazada con una media de 997.23 y una desviación estándar de σ = 209.83.
Entorno de experimentación
A continuación se describe la maqueta utilizada para el desarrollo de esta investigación. Se muestra el plano de la red real, el plano de la red simulada y el proceso de interacción entre los dos planos de la maqueta. En la Figura 6, se observa el diagrama del entorno de experimentación empleado, que consta de dos planos denominados Red Real o plano uno y Red Simulada o plano dos.
Plano de la red real
El plano uno de la Figura 6, contiene los computadores reales del servicio asociados a cada actor del servicio de videochat. El computador llamado Locutor, se debe dotar con una cámara web y un micrófono, que le permita a un ponente emitir su conferencia.
El servidor de Videochat_R que aloja al FMS, corresponde a un equipo con 750 megabytes de memoria, un procesador a 3 GHz y sistema operativo Ubuntu Release 8.04. Los equipos para cada uno de los actores corresponden a computadores dotados de un navegador y un cliente flash.
El equipo Dell PoweEdge r410 que se observa en el plano uno de la Figura 6, corresponde a un servidor de rack, llamado Eleanor, con 16 gigabytes de memoria y un procesador a 2.1 GHz. Este equipo cuenta con un sistema operativo Red Hat Enterprise Linux Server Release 5.4, dotado de 6 tarjetas de red Fast Ethernet. Su función es hacer de router entre las diferentes interfaces de red y alojar la herramienta de simulación, con la cual se construyó la red simulada del plano dos de la maqueta de la Figura 6.
Plano de la red simulada
La red simulada se conforma por la red troncal, que consta de 4 routers con enlaces que soportan 100 Mbps, computadores que representan los dispositivos del servicio, el servidor de videochat y módulos software SITL. Los módulos SITL se usan para la conexión con el hardware externo, conectan un dispositivo de la red simulada con un dispositivo de la red real a través de una conexión IP. Por lo tanto, este módulo permite entregar paquetes simulados a dispositivos reales y paquetes reales a los dispositivos simulados, dichos módulos toman el tráfico generado por los dispositivos de computo reales del plano uno y permiten que circule dicho tráfico por la red simulada o plano dos. Por ejemplo, si desde el Locutor se envía información hacia el Administrador_R (ver la línea punteada en la Figura 6), el proceso es el siguiente: los paquetes con la información de audio, video o texto, circularán desde el Locutor hasta la interfaz de red Eth2 del servidor Eleanor en el plano uno, dichos paquetes se toman por el módulo SITL_5 del plano dos y se envían al router 4 (R4), en donde, de acuerdo con la tabla de direccionamiento de red, los paquetes se envian hasta el router 3 (R3), para luego entregarse a la interfaz SITL_4, que entrega el tráfico a la interfaz de red Eth3 del servidor Eleanor. Finalmente dicha información llega hasta su destino, es decir, el Administrador_R. De esta forma, el tráfico real fluye a través de la red simulada antes de alcanzar su destino.
Escenarios de evaluación
La red virtual se construye partiendo de un escenario básico, el cual se conforma por un router con dos módulos SITL, que permiten el acceso al servidor de videochat y al Administrador, obteniendo un escenario virtual con tráfico real. Obsérvese que para esta sección no se tiene en cuenta el tráfico explícito caracterizado. Así, lo que se obtiene es una topología de red virtual sobre la cual se inyecta tráfico real.
Teniendo en cuenta el direccionamiento de la red, se crea el escenario de emulación completo, haciendo que los dos planos de la maqueta del Laboratorio interactúen entre sí. Además, para este escenario se adicionan cargas de tráfico sobre los enlaces mediante tráfico background. Así, este escenario de emulación contiene una red virtual, tráfico explícito cargado sobre elementos simulados, tráfico real que parte desde y llega hasta dispositivos reales a través de la red virtual, y tráfico analítico.
Los escenarios de evaluación están conformados como se muestra en la Tabla 2. El tráfico del escenario 1 está constituido únicamente por el tráfico explicito, es decir, solo contiene el plano dos de la Figura 6. El escenario 2 por su parte, está formado únicamente por el tráfico real del plano uno que fluye sobre el plano dos de la Figura 6. Los demás escenarios incluyen tráfico real más tráfico explícito. Los escenarios del 7 al 10 corresponden al escenario 5 más tráfico mixto de 75 Mbps, el cual se carga a nivel de la capa IP entre el servidor de videochat y un Cliente.
Resultados
Análisis y monitorización de prestaciones
La emulación exige un gran procesamiento de datos en tiempo real. Por ello, una de las limitaciones con las que se encuentra la comunidad científica para realizar emulación de servicios, son las altas capacidades de cómputo exigidas. A continuación se presentan los datos para el servidor que soporta la herramienta de simulación. En la Figura 7, se muestra una gráfica con el número de eventos generados versus el porcentaje de uso de la CPU. Los números sobre la curva corresponden a los escenarios de pruebas.
El tráfico real (escenario dos) genera un mayor número de eventos que su modelo equivalente con tráfico explícito (escenario uno). El número de eventos por segundo y el consumo de la CPU generados en el escenario tres, corresponden aproximadamente a la suma de los valores correspondientes (eventos y CPU) de los escenarios uno y dos. Los escenarios cuatro, cinco y seis, prácticamente generan el mismo número de eventos, mientras que el consumo de la CPU se incrementa en unas pocas centésimas, a pesar de que la complejidad de los escenarios ha aumentado en número de Clientes simulados. Incluso el escenario seis contiene trafico backgraound con 75% de ocupación sobre el backbone de la red simulada.
En los escenarios 7 a 10 se observa que al aumentar el tráfico mixto paquete a paquete, se incrementa el número de eventos por segundo, lo que a su vez, incrementa el porcentaje de uso de la CPU. Para valores superiores a 30% del tráfico paquete a paquete (cuyo tamaño de los paquetes es el de la MTU de Ethernet), el uso de la CPU es superior a 85%. Con estos valores el proceso de emulación no se ejecuta en tiempo real.
Respecto al uso de memoria, el proceso de emulación consume valores entre 0.37% para el escenario uno, hasta 0.65% para el escenario diez, los cuales no son valores críticos. De acuerdo con el anterior análisis, el consumo de CPU del equipo es un factor a tener en cuenta en los procesos de emulación.
Análisis del comportamiento del modelo
Una vez validado el modelo, su propósito es el de estudiar el tráfico que inyecta en la red el servicio en funcionamiento para poder medir el impacto que tendría su implantación sobre una red de comunicaciones. El estudio del tráfico se realizó bajo diferentes escenarios. No se observó ningún parámetro que afectara el servicio de manera directa. Una razón es que la red virtual está sobredimensionada para este tipo de servicios, con bajo requerimiento de ancho de banda.
No se observa jitter ni pérdida de paquetes sobre el servicio real. El retardo de los paquetes reales, extremo a extremo sobre la red virtual es del orden de 1 ms. Los tiempos de conversión de tráfico real a simulado son del orden de los 11 µs. Los tiempos de conversión de tráfico simulado a real, son del orden de los 7 µs. Así este proceso de conversión que se muestra en los módulos SITL, no tiene un impacto importante sobre los retardos que puedan sufrir los paquetes.
Respecto al tráfico mixto es de carácter homogéneo, esto es, ofrece siempre la misma carga de tráfico especificado en la Tabla 2, para este tráfico se obtuvieron las siguientes medidas: el valor medio de la latencia entre la creación de los paquetes y la recepción en el nodo destino es de 2 ms. El jitter es de 0.43 ms para el escenario 7, hasta alcanzar los 0.7 ms para el escenario 10. Los anteriores valores son lo suficientemente pequeños, ya que no tienen un impacto sobre el tráfico mixto y tampoco se observa que afecten el tráfico real del servicio de videochat.
Al agregar tráfico mixto sobre el modelo, se genera un incremento del throughput desde el servidor de videochat hacia los clientes. En la Figura 8a, se observa el tráfico generado para los escenarios sin tráfico mixto. En la Figura 8b, se observa el incremento de magnitud del throughput al incluir el tráfico mixto sobre los escenarios respectivos.
Se realizó un escenario 11, en el cual se congestionó 100% el anillo de la red virtual mediante tráfico background. Se observó que el servicio de videochat continuaba en funcionamiento a través de la red virtual, aunque su calidad percibida se iba degradando. Al analizar las trazas de tráfico para este experimento, se observa que el throughput sobre los módulos SITL y para el tráfico explicito intercambiado entre los actores simulados se redujo 10 veces respecto a los otros experimentos. En la Figura 9, se observa este comportamiento.
De acuerdo con lo presentado en esta sección se observa que la emulación es una opción capaz de obtener el comportamiento de un servicio multimedia teniendo en cuenta las características reales de este. Por lo tanto, para la emulación es transparente si existe o no dependencia de rango corto o rango largo de los modelos analíticos, lo cual permite un dimensionamiento sin trabajar con supuestos y poniendo a correr los servicios de manera real. Además, este enfoque es útil para las empresas, ya que en el momento de argumentar las necesidades de expansión o dimensionamiento de las redes, mediante la emulación, se puede ver una réplica a escala donde es posible modificar parámetros antes de realizar las implementaciones en la red real, es decir, los ingenieros de tráfico pueden ver funcionando el servicio emulado de manera real, se podría decir que es un modelo funcional, que puede evitar contrastar contra otros modelos, pues los servicios se ponen en funcionamiento.
Por otra parte, todo el proceso descrito se puede extender a otro tipo de redes y servicios, donde el insumo de esta investigación es el modelo estadístico, que se obtuvo a través de las capturas reales de tráfico, sin recurrir a funciones supuestas. De esta forma, si lo que se desea es modificar el modelo es necesario realizar nuevamente el proceso de caracterización del tráfico que se desee modelar. Ahora bien, si lo que se desea es estudiar el comportamiento de protocolos, se puede recurrir a las PDF largamente estudiadas y publicadas por los investigadores.
Conclusiones y trabajos futuros
Este artículo provee una descripción del proceso de modelado de tráfico para un servicio multimedia usando como estudio de caso el servicio de videochat, el cual presenta como característica un comportamiento a ráfagas. El modelo involucra la obtención del modelo estadístico y la construcción de la plataforma de emulación que permite que el tráfico del servicio se difunda a través de redes virtuales y reales.
Unificando los modos de actuación de los tráficos explícito, real y background de forma concurrente, se obtiene un escenario completo capaz de generar un modelo de tráfico para un servicio de videochat. El proceso se puede extender a otro tipo de redes y servicios.
Los entornos de emulación donde se trabaja con tráfico real soportado sobre una red virtual, permiten crear escenarios más completos y complejos, sin requerir de toda una infraestructura de red.
De acuerdo con el análisis de resultados, el tráfico mixto construido a partir del tráfico real y del tráfico explícito, como generador de carga, permite simular el comportamiento de un número elevado de clientes orientado hacia servicios masivos. Este es un parámetro que se debe monitorear, ya que el exceso de tráfico mixto paquete a paquete, genera un elevado consumo de CPU de la máquina donde se lleva a cabo la emulación, teniendo como consecuencia la ejecución del modelo en tiempos mayores al tiempo real, invalidando así los resultados del modelo.
El tráfico background no genera un aumento en el número de eventos, por lo que las capacidades de procesamiento se mantienen. Pero es necesario crear escenarios de referencia que permitan analizar el comportamiento del modelo y así obtener resultados correctos.
Para que los resultados no pierdan validez, se debe tener en cuenta tanto la correcta generación de tráfico explícito, como las capacidades de procesamiento de la máquina que soporta la emulación.
Como trabajos futuros se plantea investigar la emulación combinando servicios de alta calidad, con servicios de menor calidad o livianos, de tal manera que se pueda analizar cuál es el efecto de los unos sobre los otros. Así, es posible realizar estudios en entornos con múltiples servicios que permitan el análisis de diferentes parámetros de red y su impacto sobre los servicios. Además, se puede extender el proceso de modelado a otro tipo de redes como la redes de cable o las redes inalámbricas, o utilizar la emulación para el estudio de las métricas de calidad del servicio y calidad de la experiencia.
