Desarrollo de una metodología para el desarrollo de herramientas de medición de desempeño
94
0
0
Texto completo
(2) Desarrollo de una metodologı́a para el desarrollo de herramientas de medición de desempeño. Aprobado por:. Néstor Peña Traslaviña, Asesor. Fecha de Aprobación.
(3) IEMC-I-06-14. A Dios, A mi hijo, Juan Diego, quien es mi alegrı́a A mi esposo, Alejandro, por su paciencia y apoyo A mis padres, Francisco y Marı́a del Carmen, por su ayuda incondicional.. iii.
(4) IEMC-I-06-14. Prefacio. Establecer mecanismos que permitan el máximo aprovechamiento de los recursos de la red, diseñar sistemas de monitoreo eficientes a diversos niveles de escala temporal y agrupar esto en modelos de control de congestión capaces de brindar la mejor calidad del servicio al cliente, son algunos de los desafı́os impuestos a los desarrolladores de aplicaciones de equipos y programas para Internet [1]. Para las etapas de diseño y prueba de tales desarrollos, se requiere una infraestructura que permita recrear escenarios para la puesta en marcha de experimentos controlables y reproducibles. Esto implicarı́a contar no sólo con las instalaciones y equipos de la red, sino además con usuarios dispuestos a participar en diversos experimentos. Por razones de ı́ndole logı́stica, económica, por seguridad, entre otras, es imposible conducir un experimento repetitivo con tales caracterı́sticas. Esta situación, es la que motiva la generación de cargas de tráfico de manera sintética. Existen diferentes metodologı́as para la generación de cargas representativas de tráfico, en particular, esta investigación se basa en la generación de tráfico de usuarios equivalentes[2] [3] [4] [5]. Dada la evidencia de que algunas variables relacionadas con el tráfico de Internet no obedecen a los modelos de tráfico clásico [6] [7], la fuente de tráfico implementada reproduce la actividad de un usuario de internet real, el cual puede ser ajustado a. iv.
(5) IEMC-I-06-14 las condiciones particulares de una red por medio de la medición del tráfico de los usuarios reales. En el capı́tulo final del documento, se muestra como la fuente de tráfico se somete a una serie de pruebas para determinar su equivalencia con el tráfico que genera un usuario real, en términos de autosimilaridad y dependencia a largo plazo (LRD). Posteriormente, la verificación se realiza sobre fuentes de tráfico agregadas, y se evalúa la capacidad de los algoritmos implementados, para reproducir tráfico con las caracterı́sticas reportadas por Downey [8]. Finalmente, se muestra como la infraestructura tiene un impacto importante en la evaluación y desarrollo de medidores de desempeño, mostrando el caso particular de las medidas relacionadas con el ancho de banda.. v.
(6) IEMC-I-06-14. Reconocimientos. Agradezco a Néstor Peña Traslaviña, mi asesor, por su guı́a y la confianza depositada. También agradezco a la Universidad de los Andes y en especial a los directivos y personal del Departamento de Ingenierı́a Eléctrica y Electrónica por facilitar sus instalaciones, recursos y el apoyo necesario durante el curso de mis estudios. También quiero manifestar mi agradecimiento a la DTI (Dirección de tecnologı́as e Informática) y al MOX (Dirección de servidores) de la Universidad de los Andes, por la asesorı́a brindada y por facilitar información a cerca del tráfico de la red Uniandes. A los coordinadores de los Laboratorios de Eléctrica y Electrónica (Departamento de Ingenierı́a Eléctrica y Electrónica) y de Redes (Departamento de Ingenierı́a de Sistemas y Computación) de la Universidad de los Andes, por su gran colaboración respecto a las facilidades de infraestructura y equipos que muy amablemente pusieron a disposición, para el desarrollo de la presente investigación.. vi.
(7) IEMC-I-06-14. Tabla de Contenido Dedicatoria. III. Prefacio. IV. Reconocimientos. VI. Lista de Tablas. IX. Lista de Figuras. XI. Resumen I.. XIII. Estado del arte. 1. 1.1. Medición de tráfico . . . . . . . . . . . . . . . . . . . . . . . . . . .. 1. 1.2. Modelamiento y caracterización de tráfico de Internet . . . . . . . .. 4. 1.2.1. Definición de autosimilaridad . . . . . . . . . . . . . . . . . .. 7. 1.2.2. Distribuciones con cola pesada . . . . . . . . . . . . . . . . .. 8. 1.3. Generadores de tráfico . . . . . . . . . . . . . . . . . . . . . . . . . .. 9. 1.3.1. Mah [3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.3.2. Choi y Limb [2] . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.3.3. Barford y Crovella [5] . . . . . . . . . . . . . . . . . . . . . . 15 1.3.4. Heegard [9] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.3.5. Deng [4] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.3.6. Influencia de la autosimilaridad en el desempeño de la red . . 17 II. Caracterización de tráfico HTTP 2.1. Caracterización de un usuario 2.1.1. Volumen de tráfico. 19. . . . . . . . . . . . . . . . . . . . . . 24. . . . . . . . . . . . . . . . . . . . . . . . 25. vii.
(8) IEMC-I-06-14 2.1.2. Tiempo entre llegadas de paquetes . . . . . . . . . . . . . . . 27 2.2. Caracterización de la red Uniandes . . . . . . . . . . . . . . . . . . . 30 2.2.1. Volumen de tráfico. . . . . . . . . . . . . . . . . . . . . . . . 30. 2.2.2. Tiempo entre paquetes . . . . . . . . . . . . . . . . . . . . . 32 2.3. Tráfico de fondo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 III. Implementación de una fuente de tráfico HTTP. 36. 3.1. Herramientas de Software para construir aplicaciones de red . . . . . 36 3.2. Algoritmo para construir un usuario equivalente (UE) . . . . . . . . 37 3.2.1. Implementación de las variables del modelo . . . . . . . . . . 41 3.3. Múltiples usuarios UE . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.4. Red de prueba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 IV. Implementación de diversos experimentos usando usuarios equivalentes en ambientes controlados 55 4.1. Evaluación de una fuente de tráfico sintética implementada con el algoritmo UE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.2. Evaluación de la agregación de múltiples fuentes de tráfico implementadas con el algoritmo UE . . . . . . . . . . . . . . . . . . . . . 57 4.3. Efecto del multiprocesamiento sobre el tráfico generado por múltiples fuentes UE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.4. Evaluación de la intrusividad en la medición de ancho de banda disponible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 V. Conclusiones y recomendaciones. 68. Apéndice A.. — Métodos para el cálculo del parámetro de Hurst. 71. Apéndice B.. — Documentación electrónica adicional. 77. Referencias. 78. Vita. 81. viii.
(9) IEMC-I-06-14. Lista de Tablas 1.. Estándares relacionados con la medición del tráfico de Internet . . . .. 2.. Parámetros del modelo propuesto por Choi y Limb . . . . . . . . . . 14. 3.. Parámetros del modelo propuesto por Barford y Crovella . . . . . . . 16. 4.. Resultados de las medidas de tráfico realizadas a un usuario real de Internet (Enero 2006). . . . . . . . . . . . . . . . . . . . . . . . . . . 25. 5.. Resumen de las estadı́sticas para el volumen de tráfico generado por de un usuario de Internet real. . . . . . . . . . . . . . . . . . . . . . . 28. 6.. Resumen de las estadı́sticas para el tiempo entre paquetes del tráfico de un usuario de Internet. . . . . . . . . . . . . . . . . . . . . . . . . 28. 7.. Resumen de las estadı́sticas para el volumen de tráfico de la red Uniandes (Mayo de 2004). . . . . . . . . . . . . . . . . . . . . . . . . 32. 8.. Cuadro comparativo de las estadı́sticas del tráfico de fondo real y el sintético . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35. 9.. Relación de las variables que hacen parte de un modelo para producir tráfico representativo, basado en el comportamiento de un usuario de Internet. Se incluye la información de la distribución empleada, media, varianza y autor de referencia. . . . . . . . . . . . . . . . . . . 39. 10.. Cálculo de la correlación entre conjuntos de números aleatorios generados por el algoritmo implementado. . . . . . . . . . . . . . . . . . 43. 11.. Cálculo del coeficiente de correlación entre conjuntos de números aleatorios generados por el algoritmo implementado. . . . . . . . . . . 43. 12.. Función de probabilidad acumulada empı́rica para datos con distribución Gamma(0.6,1349). . . . . . . . . . . . . . . . . . . . . . . . . . . 47. 13.. Cuadro comparativo de las variables analizadas para el caso de un usuario real (UR) descrito en el capı́tulo 2 y un usuario equivalente (UE), generado con el algoritmo propuesto en el capı́tulo 3. . . . . . . 56. ix. 3.
(10) IEMC-I-06-14 14.. Cuadro comparativo del volumen de tráfico generado por un usuario real (UR), vs. un usuario equivalente (UE) para una agregación en el tiempo de 1, 10, 100 y 1000ms. . . . . . . . . . . . . . . . . . . . . . 56. 15.. Resultados de la estimación del parámetro de Hurst por los métodos descritos en el Apéndice A: (1) R/S, (2) Varianza de procesos agregados y (3) aproximación al ruido fraccional gaussiano; aplicados al tráfico producido por cuatro usuarios equivalentes. . . . . . . . . . . . 57. 16.. Cuadro comparativo de la ejecución de múltiples usuarios usando multiprocesamiento y múltiples usuarios usando múltiples procesadores. 63. x.
(11) IEMC-I-06-14. Lista de Figuras 1.. Escenario de medición del tráfico producido por un usuario de Internet de la sala de asistentes graduados del Departamento de Ingenierı́a Eléctrica y Electrónica de la Universidad de los Andes. . . . . . . . . 20. 2.. Diagrama de flujo para la reducción y análisis de información . . . . . 23. 3.. Parámetro de Hurst obtenido por: (a) Método de la varianza (b) Método R/S, aplicados al volumen de tráfico producido por un usuario de Internet real. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26. 4.. Coeficientes de correlación para el volumen de tráfico producido por un usuario de Internet real. . . . . . . . . . . . . . . . . . . . . . . . 27. 5.. Prueba log-log de la CCDF para varios niveles de agregación del tiempo entre llegadas de paquetes http del tráfico generado por un usuario de Internet real. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29. 6.. Volumen de tráfico para la red Uniandes (Mayo de 2004). (a) 15 minutos de tráfico, vistos con una precisión de 1s. (b) 100 segundos de tráfico vistos con una precisión de 0.1s (c) 10 segundos de tráfico vistos con una precisión de 0.01s. . . . . . . . . . . . . . . . . . . . . 31. 7.. Ajuste de las variables, tiempo entre paquetes (a) y tamaño del paquete (b) para el tráfico que no es HTTP, presente en la traza capturada de la red Uniandes (Mayo de 2004) . . . . . . . . . . . . . . . . . . . 34. 8.. Diagrama de flujo para una fuente de tráfico sintético basada en el comportamiento de un usuario de Internet. . . . . . . . . . . . . . . . 40. 9.. Función de distribución acumulada para los datos producidos por el generador de números Weibull(81.4,0.9), para la variable Tiempo ON del algoritmo UE comparados con números con la misma distribución generados por MathLab . . . . . . . . . . . . . . . . . . . . . . . . . 44. 10.. Función de distribución acumulada complementada para los datos producidos por el generador de números Pareto (0.9,60), para la variable Tiempo OFF del algoritmo UE. . . . . . . . . . . . . . . . . . . 45. xi.
(12) IEMC-I-06-14 11.. Función de distribución acumulada complementada para el tiempo entre solicitudes Web. De la figura se nota como para obtener tiempos medios entre solicitudes de 5s, se requiere ajustar el generador de números aleatorios a una Weibull(0.45,0.54) . . . . . . . . . . . . . . 46. 12.. Contenidos de la carpeta HTTP del servidor Apache. . . . . . . . . . 49. 13.. Función de distribución acumulada complementada para el tamaño de los objetos HTML a solicitar. Los números aleatorios obedecen a una distribución Log Normal(1.8,1) y fueron obtenidos con un generador basado en una función de distribución acumulada empı́rica. . . . . . . 50. 14.. Algoritmo para múltiples usuarios UE (Usuarios Equivalentes). . . . . 51. 15.. Efecto de los tiempos entre usuario sobre el volumen de tráfico generado. 52. 16.. Configuración de la red de prueba implementada en las instalaciones del Laboratorio de redes del Departamento de Ingenierı́a de Sistemas y Computación de la Universidad de los Andes. Los equipos designados como Generadores HTTP, corren el algoritmo implementado para el usuario equivalente (UE). . . . . . . . . . . . . . . . . . . . . 53. 17.. Volumen de tráfico para 4 UE (a) 16 minutos de tráfico, vistos con una precisión de 1 s. (b) 100 segundos de tráfico vistos con una precisión de 0.1 s (c) 10 segundos de tráfico vistos con una precisión de 0.01 s.. 58. 18.. Auto correlación del proceso de bytes por unidad de tiempo, para cuatro Usuarios Equivalentes. Los datos corresponden a una traza de 1 hora de duración. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60. 19.. Diagrama CCDF (Distribución de probabilidad acumulada complementada) para el tiempo entre llegadas de paquetes del tráfico generado por cuatro usuarios equivalentes. . . . . . . . . . . . . . . . . . 61. 20.. Diagrama CCDF (Distribución de probabilidad acumulada complementada) para el tamaño de los archivos solicitados por cuatro usuarios equivalentes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61. 21.. Mediciones de ancho de banda usando Pathload. (a) Medida bajo condiciones de bajo tráfico. Pathload arroja como resultado un ancho de banda disponible de entre 8.84 y 8.9Mbps en un enlace de 10Mbps. (b) Medida bajo condiciones de alto tráfico. Pathload reporta que el ancho de banda disponible es de 0 Mbps. . . . . . . . . . . . . . . . . 66. xii.
(13) IEMC-I-06-14. Resumen. En este documento se ilustra el proceso de implementación de una infraestructura para la reproducción de escenarios con cargas de tráfico representativas en aras de facilitar la experimentación en el desarrollo de sistemas de medición de desempeño y de control de redes corporativas. La infraestructura desarrollada consiste de un conjunto de herramientas de análisis, un generador de tráfico HTTP, una red de prueba y un proceso metodológico para la caracterización de tráfico autosimilar. Una serie de experimentos, permite verificar que la infraestructura implementada presenta un tráfico con las caracterı́sticas de autosimilaridad y dependencia a largo plazo que señalan los trabajos de medición sobre redes reales realizados y reportados en la literatura técnica.. xiii.
(14) IEMC-I-06-14. Capı́tulo I. Estado del arte A continuación, se resume parte del trabajo investigativo de las últimas décadas, que ha permitido conocer más del comportamiento de la red Internet y se concluye con una proyección de lo que deberı́a ser el trabajo a futuro en el mejoramiento del desempeño de la red.. 1.1.. Medición de tráfico. La experiencia de medición, ha constituido la columna vertebral de la mayorı́a de los trabajos en busca de establecer modelos para el tráfico de Internet [10][3][2][4][11]. Esto se debe a que partir de una concepción meramente analı́tica se pueden obviar muchos de los factores de influencia en el comportamiento del tráfico real. Dentro de los autores consultados, se tiene registro de la existencia de trabajos de medición desde finales la década de los 80, y a pesar de que son ya más de 15 años de trabajo, no se puede decir que todo está hecho en este campo. El trabajo de medición es un trabajo que ha estado limitado por razones tecnológicas, de infraestructura y de seguridad, lo que ha impedido que a hoy no se posea un conjunto de trazas lo suficientemente representativas como para establecer una clara tendencia en el tráfico. A pesar de los esfuerzos de grupos como MAWI [12] e ITA [13], las trazas disponibles. 1.
(15) IEMC-I-06-14 no cumplen con muchas de las expectativas del investigador. Por ejemplo, en MAWI se tienen trazas de servidores a nivel mundial, discriminadas por año, dı́a y hora. Cada traza tiene 15 minutos de tráfico y luego de hacer un filtro, se tiene que no posee ni una solicitud Web, y además, luego de hacer un análisis de volumen de tráfico, se obtiene una tendencia muy determinı́stica, que no cumple con las expectativas de un tráfico totalmente impredecible como el que se esperaba. No se sabe si todas las trazas tienen la misma caracterı́stica, no obstante y debido a que este proceso podrı́a tomar dias e incluso meses, no resulta muy atractivo utilizar este tipo de trazas. Respecto de las trazas ITA, se tiene que son trazas que han sufrido una reducción substancial la mayorı́a de las trazas apenas contienen una marca de tiempo con precisión de segundos y la cantidad de bytes para cada paquete. Esta información resulta insuficiente para los propósitos de esta investigación, cuando se quiere determinar, por ejemplo, el número de solicitudes HTTP por unidad de tiempo, pues los encabezados de los paquetes han sido omitidos. Con base en lo anterior, se hace evidente la necesidad de medir el tráfico, para esto, la herramienta más popular es tcpdump [14] un poderoso software de captura de paquetes que usa la librerı́a libpcap [14]. Tcpdump es un programa de libre distribución desarrollado en Lawrence Berkeley Laboratory, de la Universidad de California por: Van Jacobson, Craig Leres, y Steven McCanne. Fue diseñado originalmente para analizar los problemas de desempeño de TCP/IP y hoy en dı́a es el más popular en el área con un sin número de aplicaciones. Otras herramientas desarrolladas para capturar y filtrar tráfico son: Analyzer, Argus, Cflowd, Ethereal, NetraMet, PasTmon, Snoop, Snuffle, Natas, Netflow, Packetsizer, tcptrace, tcpshow, tcppurify, tcpdpriv, flstats, entre otras, las cuales pueden ser obtenidas de la página web de CAIDA (The Cooperative Association for Internet Data análisis)[15].. 2.
(16) IEMC-I-06-14 1.1.0.1. Medición de desempeño Existe una manifiesta dificultad no solo en establecer las métricas del desempeño, sino en el establecimiento de las metodologı́as para su medición. Dada esta necesidad, nace en 1998, el capı́tulo IPPM (Internet Protocol Performance Metrics), dedicado a la búsqueda de respuestas en el campo del desempeño de redes de Internet. En la tabla 1 se listan los números publicados (RFC=Request for comments) [16] hasta el momento en el área de la medición de tráfico de Internet: RFC RFC2330 RFC4148 RFC2678 RFC2679 RFC2680 RFC2681 RFC3148 RFC3357 RFC3393 RFC3432. TEMA Metodologı́a general para las mediciones de desempeño IP IPPM, lineamientos para el registro de métricas IP Métricas IPPM, para la medición de conectividad Métrica IPPM, para la medición del retardo en un sentido Métrica IPPM, para la medición de la pérdida en un sentido Métrica IPPM, para le medición del retardo de ida y vuelta Metodologı́a para mediciones de capacidad de transferencia Métricas para el muestreo de patrones de pérdida Métrica IPPM, de la variación del retardo de paquetes IP Medidas de desempeño de la red para flujos periódicos. AÑO 1998 2005 1999 1999 1999 1999 2001 2002 2002 2002. Tabla 1: Estándares relacionados con la medición del tráfico de Internet Las mediciones de desempeño, según la clasificación publicada en la RFC2330, pueden ser:. Formales o analı́ticas: son aquellas que pueden expresarse de manera abstracta y matemática, como: el tiempo de propagación, el tiempo de transmisión. El ancho de banda del enlace, el ancho de banda de la red, el ancho de banda del cuello de botella, la ruta instantánea de un enlace, el contador de nodos de un enlace, el tamaño del buffer, el tamaño instantáneo de la cola, la máxima capacidad de la red, el parámetro de Hurst instantáneo, la conectividad, el jitter, la disponibilidad de la. 3.
(17) IEMC-I-06-14 red, la utilización, el tiempo en que se envı́a y retorna un NOC (manejo de fallos), tiempo de propagación de un enlace, el ancho de banda de un enlace para paquetes de un tamaño determinado, etc.. Medidas empı́ricas: son aquellas que requieren de un proceso metodológico e involucran una o más medidas formales, como por ejemplo, la medición de la mejor capacidad de flujo alcanzable mientras se observa el control de congestión de TCP. En la RFC2330[17], también se enuncian las caracterı́sticas necesarias para validar una medición de desempeño, las cuales se listan a continuación: Concreción y buena definición. Repetible, bajo circunstancias similares en aras de obtener los mismos resultados. Exhibir una tendencia cuando se aplica a redes con la misma tecnologı́a. La métrica debe ser útil a los usuarios y a los proveedores para entender el nivel de desempeño que ellos experimentan o proveen.. 1.2.. Modelamiento y caracterización de tráfico de Internet. Tradicionalmente, los modelos poissonianos han permitido describir diversos tipos de tráfico, no obstante cuando se habla de tráfico de paquetes en Internet, se ha podido comprobar que dichos modelos fallan. Paxon [6], hace alusión a este fenómeno en su estudio de trazas TCP basado en 24 trazas de 2 horas de duración cada una, en el cual analiza el tiempo entre el establecimiento de las conexiones de diversos protocolos y llega a determinar que solo las aplicaciones de TELNET y FTP, se ajustan al modelo poissoniano homogéneo. Para otras aplicaciones, como las 4.
(18) IEMC-I-06-14 conexiones TCP y HTTP, el modelo falla y resulta en medidas de desempeño como el retardo y el tamaño de buffer muy poco fiables. Respecto de esta conclusión, se da a la tarea de sugerir un modelo que logre ser tan impredecible como el tráfico real el cual a diferencia de los modelos clásicos no solo debe reproducir una caracterı́stica de dependencia a corto plazo (SRD)1 sino, además, una dependencia a largo plazo (LRD)2 . Como un resultado notable, se llega a que los tiempos entre llegadas de paquetes se ajustan mejor a una distribución Pareto en lugar de una exponencial y sugiere el modelo M/G/∞ como un modelo que puede reflejar las caracterı́sticas de este tipo de tráfico. Otro estudio importante, es el Willinger [18], quien por medio de la medición de tráfico en una red LAN, llega a demostrar que el tráfico de Internet se comporta como un proceso asintóticamente autosimilar de segundo orden como se explicará mas adelante. Otros modelos aplicados al tráfico de Internet, son reseñados en el trabajo de Ma y Ji [19]:. Modelos basados en cadenas de Markov: Estos modelos se ajustan bien hasta cierto punto, ya que modelan procesos de corta dependencia. No obstante, cuando el tráfico empieza a exhibir caracterı́sticas acentuadas de larga dependencia, los modelos se vuelven muy complicados de parametrizar. 1. Dependencia a corto plazo (SRD): Los valores posibles del proceso corresponden a un proceso sin memoria (variables con distribución exponencial) y la suma de los coeficientes de correlación del procesos resultan en una cantidad finita: r(k) < ∞ 2 Dependencia a largo plazo (LRD): la función de correlación del proceso se puede aproximar a r(k) = k −β donde, 0 < β < 1, lo que implica un fenómeno de persistencia, esto es, el fenómeno estadı́stico presenta valores muy grandes o muy pequeños de manera consecutiva. Las variables aleatorias con dependencia a largo plazo, se caracterizan porque los coeficientes de correlación no se pueden sumar, y por tanto r(k) → ∞. 5.
(19) IEMC-I-06-14 Modelos basados en el ruido fraccional gaussiano (FGN): Tienen la ventaja de representar muy bien la larga dependencia (LRD) del tráfico IP, pero son incapaces de modelar la dependencia a corto plazo (SRD).. Modelos basados en la escena (para el caso de estudio de VBR) o en la conexión (tráfico IP): como los modelos MMPP, FARIMA o M/G/∞ . Logran describir muy bien las dos dependencias SLD y LRD y realmente reflejan el comportamiento fı́sico de las tramas. No obstante, el MMPP requiere que se elija un segmento de tráfico que represente lo mejor posible las estadı́sticas del tráfico total (lo cual es muy difı́cil de conseguir); FARIMA, tiene el problema del alto costo computacional y M/G/∞ resulta atractivo, pero no se han podido generar altos volúmenes de tráfico sintético usando este modelo.. Modelos no gaussianos: utilizan funciones de densidad de probabilidad con cola pesada como la función Pareto. Son modelos basados en ajuste estadı́stico que permiten predecir con buena precisión la probabilidad de overflow del buffer. Su mayor desventaja es que no tienen en cuenta los factores de escala y se basan únicamente en las estadı́sticas del proceso a nivel de paquete.. Modelos basados en onditas: Son diseñados para modelar el movimiento browniano fraccional y aquellos procesos invariantes con la escala. Dentro de las ventajas de estos modelos están los que describen la LRD y SRD, obteniendo probabilidades de desbordamiento del buffer muy cercanas a las del proceso real, tal precisión implica alto costo computacional, Ma y Ji tratan de abordar el proceso y de establecer una metodologı́a para ajustar los coeficientes de las onditas, finalmente hacen una simulación exitosa de los resultados observando la respuesta del buffer.. 6.
(20) IEMC-I-06-14 Modelos de fuentes ON/OFF: consisten en la implementación de fuentes únicas de tráfico, que se encuentran en estado ON, cuando intercambian información con el servidor, o en estado OFF, cuando se encuentran en un estado de inactividad ya sea porque están procesando la información obtenida o porque finalizaron la conversación. Este tipo de modelos ha permitido generar tráfico que sin requerir un alto costo computacional, puede reproducir tanto la caracterı́stica de SRD, como la LRD. 1.2.1.. Definición de autosimilaridad. Sea X una variable aleatoria, estacionaria, de segundo orden y sea X (m) (i), la serie agregada del proceso X, esto es, la suma de elementos consecutivos en grupos disyuntos de m elementos. El proceso se denomina exactamente autosimilar de segundo orden, si se cumple que para todo m > 1: V ar(m(1−H) · X (m) ) = σ 2. (1). r(k)(m) = 1/2 · (|k + 1|2·H − 2 · |k|2·H + |k − 1|2·H ). (2). Un caso especial de los procesos autosimilares de segundo orden, son los procesos asintóticamente autosimilares de segundo orden, en los cuales se cumple que para m → ∞,se cumple que:. V ar(m(1−H) · X (m) ) → σ 2. (3). r(k)(m) → 1/2 · (|k + 1|2·H − 2 · |k|2·H + |k − 1|2·H ). (4). En la ecuación (4), H es el parámetro de Hurst o parámetro de autosimilaridad. Para que una serie sea autosimilar se debe cumplir H > 0,5. El parámetro H de una serie puede estimarse por medio de diversas metodologı́as. En el apéndice A, se 7.
(21) IEMC-I-06-14 explican detalladamente los métodos utilizados en el presente estudio, los cuales se mencionan a continuación: Análisis de varianza-tiempo de procesos agregados. [20]. Método R/S o de estadı́sticas por rangos. [21]. Método por aproximación a un Ruido fraccional gaussiano (FGN). [22]. Los detalles de cada método, se muestran en el anexo A. 1.2.2.. Distribuciones con cola pesada. Se dice que una distribución es de cola pesada, si se cumple que:. P (X ≤ x) ≈ x−α , x → ∞, 0 < α < 2. (5). P (X ≤ x) = 1 − (k/x)α , x → ∞, 0 < α < 2. (6). La ecuación 6 muestra un caso particular de las distribuciones con cola pesada, la función de distribución Pareto. Esta distribución es hiperbólica en todo el rango y es la más popular en el modelamiento de variables en el área de las redes de computadores. En la ecuación 6, k es el mı́nimo valor de la variable aleatoria o factor de escala, en tanto que α, es la que determina que tan rápido decae la cola de la distribución y se denomina factor de forma. El factor de forma α, incide en el comportamiento estadı́stico de la variable, para α < 2, la varianza es infinita, pero si además α < 1 la media también es infinita. Esto implica que la variable aleatoria tiene valores posibles que tienden a infinito y cuya probabilidad de ocurrencia es mayor a cero. El factor de escala α para una función Pareto se puede calcular con la ecuación 7.. 8.
(22) IEMC-I-06-14 Donde P (X ≥ x), es la función de distribución acumulada complementada (CCDF) de P (X ≤ x) y se define como P (X ≥ x) = 1 − P (X ≤ x). dlog(P (X ≥ x)) = −α dlogk/x. 1.3.. (7). Generadores de tráfico. Existen dos tendencias que se pueden identificar dentro de los generadores de tráfico disponibles comercial o libremente: Tráfico basado en una función de distribución o caja negra: Este tipo de generadores, recolectan numerosas trazas de tráfico, para determinar estadı́sticas que las describan y hacer ajustes a modelos como Ruido fraccional gaussiano, procesos ARIMA o procesos de Markov modulados. Para implementar tales procesos, existen numerosos generadores de tráfico que permiten generar paquetes ya sea UDP o TCP con una función de distribución de probabilidad para el tiempo entre paquetes y el tamaño de los mismos. Para el caso de la presente investigación, se usó el generador de tráfico de libre distribución D-ITG[23], cuya efectividad fue corroborada como lo señalan los resultados mostrados en secciones siguientes. La concepción de caja negra tiene como principal inconveniente, el ajuste a futuras condiciones de la red y a variaciones en la demanda. Tráfico basado en el comportamiento del usuario (Modelos empı́ricos): A partir del análisis estadı́stico de diversas trazas recolectadas en una red real, se logran algoritmos que imitan el comportamiento del usuario navegando en el Internet. Los generadores de este tipo tienen como ventajas: que son más flexibles y más portables que los anteriores, pues se construyen libres de la influencia de 9.
(23) IEMC-I-06-14 parámetros de hardware y software de la red. La principal dificultad consiste en que requieren medidas mas detalladas que en los otros casos. La información necesaria para construir un modelo empı́rico, puede ser obtenida por diversos métodos:. Tráfico basado en la información proveniente de los registros de solicitudes hechas al servidor: Esta metodologı́a da información respecto al comportamiento de las solicitudes que llegan a un servidor. De esta metodologı́a, se puede obtener el tiempo de llegada de una solicitud, el archivo requerido y eventualmente el tamaño del archivo. La principal desventaja, es que esta información resulta insuficiente para estudios de localidad, es decir, no se pueden determinar las preferencias de los usuarios respecto de servicios fuera de la red de estudio, y solo permite caracterizar al usuario respecto de un servidor en particular.. Información proveniente de los registros de solicitudes hechas desde el cliente: A diferencia de la técnica anterior, esta permite hacer estudios de localidad y en realidad es la técnica que permite caracterizar de la mejor forma al cliente. No obstante, esta técnica tiene como principal desventaja, que resulta en experimentos difı́ciles de realizar, pues es necesario disponer de un navegador de Internet que capture la información del lado del usuario. Un navegador con tales caracterı́sticas vulnera la seguridad y la privacidad del cliente, por lo que un experimento basado en este tipo de información requiere permisos y poblaciones especiales.. Información capturada en un enlace de la red de estudio: Este tipo de estudios es el más popular y soluciona las dificultades presentes en los métodos anteriores. Consiste en el uso de un Sniffer, que es un software que permite capturar. 10.
(24) IEMC-I-06-14 tráfico de una red activa. Uno de los más populares es el tcpdump [14] para Linux y windump[24] para windows. La principal desventaja consiste en la dificultad para reconstruir los archivos a partir de la información suministrada, lo que dificulta establecer el tamaño del archivo, su tiempo de transferencia y asociar los archivos que pertenecen a una misma página Web. A continuación se hace una reseña de algunas de las investigaciones que desarrollan modelos de tipo empı́rico o basados en el comportamiento del usuario, se describe el modelo y algunos resultados obtenidos. 1.3.1.. Mah [3]. En esta investigación, se recolectan trazas de la red Ethernet de 10 Mbps de la División de Ciencia de Computadores de la Universidad de California en Berkeley, en los meses de Septiembre a Noviembre de 1995. La finalidad del estudio es la construcción de un modelo que se ajuste a las caracterı́sticas reales de tráfico, para la evaluación de redes por simulación. Cada traza tenı́a una duración de entre 24 y 36 horas y una longitud de entre 186,000 y 676,000 paquetes. Las variables modeladas fueron:. Tamaño de las solicitudes desde el cliente: Una solicitud está definida como un conjunto de paquetes que tienen como caracterı́stica común la dirección de origen, la de destino y el puerto de conexión TCP. Se obtiene que esta variable, exhibe caracterı́sticas bimodales. El tamaño de la solicitud es de entre 10 y 2000 bytes, con una media de 300 bytes.. Tamaño de las respuestas desde el servidor: La metodologı́a es similar a la de las solicitudes y se obtiene que esta variable se puede modelar con una distribución. 11.
(25) IEMC-I-06-14 de cola pesada, como la Pareto con parámetro de escala α de entre 1.04 a 1.16.. Archivos por página Web: Para determinar este parámetro, se usa una aproximación heurı́stica que consiste en asumir que los archivos consecutivos, pertenecen al mismo documento Web. Este tiempo se estima está entre 1 y 30 segundos. Mah elige como regla 1 s, porque es más probable que la página Web se visualice en un tiempo inferior a 1 s. El autor demuestra que el tiempo elegido no es crı́tico y que en promedio se solicitan 3 archivos por documento Web.. Solicitudes primarias y secundarias:. Una solicitud primaria se define como. la primera solicitud que se hace cuando el usuario se conecta a un servidor Web. Esta solicitud generalmente devolverá un archivo HTML. Una solicitud secundaria se define como la o las solicitudes realizadas para visualizar la página Web de manera apropiada a partir de la información entre lı́neas presente en el documento HTML solicitado. En resumen la solicitud del documento primario va entre 20 y 2,400 bytes. En tanto que para una solicitud secundaria, está entre 100 y 1,200 bytes.. Respuestas secundarias y primarias: Se definen como la información proveniente del servidor a partir de la solicitud hecha por el cliente. Estas variables nuevamente exhiben una caracterı́stica de cola pesada y están entre 100 y 8,146,000 bytes (media de 17 kbytes) para el caso de las respuestas a solicitudes primarias y entre 45 y 2,413,000 bytes (media de 7 kbytes) para respuestas a solicitudes secundarias.. Tiempo de inactividad del cliente: Todo tiempo entre conexiones TCP que sea mayor a 1 s. Se tiene un máximo de 80,681 s en dı́as no festivos y una media de. 12.
(26) IEMC-I-06-14 850 s, la cual se ve atenuda por la baja afluencia en dı́as festivos.. Número de descargas consecutivas de un mismo servidor: Este parámetro tiene que ver con estudios de popularidad de servidores y se obtiene que un usuario requiere de manera consecutiva entre 4 a 112 archivos de un servidor web, antes de cambiar de servidor.. Selección del servidor: Este parámetro es útil para determinar la popularidad de un servidor Web y la frecuencia de accesos a un servidor. Se ha modelado por distribuciones de cola pesada como la Ley de Zipf. Del estudio realizado por Mah se obtiene como resultado que los servidores más populares son los locales. La metodologı́a utilizada tiene como desventaja que no tiene información adicional a la dirección IP del servidor, con lo cual no se puede saber si varias IP pertenecen a un mismo servicio o cuando una misma IP ofrece servicios diferentes. El modelo se implementó para usarse en el simulador de redes INSANE [25] y las variables obedecen a los histogramas empı́ricos obtenidos[26]. 1.3.2.. Choi y Limb [2]. El estudio se desarrolló con base en la recolección de tráfico, usando tcpdump, en el backbone del campo de Georgia Tech, de las 11 a.m. a las 12 p.m. en Octubre de 1998. Participan aproximadamente 1,900 clientes que hacen 24,000 solicitudes. Aunque el autor indica que esta información no es representativa, es útil para fines de evaluación de la metodologı́a de caracterización de tráfico para el uso en la planeación y aprovisionamiento de la red, ası́ como la evaluación de protocolos. En la tabla 2, se resumen los parámetros del modelo implementado. Los autores, definen la solicitud Web como un evento iniciado por una acción. 13.
(27) IEMC-I-06-14 PARÁMETRO Tamaño de la solicitud Tamaño del objeto primario Tamaño del objeto secundario Tiempo de análisis en la máquina Número de objetos secundarios Tiempo entre arribos de documentos Tiempo de inactividad Número de solicitudes Web no en caché Número de solicitudes Web en caché. MEDIA 360 bytes 10.7 kbytes 7.7 kbytes 130 ms 5.55 860 ms 39.5 s 12.6 1.7. DISTRIBUCIÓN Log Normal Log Normal Log Normal Gamma Gamma Gamma Weibull Log Normal Geométrica. Tabla 2: Parámetros del modelo propuesto por Choi y Limb humana (clic). Del estudio realizado, se tiene que la mayorı́a de las solicitudes Web corresponden a archivos del tipo HTML. Lo novedoso con respecto de la investigación hecha por Mah, es que se verifica el tipo MIME del archivo, el cual indica que tipo de información va en el paquete, para determinar si es una solicitud primaria o secundaria, es decir si es un archivo con extensión html (solicitud primaria) o un archivo con extensión de imagen o video (solicitud secundaria). Además, de los conceptos introducidos por Mah, Choi y Limb introducen el efecto de los archivos temporales de Internet sobre el tráfico y lo modelan creando dos variables, una para las solicitudes atendidas desde la carpeta de archivos temporales y otra para las solicitudes atendidas directamente desde el servidor. El modelo se valida con base en:. Ancho de banda requerido: Se calcula el número de bytes tramitados en periodos de 100 ms y se obtiene que en promedio es de 4.6 kbytes tanto para las trazas reales como para las trazas generadas.. Pruebas de autosimilaridad: Usando el método R/S para calcular el parámetro de Hurst del proceso se encuentra que es de 0.8 para la traza real y de 0.77 para la 14.
(28) IEMC-I-06-14 traza generada. 1.3.3.. Barford y Crovella [5]. La metodologı́a de recolección de información que usaron, es basada en la obtención de información en el lado usuario, lo cual se logró al instrumentar el navegador Web NCSA Mosaic. Por medio de una modificación en el código fuente, los investigadores logran obtener la URL del archivo solicitado, la hora y fecha de la solicitud. El experimento tuvo lugar en las instalaciones del departamento de Ciencias de Computación de la Universidad de Boston, en 32 estaciones dedicadas a estudiantes de pregrado, y en 5 estaciones dedicadas a estudiantes de postgrado. El experimento recolecta información desde Noviembre de 1994 a Mayo de 1995[10]. En un trabajo posterior[5], y con base en las trazas reseñadas anteriormente, producen un generador de tráfico llamado SURGE (Scalable Referente URL Generator), motivados en la necesidad de experimentar con servidores y redes usando tráfico de alta variabilidad. A continuación se explica la filosofı́a del modelo, el cual se basa en los conceptos de usuarios equivalentes y modelos con variables ajustadas a una función de distribución de probabilidad.. Usuarios equivalentes: Es la caracterı́stica que determina la intensidad de la demanda. Un usuario equivalente es un proceso que alterna entre dos estados, uno solicitando archivos y otro de inactividad. Cada usuario equivalente es una fuente de tráfico ON/OFF[11]. Los tiempos OFF, son despreciados en algunos generadores de tráfico, en los cuales se hacen solicitudes tan rápido como sea posible. No obstante, Bradford y Crovella logran demostrar en su investigación que es este parámetro el que le da la caracterı́stica de autosimilaridad al tráfico y por tanto, no puede ser despreciado. 15.
(29) IEMC-I-06-14 Una de las principales dificultades en el ajuste del modelo tiene que ver con la dificultad de ajustar las variables que exhiben una cola pesada. En la tabla 3 se muestran las variables del modelo adoptado. PARÁMETRO Respuestas a solicitudes primarias Respuestas a solicitudes secundarias Popularidad Localidad temporal Tamaño de las solicitudes Tiempos entre solicitudes embebidas Tiempos entre solicitudes Web Número de referencias embebidas. DISTRIBUCIÓN Log normal Pareto Zipf LogNormal Pareto Weibull Pareto Pareto. Tabla 3: Parámetros del modelo propuesto por Barford y Crovella Para validar el modelo, se hacen pruebas del generador que corre en 6 computadores. El tráfico generado tiene un parámetro de Hurst de 0.75. 1.3.4.. Heegard [9]. Esta investigación produce una aplicación llamada Gensyn, un generador de tráfico basado en un modelo de cadenas de Markov, de tres estados:. Apagado: Es el estado en el que se encuentra una fuente ON/OFF cuando no está solicitando archivos.. Lectura: El usuario lee la página y decide que hará a continuación, para lograr la variabilidad deseada, este estado se modela como 4 posibles estados de lectura, con lo que se logra implementar un comportamiento hiperexponencial del proceso.. Descarga: Una vez que el usuario toma la decisión, abre la conexión a una URL y descarga el documento y los archivos asociados a su visualización. A diferencia de 16.
(30) IEMC-I-06-14 las otras dos variables, esta variable no corresponde a un espacio de estados aleatorio y está gobernada por un espacio de estados de comunicación cuyo funcionamiento depende de los protocolos y caracterı́sticas inherentes a la red y no por la aplicación. La población de usuarios estará en uno de los 6 estados posibles y permanecerá en cada uno de ellos por un tiempo determinado por una ley estocástica. La tasa de transferencia asociada y sugerida por el autor es de 1/1800s−1 y la distribución de probabilidad asociada es una exponencial negativa. El autor no expone con detalle los resultados obtenidos y manifiesta tener dificultades en la implementación, que obedecen a limitaciones del lenguaje de programación, que en este caso es Java. Sugiere que serı́a más apropiado el uso de lenguaje C. 1.3.5.. Deng [4]. En esta investigación se hace uso de dos trazas de 2 horas cada una capturadas en agosto de 1995 en el backbone de los laboratorios de la GTE. En donde se obtuvo que entre el 30 % y el 37 % del tráfico correspondı́a a tráfico Web. El modelo está basado en el concepto de fuentes de tráfico ON/OFF y consiste de 4 parámetros: el tiempo entre solicitudes, la duración del tiempo ON , la duración del tiempo OFF y la distribución del tamaño de los archivos. Las dos primeras variables, se ajustan a una función de distribución Weibull y las demás a una distribuón Pareto. 1.3.6.. Influencia de la autosimilaridad en el desempeño de la red. El hallazgo de autosimilaridad en el tráfico de Internet, ha permitido entender las causas de los cambios abruptos entre la subutilización y la congestión de los enlaces de redes de datos, según lo reseñan Crovella, Lindemann y Reiser [1]. Esto ha contribuido al desarrollo de mecanismos de control de congestión capaces de 17.
(31) IEMC-I-06-14 predecir estados futuros del enlace. Gracias a la comprensión del concepto de larga dependencia y al trabajo de medición de la misma, se pudo determinar que el mayor porcentaje del tráfico cursado obedece a la transferencia de archivos pequeños o de corta vida y que los archivos de gran tamaño o larga vida son poco comunes. Esto ha llevado a determinar que una mejora del desempeño sucede cuando los flujos de corta vida pueden ser transportados por una misma conexión TCP y de esta manera evitar tráfico de inicialización de las conexiones que puede ser redundante. Es este principio el que motivó la implementación de HTTP 1.0. Lo anterior es apenas una pequeña muestra del impacto que puede tener el dominar la caracterı́stica autosimilar del tráfico, pero aún falta explorar en otros campos de aplicación que incidan de manera favorable en el desempeño de las redes.. Respecto a la labor a futuro, se requiere el planteamiento de controles de red escalables, que tengan en cuenta que la red tiene procesos que suceden en escalas de tiempo diferentes, lo que involucra el uso de diversos controles que incluso pueden suceder de manera simultánea basados en sistemas de monitoreo de red que permitan retroalimentar de manera eficiente (en tiempo real) dichos controles. También es necesario lograr optimizar el consumo de recursos y lograr minimizar el número de negaciones del sistema, lo cual se puede lograr con una alta distribución de las fuentes de información y de los servicios de computación lo que evitará la información redundante en Internet. Esta es la filosofı́a de los algoritmos de almacenamiento de archivos temporales, los cuales pueden mejorar en aras de aumentar la calidad del servicio al usuario final.. 18.
(32) IEMC-I-06-14. Capı́tulo II. Caracterización de tráfico HTTP El proceso de caracterización de tráfico, es un proceso, que provee puntos de verificación de los modelos implementados. Además, es la etapa en la que se evalúan las herramientas de análisis empleadas. La etapa de caracterización, permite verificar resultados obtenidos por otros investigadores, y es una actividad que aporta mucho a la investigación, pues a través de este proceso es más fácil familiarizarse con los fenómenos de estudio en la red. Dentro del proceso de caracterización de tráfico, se distinguen tres fases: Medición Reducción Ajuste estadı́stico. Medición: La etapa de medición es muy importante, ya que de ella depende el éxito de los resultados obtenidos. Para la medición, se emplea el programa tcpdump[14], que como se dijo anteriormente es una potente herramienta que permite capturar tráfico desde y hacia la tarjeta de red. La figura 1, muestra el escenario de medición de tráfico real.. 19.
(33) IEMC-I-06-14. Figura 1: Escenario de medición del tráfico producido por un usuario de Internet de la sala de asistentes graduados del Departamento de Ingenierı́a Eléctrica y Electrónica de la Universidad de los Andes.. 20.
(34) IEMC-I-06-14 La finalidad de este experimento, es capturar el tráfico que transmite y recibe un usuario mientras navega en Internet. Para aumentar la precisión de la medida, no se capturan paquetes en la misma tarjeta de red del usuario, esta actividad se realiza en un computador diferente, denominado snnifer, corriendo la aplicación tcpdump, según aconseja Paxon en [17]. Dentro de las subredes, los usuarios, tienen el acceso a Internet a través de elementos de conmutación (Switch), para que a cada tarjeta de red solo llegue el tráfico destinado a ésta y el tráfico de difusión. Con esto, una tarjeta en modo promiscuo, en una red conmutada, no puede ver el tráfico de otras máquinas en la misma subred. Para lograr que la tarjeta de red del snnifer vea el tráfico del cliente en observación, se emplea un concentrador (Hub), que tiene como fin multiplexar el nodo, pero no tiene inteligencia como para filtrar el tráfico de acuerdo a la dirección de destino como lo hace el switch. Para iniciar la medida, se digita en la lı́nea de comandos windump [24] (Windows) o tcpdump [14] (para Linux) según corresponda, a continuación, y para evitar el exceso de información, se puede aplicar además un filtro para no capturar tráfico de difusión, el comando que inicia la captura de tráfico HTTP se muestra a continuación: windump. -i 2 -w captura port 80. Esto provocará que se guarde el tráfico HTTP visto por la interface de red número 2, en un archivo binario llamado captura. Reducción: Esta fase consiste en extraer de entre los 60 y 1500 octetos que hay por cada paquete, la información de interés. Se aprovecha la facilidad de tcpdump que produce un resumen del encabezado de la trama IP, como el que se muestra a. 21.
(35) IEMC-I-06-14 continuación: 16:41:28.070018 IP (tos 0x0, ttl. 64, id 2825, offset 0, flags [DF],. proto: TCP (6), length: 1500) 192.168.0.10.80 > 192.168.0.21.4008: La información de los bytes se decodifica en cadenas de texto de este estilo, de las cuales se puede extraer: El tiempo de llegada a la tarjeta de red, dado en horas, minutos, segundos, milisegundos y microsegundos (timestamp). El tipo de protocolo de transporte El tamaño en bytes del paquete Las direcciones IP de origen y destino Los puertos de origen y destino. La mayor dificultad que reviste el proceso de reducción, consiste en el gran volumen de información que tiene cada captura, lo que puede implicar mucho tiempo de ejecución (horas o incluso dı́as) y un costo computacional elevado, por lo cual es importante elegir un lenguaje de programación adecuado. Una herramienta muy eficiente, en el manejo de cadenas, es el G77[27]. Esta es una distribución binaria, que corresponde a la versión GNU de Fortran y trae numerosas funcionalidades no solo para manejo de cadenas, sino para el cálculo matemático. Los tiempos de procesamiento están alrededor de 3 segundos por cada Megabyte de información. En la figura 2 se ilustra el algoritmo escrito en Fortran que reduce la traza y que además determina la estadı́stica descriptiva de la misma. El algoritmo, permite filtrar la información por tipo de protocolo de trasporte, por el puerto de origen y/o destino 22.
(36) IEMC-I-06-14 y extrae la información necesaria para determinar las estadı́sticas del tiempo entre llegadas y de la cantidad de bytes por unidad de tiempo (con precisión de milisegundos) por último, se puede introducir una serie de datos y hacer la agregación de los datos (suma de los elementos por grupos de igual tamaño, que no tienen elementos comunes). Los detalles del algoritmo (código y manual del usuario), se encuentran en la documentación electrónica que complementa este documento (Ver Anexo B).. Inicio GENERAR EL ARCHIVO DE RESUMEN Extrae timestamps y los convierte a ms Extrae el tamaño, tipo de protocolo de transporte, puerto de origen y destino. Introduzca el nombre del archivo que contiene la serie que va a agregar. Introduzca el número de elementos de la agregación. Se quiere generar el proceso de ms?. Cálculo de las estadísticas de la nueva serie: - Media, varianza, total elementos - Coeficientes de correlación - Parámetro de Hurst, basado en el primer coeficiente de correlación. SI TCP puerto 80 o UDP?. Resumen de cada paquete perteneciente al protocolo elegido: - Tiempo desde el paquete anterior (ms) - Tamaño del paquete (Bytes). Conteo de bytes/ms del protocolo. Figura 2: Diagrama de flujo para la reducción y análisis de información. 23.
(37) IEMC-I-06-14 Ajuste estadı́stico: Es el proceso mediante el cual, se determinan los parámetros de las funciones de distribución que mejor describen las variables involucradas en el modelo. Este procedimiento se lleva a cabo con la versión estudiantil de Mathlab 7. Este programa tiene utilidades para el ajuste automático de series de datos a un amplio rango de funciones de distribución (dfittool ) y para el ajuste manual, pruebas de ajuste como la prueba de Smirnov Kolmogorov (kstest2), que permite comparar dos series y ajustar parámetros aplicando una táctica iterativa. El ajuste inicial, se hace con la herramienta automática y posteriormente se inicia un proceso de prueba y error para el ajuste fino de los parámetros en busca del mı́nimo error (menor al 5 %). Estos métodos funcionan bien, para series que se ajustan a funciones de distribución como la Normal, LogNormal y Exponencial, pero los ı́ndices de error resultan muy altos en el ajuste de funciones Pareto (series con varianzas y/o medias infinitas). Para estos casos, se hace un ajuste por verificación visual. En un gráfico log-log de la CCDF empı́rica de la serie de datos, es fácil determinar la pendiente de la lı́nea que mejor se ajusta a los datos, la cual se puede constatar con una regresión lineal aplicada a la cola de la CCDF empı́rica. Esta metodologı́a, permite determinar los parámetros de forma α (la pendiente de la recta) y el factor de escala k (el punto inicial de la recta), de la distribución Pareto que mejor se ajusta.. 2.1.. Caracterización de un usuario. A continuación, se muestran los resultados más relevantes del análisis aplicado al tráfico que genera un usuario mientras navega en Internet, consulta el correo, chatea, hace consultas y descarga archivos, usando Internet Explorer para Windows XP, la captura tiene una duración de 30 minutos y contiene información de 30000 paquetes de tráfico HTTP. El experimento tiene lugar en las instalaciones del laboratorio de. 24.
(38) IEMC-I-06-14 Eléctrica y Electrónica de la Universidad de los Andes en Enero de 2006 (periodo vacacional). En la tabla 4, se muestran algunas estadı́sticas obtenidas con Ethereal, en este capı́tulo, se hace un análisis detallado de la traza correspondiente a la medida número 4. Medida No. Bits/segundo Paquetes/hora Solicitudes Web/hora Conexiones TCP/hora Solicitudes Web/conexión TCP. 1 26k 20k 892 504 1.7. 2 120k 10k 372 201 1.8. 3 65k 38k 660 828 0.79. 4 118k 67k 354 216 1.6. Tabla 4: Resultados de las medidas de tráfico realizadas a un usuario real de Internet (Enero 2006).. 2.1.1.. Volumen de tráfico. Se define volumen de tráfico a la suma de la longitud en bytes de los paquetes que llegaron a la tarjeta de red en un periodo determinado, que para el caso se fijó en 1 ms. Con la herramienta de agregación, se pueden generar diversos conjuntos de series para escalas de 1, 10, 100 y 1000 ms. Para hacer una verificación formal de la caracterı́stica autosimilar del volumen generado por un usuario de Internet, se aplican las pruebas de autosimilaridad descritas en el capı́tulo anterior. En la figura 3, se muestran los resultados de las pruebas gráficas de los métodos R/S y de varianzas agregadas. El tercer método estudiado en este documento (Ver apéndice A) es el método por aproximación a un Ruido Fraccional Gaussiano (FGN). Para esto, se construye la gráfica de la función de correlación del volumen de datos de un usuario real y se busca el parámetro de Hurst del Ruido Fraccional Gaussiano que mejor se ajusta a los datos medidos. Los resultados se ilustran en la figura 4. Nótese que es claro que. 25.
(39) IEMC-I-06-14. Figura 3: Parámetro de Hurst obtenido por: (a) Método de la varianza (b) Método R/S, aplicados al volumen de tráfico producido por un usuario de Internet real. un Ruido Fraccional Gaussiano con H = 0.95 tiene una función de correlación que se ajusta bastante bien al tamaño en bytes por segundo que se tramitan mientras un usuario navega en Internet, esto permite concluir que la serie es autosimilar y presenta una dependencia a largo plazo (la función de correlación decae lentamente a cero). En la tabla 5, se muestra la varianza y la media de cada serie agrupada y se resumen los resultados obtenidos por los distintos métodos para diversos niveles de agregación (número de elementos de cada grupo de 1, 10, 100, 1000). De tales resultados, se observa que el proceso tiene un grado de autosimilaridad (H > 0,5) para todas las agrupaciones y que tal caracterı́stica se acentúa cuando el nivel de agrupación es mayor (H crece), además, se verifica la presencia de una dependencia a largo plazo, pues se observa una varianza que aumenta con mayor rapidez que el tamaño de la agrupación. 26.
(40) IEMC-I-06-14. Correlación del proceso de agregación 1s: r(k). 1 Coeficientes de correlación del throughput (bytes/seg) Exponencial = 0.7exp(-0.01x) Correlación para un proceso FGN, con H=0.95 Correlación para un proceso FGN, con H=0.925 Correlación para un proceso FGN, con H=0.9. 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0. 0. 100. 200. 300 k. 400. 500. 600. Figura 4: Coeficientes de correlación para el volumen de tráfico producido por un usuario de Internet real. De lo anterior, se observa como el proceso de agregación hace que la traza obtenida aumente su caracterı́stica autosimilar. Las series con niveles de agregación mayores, además, presentan una función de correlación de caı́da lenta por lo cual se puede decir que la variable tiene dependencia a largo plazo. 2.1.2.. Tiempo entre llegadas de paquetes. La herramienta de reducción descrita anteriormente, permite construir una serie de datos que contienen la diferencia en milisegundos entre paquetes que llegan de manera consecutiva a la tarjeta de red del medidor (sniffer ). Para el estudio que se muestra a continuación, se eligen únicamente los paquetes TCP con puerto de origen y/o destino 80 (paquetes HTTP).. 27.
(41) IEMC-I-06-14 Agregación ms 1 10 100 1000. Varianza [bytes2 ] 11129 526350 12086000 957160000. Media [bytes] 29 158 1400 14500. R/S H 0.78 0.84 0.92 0.94. Var-Agreg H 0.59 0.64 0.76 0.97. FGN H 0.86 0.83 0.94 0.91. Tabla 5: Resumen de las estadı́sticas para el volumen de tráfico generado por de un usuario de Internet real. Se aplican las pruebas para el cálculo del parámetro de Hurst, de la serie tiempos entre paquetes y se obtienen los resultados mostrados en la tabla 6. De la tabla, se puede apreciar, que para la variable tiempo entre paquetes, no se aplica una agregación por tiempo, sino por elementos de la serie. Al hacer esto, en la agregación de 1000, se cuenta con una serie de apenas 30 datos, la cual tiene muy pocos elementos como par aplicar los métodos R/S y el de varianzas agregadas, por tanto el cálculo queda indeterminado (Ind.) Agregación paquetes 1 10 100 1000. Varianza [ms2 ] 218914 3200841 80507072 4e+9. Media [ms] 107 588 5366 51000. R/S H 0.75 0.78 0.89 Ind.. Var-Agreg H 0.74 0.79 0.67 Ind.. FGN H 0.8 0.8 0.83 0.72. Tabla 6: Resumen de las estadı́sticas para el tiempo entre paquetes del tráfico de un usuario de Internet. De los resultados de la tabla 6, se puede deducir que el proceso de tiempos entre llegadas es una variable con una tendencia autosimilar (H > 0,5). A continuación, se validará el método del análsis por medio del ajuste de la serie a una función de distribución Pareto como se sugiere en [6]. Para esto, se emplea la herramienta dfittool de Mathlab, pero se llega a la conclusión, que los parámetros ajustados tienen un margen de error amplio y que no son ajustables a una distribución exponencial. 28.
(42) IEMC-I-06-14. CCDF -Prob(Tiempo >X). 1. 0.13. 0.01. 2e-3. 3e-4. 0. 1ms. Agregación de 1 Agregación de 10 Agregación de 100 Agregación de 1000 Pareto(1.4,20) Pareto(1.4,200) Pareto(1.4,2000) Pareto(1.4,20000). 50ms 3s Tiempo entre paquetes. 27min. Figura 5: Prueba log-log de la CCDF para varios niveles de agregación del tiempo entre llegadas de paquetes http del tráfico generado por un usuario de Internet real. Por tanto, es necesario hacer una prueba de ajuste diferente, para esto, se emplea la metodologı́a descrita en [28], a partir de la obtención de la función de distribución acumulada complementaria (CCDF) como se muestra en la figura 5. Por un ajuste visual, se determina la pendiente que mejor se ajusta a los datos, obteniéndose que los mismos se ajustan a una función Pareto con parámetro α=1.4. A pesar de que los resultados obtenidos, coinciden con los reportados [28][6] por cuanto se verifica que la variable tiempo entre paquetes se ajusta mejor a una distribución Pareto de varianza infinita (α < 2) que a una exponencial, la estadı́stica descriptiva de la serie (ver tabla 6) indica que la varianza no deja ver una clara tendencia a ser infinita. Ante esto, debe considerarse que ni este estudio, ni los. 29.
(43) IEMC-I-06-14 estudios de referencia se pueden catalogar como representativos, pues la duración de las trazas no es lo suficientemente larga y por tanto puede acotar los resultados posibles del proceso.. 2.2.. Caracterización de la red Uniandes. El tráfico capturado por una red con tantos usuarios como la red Uniandes, no es fácil de recolectar. La DTI (Dirección de Tecnologı́as e Información), facilitó un archivo de 60 minutos de tráfico capturado con tcpdump en el backbone de la Universidad de los Andes, la captura sucedió en el mes de Mayo de 2004 (época de parciales finales). El archivo de 1.2 Gbytes, contiene 12’227679 paquetes, de los cuales, 6’602.638 corresponden a tráfico HTTP, lo que equivale a que el tráfico de Internet durante el intervalo capturado, corresponde aproximadamente, al 54 % del tráfico total. 2.2.1.. Volumen de tráfico. A continuación, se muestra el análisis del comportamiento de el volumen de tráfico de la red Uniandes para los primeros 15 minutos de la captura. Para tal fin, se procesan los primeros 3 millones de paquetes y se obtiene el volumen en bytes procesado cada milisegundo, con esta información, se puede deterrminar que el consumo de ancho de banda en el momento de la medición es de 1.8Mbytes por segundo, esto es, 14.5 Mbps. En la figura 6, se busca ilustrar el fenómeno de autosimilaridad presente en el tráfico capturado. En primer lugar se hace una vista a gran escala del fenómeno, se observan 15 minutos de tráfico (900 segundos), luego, se elige una porción de esta vista y se magnifica, para observar 100 segundos (parte b) y de estos se visualizan en la parte c de la figura 10 segundos. Como resultado, se obtienen 3 gráficas que realmente lucen muy similares, a tal punto que de no ser por 30.
(44) IEMC-I-06-14. Figura 6: Volumen de tráfico para la red Uniandes (Mayo de 2004). (a) 15 minutos de tráfico, vistos con una precisión de 1s. (b) 100 segundos de tráfico vistos con una precisión de 0.1s (c) 10 segundos de tráfico vistos con una precisión de 0.01s.. 31.
(45) IEMC-I-06-14 los ejes no se podrı́a advertir el efecto de la magnificación, lo que coincide con las mediciones hechas en redes LAN por Willinger [11]. La autosimilaridad se verifica por medio del cálculo del parámetro de Hurst aplicado a la serie para diferentes niveles de agregación, los resultados se consignan en la tabla 7. Obsérvese que a medida que aumenta la agregación, aumenta el parámetro de Hurst, que para todos los casos es superior a 0.5 y por tanto implica autosimilaridad. Agregación ms 1 10 100 1000. Varianza [bytes2 ] 1.4e+6 27.3e+6 532.3e+6 14e+9. Media [kbytes] 11 130 1000 10000. R/S H 0.72 0.73 0.77 0.82. Var-Agreg H 0.67 0.72 0.76 0.80. FGN H 0.82 0.85 0.80 0.87. Tabla 7: Resumen de las estadı́sticas para el volumen de tráfico de la red Uniandes (Mayo de 2004).. 2.2.2.. Tiempo entre paquetes. Aplicando la metodologı́a descrita anteriormente, se tiene que el tráfico agregado de numerosos usuarios exhibe caracterı́sticas distintas al mostrado en el caso de un único usuario. En este caso, casi el 99 % de los paquetes del tráfico llegan al snnifer a intervalos exponencialmente distribuidos. No obstante, la presencia de tiempos largos en la traza hace que aparezca una cola pesada (el 1 % restante), que se ajusta muy bien a una distribución Pareto, de varianza y media finitas. La principal razón de este resultado, puede estar asociada a la corta duración de la captura, lo cual puede acotar significativamente los tiempos entre paquetes. Obtener muestras de mayor duración tiene como principal inconveniente que se pueden generar grandes volúmenes de información, de 12 millones de datos por cada hora de tráfico, esto quiere decir que para poder analizar un dı́a de tráfico se tendrı́an 288 millones de. 32.
(46) IEMC-I-06-14 datos, lo cual demanda un gasto computacional importante. Para la reducción de la traza de 1 hora, por ejemplo, se requirió de un computador con Windows XP de 2 GHz y 256 Mbytes en RAM haciendo el proceso durante 4 horas.. 2.3.. Tráfico de fondo. Los análisis previos se han dedicado a la caracterización del tráfico HTTP. El resto de tráfico (46 %), es la suma de otros flujos TCP y los flujos UDP, a los cuales se les denominará tráfico de fondo. En busca de escenarios de medición lo mas reales posibles, un desarrollador de herramientas para medición de desempeño, requiere la presencia de tales flujos que además de imprimir el realismo, permitirán introducir circunstacias de tráfico diversas (estados de alta y baja carga, comunicaciones no orientas a conexión, etc.). A continuación se plantea una estrategia para la producción sintética de tráfico de fondo en una red real, para esto, se utiliza el modelo simplificado que usan diversos generadores de tráfico, que consiste en establecer una función de distribución para el tamaño de los paquetes y el tiempo entre llegadas de los paquetes que se van a emitir. Para poner este flujo en la red, se utiliza un program de libre distribución llamado D-ITG[23]. El generador requiere que el usuario indique el tipo de distribución deseada (dentro de las posibles distribuciones: exponencial, gamma, pareto, normal) y los parámetros de la distribución. Luego del ajuste de la serie de datos del tráfico capturado, se logra determinar que la mejor opción para tiempo entre paquetes es una exponencial con una media de 0.5 ms y para el tamaño de los paquetes, se elige una función Gamma con una media de 104 bytes (ver figura 7).. Para el tiempo entre paquetes, se obtiene un error del orden de 4e−5 para una. 33.
(47) IEMC-I-06-14. Traza Generada Tráfico de fondo Unidades Función Exp(2000). Traza Generada Tráfico de fondo Unidades Función Gamma(0.8,130). milisegundos. bytes. Figura 7: Ajuste de las variables, tiempo entre paquetes (a) y tamaño del paquete (b) para el tráfico que no es HTTP, presente en la traza capturada de la red Uniandes (Mayo de 2004). 34.
(48) IEMC-I-06-14 prueba de Smirnov Kolmogorov con un intervalo de confianza del 5 %. En tanto, que el ajuste para el tamaño del paquete es bueno solo para el 70 % de los datos. La dificultad de lograr un ajuste mejor se atribuye a que los paquetes de tamaño superior a 500 bytes son en su mayorı́a de 1500 bytes, lo cual no se puede modelar con una función continua. El modelo ajustado, se pone a prueba en una red real y permite verificar que el. Traza real Función teórica Traza generada. Tiempo entre paquetes Media Varianza [ms] [ms2 ] 0.5184 1.899 0.5043 0.254 0.5408 0.517. Tamaño del paquete Media Varianza [bytes] [bytes2 ] 335 2.4e+5 104 1.35e+4 133 1.31e+4. Tabla 8: Cuadro comparativo de las estadı́sticas del tráfico de fondo real y el sintético generador de tráfico tiene un buen comportamiento respecto del tiempo entre paquetes. Para la variable tamaño del paquete el tráfico generado sigue muy bien el modelo propuesto, pero, como se esperaba, resulta un modelamiento que no reproduce con alta fidelidad los datos reales (ver tabla 8). Para esto se podrı́a emplear una estrategia con dos flujos, uno para los paquetes de menos de 500 bytes y otro para paquetes de 1500 bytes.. 35.
(49) IEMC-I-06-14. Capı́tulo III. Implementación de una fuente de tráfico HTTP 3.1.. Herramientas de Software para construir aplicaciones de red. La librerı́a Winpcap [24] : Es la versión para Windows de la reconocida API de Unix libpcap[14] y es la herramienta estándar de la industria para el acceso a la capa de enlace de la red. Esta librerı́a, permite construir aplicaciones para capturar y transmitir paquetes en la red omitiendo la pila de protocolos, y como utilidades adicionales, incluye la posibilidad de hacer filtrado de paquetes, herramientas estadı́sticas y soporte para captura de remota de paquetes. Gracias a sus caracterı́sticas, winpcap es la maquinarı́a de captura y filtrado de muchas de las herramientas para la red, libres y comerciales, incluyendo analizadores de protocolo, monitores de red, sistemas de detección de intrusión, sniffers, generadores de tráfico y medidores de red. Algunas de esas herramientas son Ethereal[29], Nmap, Snort, Ntop ampliamente reconocidas y utilizadas dentro de los estudiosos de las redes de comunicaciones, las cuales pueden ser encontradas en la página de herramienta para medición de CAIDA[15]. Para comenzar a trabajar con winpcap, basta con instalar la librerı́a y descargar los archivos de desarrollo, en los que se encuentran ejemplos para la generación y. 36.
(50) IEMC-I-06-14 captura de paquetes, se sugiere emplear la versión 3.0, la cual no presenta conflictos con winsock de Windows XP. Para la generación de paquetes usando este software, es necesario tener un conocimiento previo de la estructura de los datagramas para construir el encabezado necesario para que los paquetes lleguen al destino propuesto, ya que, como se dijo anteriormente el programador se salta las capas de nivel superior al de enlace.. La librerı́a Wininet [30]:El API Wininet permite enviar y recibir archivos, usando los protocolos: HTTP, FTP y Gopher, desde un servidor remoto o desde la carpeta de archivos temporales de Internet, de manera fácil, por medio de un conjunto de funciones que crean una sesión en el nivel de aplicación. La principal ventaja de WinInet es que no hay que conocer la sintaxis del protocolo a utilizar, ni establecer una comunicación con los puertos (sockets) de Windows. Las funciones tienen nombres muy descriptivos como: CInternetSession, HttpRequest, SendRequest, etc., lo que facilita familiarizarse rápidamente con el API.. 3.2.. Algoritmo para construir un usuario equivalente (UE). Un usuario equivalente es un proceso que puede ser modelado por una fuente ON/OFF [11][4]. Durante el estado ON, el usuario solicita archivos al servidor, durante el estado OFF, el usuario procesa la información adquirida, la lee o simplemente se desconecta de la red. Los tiempos OFF, son despreciados en algunos generadores de tráfico, en los cuales se hacen solicitudes tan rápido como sea posible. No obstante, Bestavros y Crovella[7], logran demostrar en su investigación que es este parámetro el que le da la caracterı́stica de autosimilaridad al tráfico y por tanto, no puede ser despreciado.. 37.
(51) IEMC-I-06-14 En general, un usuario equivalente, fusiona la acción humana y la acción del navegador de Internet. La acción de solicitar un enlace la simula haciendo la solicitud de un objeto principal (documento HTML), la acción del navegador la simula solicitando uno o varios archivos al servidor (objetos secundarios), que corresponden a los archivos necesarios para la correcta visualización de la página solicitada. A continuación se describe la construcción de una fuente Usuario Equivalente (UE), basada en los modelos reseñados en el capı́tulo 1. Los parámetros del modelo implementado son:. Tiempo ON: Es el tiempo durante el cual se hacen solicitudes de una o más páginas web al servidor.. Tiempo OFF: El tiempo durante el cual el usuario deja de solicitar archivos del servidor, ya sea porque está procesando la información obtenida o porque abandona la sala.. Tiempo IR: Es el tiempo entre solicitudes de archivos al servidor.. Tamaño Obj: Es el tamaño en bytes de los archivos requeridos luego de la lectura del archivo HTML por parte del navegador para la correcta visualización de una página Web.. Tamaño Ppal: Es el tamaño del objeto HTML solicitado al servidor, cuando el usuario hace clic.. Número Obj: Es el número de objetos que pueden ser solicitados por cada página Web. 38.
(52) IEMC-I-06-14 Cada una de estas variables es representada por una función de distribución, en la tabla 9, se muestra un cuadro que indica los parámetros de las funciones de distribución que mejor las representan y se referencia el autor del cual se toma el ajuste. La razón de utilizar los parámetros de los modelos de Mah, Deng, Crovella y Choi y no calcularlos con base en las trazas descritas en el capı́tulo 2, obedece a que son reportes basados en trazas que involucraron el estudio realizado a un número considerable de individuos y por tanto, se puede decir son representativas. Variable Tiempo ON Tiempo OFF Tiempo IR Tamaño Obj Tamaño Ppal Número Obj. CDF Weibull(81.4,0.9) Pareto( 0.99,60) Weibull(1.46,0.38) LogNormal(1,4) LogNormal(1.8,1) Gamma(0.6,1349). Media 84 s ∞ 5.5 s 8 kbyte 12 kbyte 5.55. Varianza 9000 s2 ∞ 3530 s2 8x1012 bytes2 430bytes2 130. Autor Deng[4] Deng[4] Crovella[5] Choi[2] Choi[2] Choi[2]. Tabla 9: Relación de las variables que hacen parte de un modelo para producir tráfico representativo, basado en el comportamiento de un usuario de Internet. Se incluye la información de la distribución empleada, media, varianza y autor de referencia. El algoritmo que implementa el modelo, se ilustra en el diagrama de flujo de la figura 8. El algoritmo inicia con el cálculo de los números aleatorios con la distribución de probabilidad deseada para cada variable del modelo. Posteriormente, se hace la solicitud del archivo HTML de tamaño Tamaño PPal, que es el código fuente de una página Web. Con base en la variable Num Obj, se determinan cuantos archivos se solicitarán a continuación, antes de que la fuente de tráfico ingrese a un estado de inactividad (Tiempo OFF), estos archivos de tamaño Tamaño Obj se solicitan a intervalos diferentes entre solicitudes determinados por el arreglo Tiempo IR[Num Obj], una vez todos los archivos son solicitados, se verifica que el Tiempo ON,que se contabiliza desde la primera solicitud (documento HTML),se haya vencido. Si este tiempo no ha vencido, se solicita una nueva página Web y sus 39.
Documento similar
Habiendo organizado un movimiento revolucionario en Valencia a principios de 1929 y persistido en las reuniones conspirativo-constitucionalistas desde entonces —cierto que a aquellas
You may wish to take a note of your Organisation ID, which, in addition to the organisation name, can be used to search for an organisation you will need to affiliate with when you
Where possible, the EU IG and more specifically the data fields and associated business rules present in Chapter 2 –Data elements for the electronic submission of information
The 'On-boarding of users to Substance, Product, Organisation and Referentials (SPOR) data services' document must be considered the reference guidance, as this document includes the
In medicinal products containing more than one manufactured item (e.g., contraceptive having different strengths and fixed dose combination as part of the same medicinal
Products Management Services (PMS) - Implementation of International Organization for Standardization (ISO) standards for the identification of medicinal products (IDMP) in
Products Management Services (PMS) - Implementation of International Organization for Standardization (ISO) standards for the identification of medicinal products (IDMP) in
This section provides guidance with examples on encoding medicinal product packaging information, together with the relationship between Pack Size, Package Item (container)
