You are on page 1of 26

5 de Ingeniera de Telecomunicaciones

ESTUDIO TECNOLGICO:

MEDIDA DEL RETARDO EN REDES IP

Autor: Alberto Castro Hinojosa Tutor: Ignacio Soto Campos

Medida del Retardo en Redes IP Alberto Castro Hinojosa

1 de 26

0- ndice
1- Introduccin.2 2- Motivacin4 3- Medidas Activas y Medidas Pasivas...8 3.1 Medidas Activas.8 3.2 Medidas Pasivas....................................9 4- One-Way Delay, Round Trip Time Delay y Jitter... 10 4.1 One-Way Delay (OWD)...............................................................11 4.2 Round Trip Time (RTT)..12 4.3 Jitter...13 5- Herramientas y mtodos para medir el retardo...14 5.1 Ping..............................................................................................14 5.2 Traceroute...................................................................................15 5.3 Netperf...17 5.4 SNMP17 5.5 Netflow e IPFIX....18 5.6 IPMP..20 5.7 One-Way Delay Protocol21 5.8 Monitorizacin de paquetes...21 6- Resumen...23 7- Bibliografa.24

Medida del Retardo en Redes IP Alberto Castro Hinojosa

2 de 26

1- Introduccin
Cuando se hace uso de una red IP, una pregunta que surge de manera natural es Cmo es de buena la red?, o dicho de otra forma, Cmo se puede medir y monitorizar la calidad de servicio que se ofrece a los clientes?. Con el aumento en la velocidad de acceso y con los servicios de banda ancha, hay asociada una expectacin por parte del usuario final sobre las prestaciones recibidas del servicio de Internet. Esa expectacin debera ser de mejora en algn aspecto, donde dicha mejora se refiere a las prestaciones de la red y del perfil de servicio que es ofrecido a las aplicaciones de red. Y no slo hay una expectacin de mejora de prestaciones, tambin deberan poder ser medidas. Una aproximacin informal a una definicin de prestacin de red es medir la velocidad de la red. Cmo es de rpida la red? O, Cunto tiempo ha transcurrido para una transaccin de red particular? O, Cmo de rpido puedo descargar un fichero? Esta medida de tiempo para completar una transaccin de red ciertamente describe la velocidad de la red, y la velocidad es una buena referencia para las prestaciones de red, pero Lo es todo la velocidad? Si miramos al amplio espectro de prestaciones, la respuesta es que la velocidad no lo es todo. La habilidad de una red para soportar transacciones que incluyen la transferencia de grandes volmenes de datos, as como la de soportar un gran nmero de transacciones simultneas, es tambin parte de las prestaciones de la red. Tambin deberan hacerse consideraciones sobre aplicaciones interactivas en tiempo real, que incluyen voz y video, y que sus requerimientos de prestaciones incluyen el retardo total entre sistemas finales, o latencia, as como la variacin de esa latencia, o jitter. Esta descripcin informal de lo que constituye las prestaciones de la red, parece estar en el camino correcto, dado que si conocemos la latencia, el ancho de banda disponible, las prdidas, el jitter y la probabilidad de reordenacin de paquetes como perfil de la prestacin de red entre dos puntos finales, as como las caractersticas de la transaccin de red, es posible hacer una prediccin razonable en relacin a la prestacin de la transaccin. Dados estos indicadores de prestaciones, el siguiente paso es determinar como esos indicadores pueden ser medidos y cmo las medidas resultantes pueden ser interpretadas. En este punto es til echar un vistazo a las numerosas y ms populares herramientas de medida y examinar su habilidad para proveer medidas tiles. Hay dos tipos bsicos de acercarse a esta tarea; una es recoger informacin de gestin desde elementos activos en la red usando un protocolo de gestin y con esta informacin realizar algunas inferencias sobre las prestaciones de la red. Esto puede ser determinado mediante tcnicas pasivas, que intentan medir las caractersticas de la red sin perturbar su operacin. La segunda aproximacin es usar mtodos activos e inyectar trfico de prueba en la red y medir sus prestaciones de alguna manera.

Medida del Retardo en Redes IP Alberto Castro Hinojosa

3 de 26

El objetivo de este estudio tecnolgico es realizar esta exploracin de tcnicas comnmente usadas centrndonos en el retardo en redes IP como indicador de prestaciones. El documento se organiza como sigue: en el siguiente captulo, se comienza hablando sobre la motivacin del estudio, el por qu tiene sentido realizar medidas del retardo en redes IP. En el captulo 3, se discutirn las ventajas y desventajas de los dos grupos tradicionales en que se clasifican la toma de medidas en redes: medidas activas y pasivas. El captulo 4 introduce los principales parmetros que se suelen medir en relacin al retardo: One-Way Delay, Round Trip Time Delay y Jitter. Se hablar de sus caractersticas, por qu interesa medirlos, etc. Finalmente navegaremos por alguna de las herramientas y protocolos ms famosos para obtener la latencia asociada a una red.

Medida del Retardo en Redes IP Alberto Castro Hinojosa

4 de 26

2- Motivacin
Una definicin del retardo, siguiendo [1], [2] y [3], es el tiempo trascurrido entre que la primera parte (ej. El primer bit) o un objeto (ej. Un paquete) pasa por un punto de observacin (ej. Donde el interfaz de tarjeta de red del ordenador se conecta al cable) y el tiempo en que la ltima parte (ej. El ltimo bit) u objeto relacionado (ej. Un paquete de respuesta) pasa por un segundo (puede ser el mismo) punto de observacin. Por qu es necesario medir el retardo? Tal y como se explica en [1] y en [2], el retardo es importante por varios motivos: Algunas aplicaciones no funcionan bien (o nada en absoluto) si el retardo entre los nodos finales es grande comparado con algn valor umbral. Hablaremos de estos temas un poco ms adelante. Variaciones irregulares en el retardo hacen difcil (o imposible) soportar muchas aplicaciones en tiempo real. Cuanto mayor es el valor del retardo, ms difcil es para los protocolos de la capa de transporte sostener altos anchos de banda. Si pensamos en TCP, si enviamos tantos segmentos como nos permita la ventana de transmisin, no podremos volver a enviar un segmento hasta que no recibamos el asentimiento (ack) generado por el destino, y esto depende del retardo entre otras cosas. El valor mnimo de esta mtrica provee una indicacin del retardo debido slo a los tiempos de propagacin y de transmisin. Es una medida que identifica al camino fsico ms que al nivel de congestin de la red. El valor mnimo de esta mtrica provee una indicacin del retardo que probablemente ser experimentado cuando el camino atravesado est ligeramente cargado. Probablemente todas las colas de los routers del camino estn casi vacas. Valores de esta mtrica por encima del mnimo provee una indicacin de la congestin presente en el camino.

El carcter Best Effort del protocolo IP hace que no pueda ofrecer garantas de rendimiento, ni retardo en la transmisin de los paquetes a su destino. Esto hace que la provisin de servicios con una calidad determinada sea, a priori, imposible. Por otro lado, las nuevas aplicaciones multimedia tienen requisitos de retardo y ancho de banda muy exigentes. Esto ha llevado a que se emprenda a lo largo de todo el mundo una intensiva labor en busca de mecanismos que, sin cambiar el actual protocolo de red, IP, permitan obtener de ste garantas que permitan desarrollar nuevos servicios con unas necesidades ms restrictivas que los existentes. Las aplicaciones multimedia generan y consumen caudales de datos continuos en tiempo real. stos contienen grandes cantidades de audio, vdeo y otros elementos de datos dependientes del tiempo, y resulta esencial el procesamiento y la entrega a tiempo de los elementos individuales de datos. Una especificacin de un caudal multimedia se expresa en trminos de valores aceptables para la tasa a la que los datos pasan desde la fuente al destino (ancho de banda), el retardo en la entrega de cada elemento (latencia) y la tasa

Medida del Retardo en Redes IP Alberto Castro Hinojosa

5 de 26

a la que se pierden o se desechan los elementos. La latencia es particularmente importante en aplicaciones interactivas. En las aplicaciones multimedia a menudo resultan aceptables un grado pequeo de perdida de datos de los caudales multimedia ya que las aplicaciones pueden volver a sincronizarse con los elementos que siguen a aquellos perdidos. Las aplicaciones multimedia demandan la entrega a tiempo a los usuarios de caudales de datos multimedia. Los caudales de audio y vdeo se generan y se consumen en tiempo real, la entrega a tiempo de los elementos individuales es esencial para la integridad de la aplicacin. En resumen, los sistemas multimedia son sistemas de tiempo real: deben ejecutar tareas y entregar sus resultados de acuerdo de una planificacin que es determinada externamente. Algunas de estas aplicaciones utilizadas en redes actuales sin QoS y basados en el principio del mejor esfuerzo son: Multimedia basado en Web: estas aplicaciones proporcionan acceso segn el mejor esfuerzo a caudales de audio y vdeo publicados en la Web. Han tenido xito cuando existe poca o ninguna sincronizacin de los caudales de datos entre diferentes localizaciones. Sus prestaciones estn restringidas por el limitado ancho de banda y por las latencias variables que se dan en las redes actuales y por la imposibilidad de los sistemas operativos actuales para soportar una planificacin de tiempo real de los recursos. En el caso de audio y de las secuencias de audio y vdeo de baja calidad, la utilizacin extensiva de almacenamiento en el destino para suavizar las variaciones en el ancho de banda y en la latencia hace que se puedan reproducir secuencia de vdeo de forma continua y sin sobresaltos, aunque exista un retardo desde el origen al destino hasta varios segundos. Telefona de red y conferencias de audio: esta aplicacin tiene unos requisitos de ancho de banda relativamente bajos, especialmente cuando se aplican tcnicas de compresin eficiente. Aunque la naturaleza interactiva de la misma implica tiempos de ida y vuelta pequeos, algo que no siempre se puede conseguir. Servicio de vdeo bajo demanda: stos proporcionan vdeo en formato digital desde grandes sistemas de almacenamiento hasta la herramienta de visualizacin del usuario. Resultan satisfactorios cuando existe suficiente ancho de banda dedicado, y tanto el servidor como el cliente son computadores dedicados. Tambin emplean una cantidad considerable de almacenamiento en el destino.

Las aplicaciones altamente interactivas plantean problemas muchos ms graves. Muchas aplicaciones multimedia son cooperativas (involucran muchos usuarios) y sincronizadas (requieren que las actividades de los usuarios estn coordinadas). Las aplicaciones como estas (videoconferencia, etc.) requieren: Conmutacin con baja Latencia: En aplicaciones de conferencia, la necesidad de interacciones aparentemente instantneas entre los participantes hacen necesario que los retardos extremo a extremo no sean mayores de 150ms, para evitar problemas en la percepcin

Medida del Retardo en Redes IP Alberto Castro Hinojosa

6 de 26

humana de la conversacin, mientras que en la reproduccin de video almacenado, para asegurar que el sistema responda adecuadamente a ordenes como Pausa y Parada, la latencia mxima debera ser entorno a 500ms. Estado de sincronizacin distribuida: Si un usuario detiene un vdeo en un determinado marco, los otros usuarios deberan ver el vdeo parado en el mismo marco. Sincronizacin de medios: Todos los participantes en una actuacin musical deberan escuchar la ejecucin aproximadamente a la vez (identifica como requisito de sincronizacin un intervalo de 50ms). La banda sonora y el caudal de vdeo deberan mantener la sincronizacin de labios, por ejemplo, para un usuario haciendo comentarios en una reproduccin de vdeo o en una sesin distribuida de karaoke. Sincronizacin externa: en conferencias o en otras aplicaciones cooperativas, pueden existir datos activos en distintos formatos, tales como animaciones generadas por computador, datos CAD, pizarras electrnicas y documentos compartidos.

Una tercera consideracin con respecto al tiempo de entrega de los mensajes multimedia es la fluctuacin o jitter (variacin en el periodo entre la entrega de dos marcos adyacentes). Mientras la mayora de los dispositivos multimedia producen datos a su tasa regular sin variacin, las herramientas software (por ejemplo un decodificador software para marcos de video) necesitan ser cuidadosas para descartar la fluctuacin. La fluctuacin se elimina utilizando almacenamiento previo (buffering). Hablemos un poco de VoIP como ejemplo de la importancia de la latencia en las redes [5]. Aunque la telefona IP es principalmente usada en aplicaciones para reduccin de costes, debera tener una calidad de voz aceptable. Qu se considera como calidad aceptable en una llamada VoIP? Al tratar con factores humanos, cada uno tiene su propia opinin en este asunto. Sin embargo, hay definido un lmite de degradacin de la calidad que ser tolerado por los usuarios. Muchos factores influyen en la totalidad de la calidad de voz extremo a extremo en las llamadas de VoIP. Si los factores son adecuadamente controlados, permiten ajustar los presupuestos de retardo para una determinada calidad de voz. Gestionar el retardo es clave para que los servicios VoIP tengan xito. Una relacin entre retardo y otros factores como son el eco y las prdidas deberan ser estudiadas para gestionar el presupuesto de retardo. La norma ITU-T G.114 hace una recomendacin sobre el retardo one-way lmite de 150ms. Tambin son usados otros modelos, como el modelo E, para evaluar la calidad de la conversacin en la transmisin extremo a extremo en las redes VoIP. La figura 1 muestra el modelo E, evaluando el parmetro R en categoras de calidad de transmisin en y satisfaccin del usuario. R por debajo de 50 indica una calidad inaceptable. Todas las conexiones por debajo de R=70, sufrirn de una combinacin entre distorsin y alto retardo. La regin entre R=50 y R=70 abarca las categoras de Muchos usuarios insatisfechos y la de Casi todos los usuarios insatisfechos, obteniendo la calidad ms baja. Para una aceptable calidad, el lmite inferior es R=70. La figura 1 ilustra el

Medida del Retardo en Redes IP Alberto Castro Hinojosa

7 de 26

asunto comparando las curvas del mejor caso para tres populares codecs IP (G.711, G.729A y G.723.1 son recomendaciones ITU-T).

Figura 1. Modelo E

Cunto retardo es demasiado? El retardo no afecta a la calidad de la conversacin directamente, pero afecta al ritmo o carcter de la misma. Con valores por debajo de 100ms, la mayora de los usuarios no aprecian el retardo, entre 100ms y 300ms, los usuarios notan una ligera duda en la respuesta de la otra persona. Por encima de 300ms, el retardo es obvio entre los integrantes de una conversacin y empiezan ceder el turno para hablar para prevenir interrupciones. Podramos seguir hablando de distintas aplicaciones que necesitan un retardo moderado para un correcto funcionamiento. Es por eso que, para los operadores de red, por ejemplo, es imprescindible tener un mecanismo de monitorizacin de la red para identificar problemas y ver cul es el estado del servicio que se ofrece a los usuarios. Un usuario con no demasiados conocimientos informticos o telemticos tambin puede utilizar herramientas sencillas para controlar el retardo de sus aplicaciones o de la red de acceso. De todos estos temas, surge el inters por hacer un estudio sobre la medida del retardo en redes IP.

Medida del Retardo en Redes IP Alberto Castro Hinojosa

8 de 26

3- Medidas Activas y Medidas Pasivas


Internet ha estado creciendo rpidamente con respecto al nmero de usuarios y a la cantidad de trfico y ha sido reconocida como una importante infraestructura de la informacin para uso social y de negocios. As, aunque inicialmente la cuestin principal ha sido la capacidad de conexin y de transmisin, se ha prestado tambin atencin recientemente a la calidad. Como hemos visto, el trfico que circula por Internet es generado por una amplia variedad de aplicaciones, las cuales tienen diferentes caractersticas y diferentes requerimientos de calidad. Entonces, las medidas de la calidad de servicio (QoS) y de las prestaciones son cruciales para controlar y gestionar el aprovisionamiento de las redes. Sin embargo, es difcil o caro medir estadsticas de QoS y prestaciones de cada flujo directamente. Recientemente, muchas herramientas de monitorizacin han sido desarrolladas para medir las prestaciones de la red [7], [8], [9] y las medidas resultantes tambin han sido reportadas. En general, los esquemas convencionales de monitorizacin para medir la QoS y las prestaciones de la red, se clasifican en dos tipos: monitorizacin activa y monitorizacin pasiva. Desafortunadamente, ambos tipos tienen sus desventajas. 3.1 Medidas Activas La monitorizacin activa consiste en probar directamente las propiedades de la red generando el trfico necesario para realizar la medida. Esto permite utilizar mtodos de anlisis mucho ms directos, pero tambin presenta el problema de que el trfico introducido puede tener un impacto negativo en las prestaciones recibidas por otros tipos de trfico. Hay varios mtodos activos para medir prestaciones de red tales como el ancho de banda disponible, el retardo, las prdidas y para estimar las caractersticas enlace por enlace. Monitorizan la QoS del flujo de paquetes prueba para determinar la QoS de los usuarios indirectamente. Esto implica que asumimos implcitamente que la QoS de un usuario es la misma que los valores medidos con los paquetes de prueba. Analicemos un poco ms las desventajas: Si usamos un flujo de paquetes de prueba que simula el trfico actual del usuario: o El flujo de paquetes de prueba produce una no despreciable cantidad de trfico extra en la red y esto afecta a la QoS/prestaciones del trfico de usuarios. o La QoS/prestaciones obtenidas de los paquetes de pruebas no es igual a la obtenida sin la influencia del flujo de paquetes de prueba. Si usamos paquetes pequeos de prueba y los enviamos en ciertos intervalos, como ping:

Medida del Retardo en Redes IP Alberto Castro Hinojosa

9 de 26

o El trfico extra puede ser despreciable, pero la QoS/prestaciones obtenidas desde el paquete de prueba no es igual a las experimentadas por los usuarios, en general. o Puede ser catalogado como trfico hostil o intento de ataque. Por ejemplo, algunos routers rechazan trfico ICMP o limitan su tasa, por si se trata de un intento de spoofing, etc. 3.2 Medidas Pasivas Las medidas pasivas dependen completamente de la presencia del trfico apropiado en la red bajo estudio, y tiene la considerable ventaja de que pueden ser realizadas sin afectar al trfico que lleva la red durante el perodo de medida. Sin embargo, puede ser mucho ms difcil o imposible extraer alguna de la informacin deseada desde los datos disponibles. La monitorizacin pasiva se puede clasificar en dos tipos: monitorizacin en dos puntos y monitorizacin en un punto. La monitorizacin en dos puntos requiere dos dispositivos de medida desplegados en los puntos de acceso y salida de la red. Estos dispositivos, toman paquetes de datos de forma secuencial y los parmetros de prestaciones de la red como el retardo o las prdidas pueden ser calculados comparando los datos de los correspondientes paquetes tomados en cada punto. Si aplicamos la monitorizacin de dos puntos como medida de QoS/prestaciones: o Todos los dispositivos deberan estar sincronizados en el tiempo. o Requiere identificar cada paquete en los dos dispositivos por su cabecera y/o contenido. Este proceso de identificacin puede ser tremendamente difcil cuando el volumen de paquetes es enorme, como en redes de gran escala, y este tipo de monitorizacin no es escalable. o Para identificar los paquetes monitorizados, debemos recoger todos los paquetes de datos. Este proceso requiere un no despreciable ancho de banda. La monitorizacin de un punto usa el mecanismo de asentimiento de TCP. Cuando se recibe un segmento TCP desde una fuente, se transmite un paquete de asentimiento para ese segmento. Entonces, monitorizando este par de paquetes en un punto de la red, podemos medir el retardo Round Trip Time entre ambos puntos. Los paquetes perdidos tambin pueden ser detectados de esta forma. Sin embargo, si aplicamos este tipo de monitorizacin, las medidas estn restringidas a flujos TCP. Si conseguimos extraer la informacin de inters de las medidas realizadas, entonces esa informacin es libre, en el sentido de que no hemos necesitado introducir ningn tipo de trfico para conseguirla, siendo adems, ms cercanas a las prestaciones que el usuario realmente recibe de la red, pues se trata de trfico real.

Medida del Retardo en Redes IP Alberto Castro Hinojosa

10 de 26

4- OneWay Delay, Round Trip Time Delay y Jitter


Antes de presentar herramientas para caracterizar el retardo, debemos dar algunas definiciones sobre los parmetros que habitualmente se asocian a esta medida: One-Way Delay, Round Trip Time Delay y la variacin del retardo o jitter. Comenzaremos dando dicha definicin general para luego adentrarnos un poco ms en cada parmetro. El One-Way Delay (figura 2) desde una fuente a un destino en el tiempo T es dT si la fuente enva el primer bit de un paquete al destino en el tiempo T y el destino recibe el ltimo bit del paquete en el tiempo T + dT ([1]).
T + dT

RED

Figura 2. One - Way Delay

El Round Trip Time Delay (figura 3) desde una fuente a un destino en el tiempo T es dT si la fuente enva el primer bit de un paquete en el tiempo T, el destino recibe el paquete e inmediatamente enva una respuesta hacia la fuente y el destino recibe el ltimo bit del paquete respuesta en T + dT ([2]).

RED
T + dT
Figura 3. Round Trip Time Delay

Una definicin de variacin del retardo de paquetes IP (ipdv o jitter) puede ser dada para los paquetes dentro de un flujo [12]. El jitter entre un par de paquetes dentro de un flujo desde un punto de medida origen a otro destino se define como la diferencia entre el one-way delay de los paquetes seleccionados.

Medida del Retardo en Redes IP Alberto Castro Hinojosa

11 de 26

4.1 One-Way Delay (OWD) Segn [1], el uso de del One-Way Delay en lugar del Round Trip Time Delay est motivado por los siguientes factores: Hoy en da en Internet el camino desde una fuente a un destino puede ser diferente que el camino desde el destino a la fuente (caminos asimtricos), debido a diferentes secuencias de routers usados en ambos sentidos. De hecho, la medida del Round Trip Time realmente mide las prestaciones de dos caminos distintos juntos. Midiendo cada camino independientemente se resalta la diferencia de prestaciones entre los dos caminos que pueden atravesar diferentes proveedores de Internet, y tener totalmente diferentes tipos de redes (por ejemplo, ATM vs. paquetes sobre SONET). Aunque los dos caminos sean simtricos, pueden tener diferentes tipos de prestaciones debido al carcter asimtrico de las colas. Las caractersticas de una aplicacin puede depender en su mayor parte de las prestaciones en un sentido. Por ejemplo, una transferencia de ficheros usando TCP puede depender ms de las prestaciones del camino en el que fluyen los datos, ms que en el sentido en que viajan los asentimientos. En redes que proporcionan calidad de servicio (QoS), el aprovisionamiento en un sentido puede ser radicalmente distinto al del sentido inverso, y entonces la QoS es diferente. Midiendo ambos caminos independientemente permite verificar ambas garantas de calidad.

Como los valores de la latencia pueden ser a menudo tan pequeos como el rango desde 100 microsegundos hasta 10 milisegundos, es importante que la fuente y el destino estn muy bien sincronizados. Los sistemas GPS ofrecen entre ambos extremos una sincronizacin desde decenas de segundos hasta microsegundos. Una aplicacin ordinaria de NTP puede permitir una sincronizacin dentro de varios microsegundos, pero esto depende de la estabilidad y simetra de las propiedades de latencia entre los agentes NTP usados, y esta es la latencia que estamos intentando medir. Una combinacin entre algunos servidores NTP basados en GPS y otro conjunto diseados de forma conservadora de agentes NTP deberan dar buenos resultados. Uno de los famosos problemas con el uso de GPS era que los ordenadores estn normalmente situados dentro de habitaciones, y una seal GPS clara est normalmente disponible slo en el tejado. Implementaciones posteriores han usado el reloj asociado con redes telefnicas mviles CDMA como mtodo para tener fuentes de reloj distribuidas, altamente precisas y sincronizadas, con la ventaja de que la seal de tiempo est normalmente disponible cerca del punto de medida. La descripcin de cualquier mtodo especfico de medida debera incluir un anlisis de las fuentes de error e incertidumbre. Entre las ms relevantes, en este caso cabe resear:

Medida del Retardo en Redes IP Alberto Castro Hinojosa

12 de 26

Errores e incertidumbres debidas a los relojes de la fuente y el destino: Cualquier error en la sincronizacin entre los relojes de la fuente y el destino contribuir al error de la medida de la latencia. Si conocemos el valor exacto de dicho error, deberamos corregir la medida. La resolucin de un reloj aade incertidumbre sobre cualquier medida realizada con l. As, si el reloj de la fuente tiene una resolucin de 10ms, entonces aade 10ms de incertidumbre para cualquier valor medido. En las medidas One-Way Delay, tendremos en cuenta la resolucin de la fuente y el destino.

4.2 Round Trip Time Delay (RTT) Segn [2], las ventajas del uso del One-Way Delay de las que habbamos en el punto anterior, pueden verse como las principales debilidades del uso del RTT. Por otra parte, medir el RTT tiene dos ventajas especficas: Facilidad de despliegue: a diferencia de las medidas de OWD, a menudo es posible realizar las medidas de RTT sin instalar software especfico para medir en el destino. Una variedad de aproximaciones son bien conocidas, incluyendo el uso de ICMP (Echo) o metodologas basadas en TCP. Sin embargo, algunos mtodos pueden introducir un grado de incertidumbre en el tiempo en el que el destino produce la respuesta. Facilidad de interpretacin: en algunas circunstancias, el RTT es de hecho la magnitud de inters. Deducir el RTT a partir de OWD puede ser potencialmente menos preciso. Muchas aplicaciones han adoptado el RTT entre host como herramienta bsica para aproximar distancia y estimar la localizacin de los host en Internet [10]. Por ejemplo, Napster es una aplicacin para compartir archivos peer-to-peer. Cuando los usuarios de Napster buscan un archivo, Napster devuelve una lista con los enlaces que albergan dicho archivo y otra lista con los RTTs entre el usuario y cada destino. El usuario debera entonces intentar descargar primero desde el enlace con menor RTT.

El RTT en una conexin en la capa de transporte juega un papel central en el comportamiento de la conexin [11]. Primero, un protocolo de transporte fiable como TCP necesita decidir cunto tiempo esperar por un asentimiento de datos que han sido enviados antes de retransmitir los datos. Hay un compromiso entre esperar el tiempo suficiente para asegurar que el protocolo no retransmite innecesariamente, frente a no esperar demasiado cuando de hecho la retransmisin es necesaria. La segunda forma en el que el RTT influye en el comportamiento de la conexin es la nocin del producto ancho de banda latencia (BDP). El BDP de una conexin es el producto del ancho de banda disponible, medido en bytes/segundo, con el RTT, medido en segundos. El resultado es un nmero de bytes que indica cuntos datos en la conexin han de estar circulando para utilizar completamente el ancho de banda disponible. Debemos, sin embargo, hacer una distincin crucial entre esos dos diferentes roles del RTT dentro del comportamiento de una conexin. Para el primer rol,

Medida del Retardo en Redes IP Alberto Castro Hinojosa

13 de 26

regular las retransmisiones, el RTT de inters es el mximo RTT. Para el segundo rol, es el mnimo RTT. En cuanto a los errores e incertidumbres en la medida del RTT: Mientras que en OWD la sincronizacin entre los relojes de la fuente y el destino es un problema, en las medidas de RTT es ms sencillo, pues el reloj utilizado es el mismo, el de la fuente, estando pues auto sincronizado. El problema de la resolucin, en cambio, si est presente. 4.3 Jitter La variacin en el retardo de los paquetes se llama a menudo jitter. Este trmino, sin embargo, produce confusin porque es usado de diferentes formar por diferentes grupos de personas. Jitter, en este estudio tecnolgico, tiene el significado de variacin de una mtrica (por ejemplo el retardo) con respecto a alguna mtrica de referencia (por ejemplo el retardo medio o el mnimo). Un importante uso de la variacin del retardo es el dimensionado de buffers para aplicaciones que requieren de la entrega regular de paquetes (por ejemplo voz o video). Lo que normalmente es importante en este caso es el jitter mximo, que es usado para calcular el tamao del buffer de tales aplicaciones. Otros usos de esta mtrica son, por ejemplo, determinar la dinmica de las colas dentro de una red (o router) donde los cambios en el jitter pueden estar debidos a cambios en la longitud de la cola en el enlace dado o en una combinacin de enlaces. Adems, este tipo de mtrica es particularmente robusta con respecto a diferencias y a variaciones de los relojes de los dos hosts. Esto permite el uso del jitter an cuando los dos puntos de medida no estn sincronizados. Adems, dado un flujo de medidas de latencia, el jitter es bastante fcil de obtener.

Medida del Retardo en Redes IP Alberto Castro Hinojosa

14 de 26

5- Herramientas y mtodos para medir el retardo


En este captulo presentar alguna pequea coleccin de herramientas, mtodos, protocolos, etc., tanto pasivos como activos, que pueden ser utilizados para obtener el retardo (entre otras cosas). El nmero de herramientas es bastante grande, por lo que se siempre se puede profundizar obteniendo ms mtodos en la bibliografa recomendada. 5.1 Ping El ping es la ms sencilla de todas las aplicaciones TCP/IP. Enva uno o ms datagramas (mtodo activo, por lo tanto) a un host de destino determinado solicitando una respuesta y mide el tiempo que tarda en retornarla. La palabra ping, que puede usarse como nombre o como verbo (en ingls), procede de la operacin de snar empleada para localizar un objeto submarino. Tambin es un acrnimo de Packet InterNet Groper. Tradicionalmente, si podas hacer un ping a un host, otras aplicaciones como Telnet o FTP podan comunicarse con ese host. Con el advenimiento de las medidas de seguridad en Internet, particularmente los cortafuegos ("firewalls"), que controlan el acceso a redes a travs del protocolo de aplicacin y/o el nmero de puerto, esto ha dejado de ser estrictamente cierto. An as, el primer test para comprobar si es posible alcanzar un host sigue siendo intentar hacerle un ping. Ping usa los mensajes Eco y Respuesta al Eco ("Echo Request", "Echo Reply") de ICMP. Ya que se requiere ICMP en cada implementacin de TCP/IP, a los hosts no les hace falta un servidor separado para responder a los pings. El RTT es calculado como la diferencia entre el tiempo en el que el echo request es enviado y el tiempo de la correspondiente respuesta es recibida por la aplicacin ping. Una variacin de este mtodo es construir un paquete request ICMP con la marca de tiempo [13]. Este paquete contiene tres marcas de tiempo: origen, recibida y transmitida. Si los hosts implicados tienen en el intercambio de marcas de tiempo tienen los relojes sincronizados, el retardo del camino directo puede ser calculado usando las marcas de tiempo origen y recibida. El retardo del camino de retorno puede ser calculado usando la marca de tiempo transmitida contenida en el paquete respuesta y el tiempo en el que el paquete respuesta llega al transmisor. En la figura 4 podemos observar como tambin se proporcionan los RTT mnimos, medios y mximos.

Figura 4. Ejemplo de salida mostrada por ping.

Medida del Retardo en Redes IP Alberto Castro Hinojosa

15 de 26

Cabe destacar, que pueden producirse algunos resultados anmalos debidos a bloqueos para acceder al servidor o tener limitada la tasa de acceso, para evitar problemas de seguridad (podramos ver la tasa de paquetes perdidos para comprobar esto). As que no estara de ms comprobar las medidas del RTT con otras basadas en TCP. Una herramienta equivalente a ping en la capa de transporte es echoping [14], utilidad que prueba los host remotos conectndose al servicio echo. Es capaz de probar conexiones UDP y TCP y adems puede emitir una peticin HTTP para probar la disponibilidad de un servidor Web. Al ser una implementacin del nivel de aplicacin el servicio echo, algunos retardos extra se introducen en los tiempos de respuesta. 5.2 Traceroute Traceroute es una herramienta que combina muy inteligentemente, dos caractersticas de los protocolos que hacen posible Internet: TTL o expiracin de los paquetes e ICMP. Para proteger a Internet del efecto de paquetes atrapados en ciclos de enrutamiento, los diseadores de TCP/IP dotaron a cada datagrama IP de un contador al que llamaron TTL por las siglas de Time To Live. Esto es un nmero que limita cuntos saltos puede dar un datagrama, antes de ser descartado por la red. Cuando se introduce un datagrama IP a la red, el campo TTL es poblado con el nmero mximo de saltos que define la vida de ese datagrama. Cada enrutador por el que ese datagrama transita, resta uno a ese nmero. Cuando ste llega a cero, el datagrama es descartado. Los paquetes ICMP sirven para muchas cosas: avisar que un enlace o que un dispositivo estn congestionados, que se escogi un camino sub-ptimo para enviar un paquete, que no se puede acceder a un sitio en particular, etc. Uno de esos avisos es particularmente til para traceroute: el aviso de que se excedi la vida til del paquete. Combinando estas dos herramientas, traceroute permite construir un mapa de la red de acuerdo como es vista desde un nodo en particular.

Figura 5. Ejemplo de salida mostrada por traceroute.

Medida del Retardo en Redes IP Alberto Castro Hinojosa

16 de 26

En la figura 5 se muestra cada uno de los saltos que tiene que dar un paquete al recorrer el camino desde la direccin de host 213.190.0.6 hasta www.uc3m.es. La direccin del recorrido es muy importante, porque en Internet no necesariamente el camino de ida es igual al de regreso. La cantidad de saltos puede dar una idea de la complejidad de la red. Para cada salto, que traceroute numera en la primera columna, se envan tres paquetes (UDP) con un TTL que se va incrementando progresivamente. El nombre del nodo que responde, bien sea indicando que se lleg al destino o que el paquete expir en trnsito, se muestra junto a los tiempos transcurridos entre el envo del paquete y la recepcin de la respuesta. Eso nos da una idea de cmo es la condicin de la red en ese salto o en alguno de los anteriores.

Figura 6. Mecanismo utilizado por traceroute.

La figura 6 permite ver mejor cmo funciona la herramienta. En el primer salto, hacia el nodo 1, traceroute pone el valor TTL en 1 y enva el paquete hacia el nodo de destino. Cuando el nodo 1 decrementa el valor del TTL y obtiene un cero, devuelve al nodo de origen un mensaje de error que dice que el TTL expir mientras el paquete iba en trnsito. Este proceso se repite varias veces y los tiempos se registran. Para el siguiente salto, traceroute aumenta en uno el valor del TTL y lo enva de nuevo hacia su destino. El nodo 1 decrementa el valor del TTL a uno y pasa el paquete hacia el nodo 2. El nodo 2 recibe el paquete con TTL uno y al decrementarlo, obtiene un TTL cero, enviando el correspondiente mensaje de error hacia el nodo de origen. Este proceso se va repitiendo con valores progresivamente ms grandes de TTL, para ir encontrando los saltos cada vez ms lejanos o hasta que se llega a un TTL muy grande. Tpicamente este valor mximo es 30, aunque puede ser de hasta 255. Una herramienta que usa el mismo mecanismo que traceroute es pathchar, sin embargo fue diseada para un propsito diferente. Estima las prestaciones de cada host a lo largo de un camino desde una fuente a un destino. Enva una serie de paquetes UDP de varios tamaos a cada router (incrementando el TTL) y recoge informacin de cada salto de forma incremental. Usando el conocimiento de los anteriores saltos y la distribucin del RTT en este salto, pathchar estima el ancho de banda, la latencia, prdidas y las caractersticas de la cola en este salto. Sin embargo, como pathchar hace mucho esfuerzo para caracterizar el camino de forma muy precisa, tiene una serie de desventajas, por lo que no es muy

Medida del Retardo en Redes IP Alberto Castro Hinojosa

17 de 26

popular. Primero, porque tarda mucho en ejecutarse, y segundo porque altera mucho el estado de la red al introducir muchos paquetes de prueba. 5.3 Netperf Netperf es una herramienta que puede ser usada para medir varios aspectos de las prestaciones de las redes. Realiza tests para obtener el throughput unidireccional y la latencia extremo a extremo. Usa tanto TCP como UDP sobre el ampliamente aceptado interfaz socket de Berkeley. Netperf consiste en dos partes ejecutables: netserver es la parte servidora que puede actuar manualmente o va inetd, y netperf es la parte cliente. Ejecutando netperf, una conexin TCP de control es establecida entre los dos host para negociar los parmetros de configuracin del test. Durante el test, el canal de control est activo, pero no se usa. La medida de prestaciones del flujo suele ser determinar la mxima tasa de transferencia de un flujo TCP o UDP dados. Esta medida puede ser fcilmente calculada dividiendo los bytes transmitidos con el tiempo transcurrido. La prestacin de la transaccin est de cierta manera relacionada con la medida de la latencia. Durante este test, los paquetes de usuario con carga til (1 byte por defecto) son transmitidos dentro de la red y una respuesta es generada por el receptor. La tasa de transaccin se expresa entonces como el cociente entre el nmero de transacciones entre el tiempo transcurrido. 5.4 SNMP SNMP (Simple Network Management Protocol) es el protocolo definido por los comits tcnicos de Internet para ser utilizado como una herramienta de gestin de los distintos dispositivos en cualquier red. El funcionamiento de SNMP es sencillo, como dice el protocolo, aunque su implementacin es tremendamente compleja. SNMP utiliza la capa de transporte de TCP/IP mediante el envo de datagramas UPD, sin embargo, el hecho de usar UDP hace que el protocolo no sea fiable (en UDP no se garantiza la recepcin de los paquetes enviados, como en TCP). SNMP se basa en un conglomerado de agentes. Cada agente es un elemento de la red que ofrece unas determinadas variables al exterior, para ser ledas o modificadas. Asimismo, un agente puede enviar "alertas" a otros agentes para avisar de eventos que tengan lugar. Generalmente se llama "gestor" al agente encargado de recibir estos eventos. El esquema es sencillo, sin embargo su complejidad se incrementa a la hora de definir las variables (y su formato). Las variables ofrecidas para consulta por los agentes SNMP se definen a travs de una MIB (Management Information Base, Base de Informacin de Gestin). La MIB (hay slo una aunque existen mltiples extensiones a sta) es una forma de determinar la informacin que ofrece un dispositivo SNMP y la forma en que se representa. La MIB actual es MIB-II y est definida en el RFC 1213, aunque hay mltiples extensiones definidas en otros RFCs.

Medida del Retardo en Redes IP Alberto Castro Hinojosa

18 de 26

Cada agente SNMP ofrece informacin dentro de una MIB, tanto de la general (definida en los distintos RFCs) como de aquellas extensiones que desee proveer cada uno de los fabricantes. As, los fabricantes de routers han extendido las MIBs estndar incluyendo informacin especfica de sus equipos. Qu se puede hacer con SNMP? Con SNMP se puede monitorizar el estado de un enlace punto a punto para detectar cuando est congestionado y tomar as medidas oportunas, se puede hacer que una impresora alerte al administrador cuando se ha quedado sin papel, o que un servidor enve una alerta cuando la carga de su sistema incrementa significativamente. SNMP tambin permite la modificacin remota de la configuracin de dispositivos, de forma que se podra modificar las direcciones IP de un ordenador a travs de su agente SNMP, u obligar a la ejecucin de comandos (si el agente ofrece las funcionalidades necesarias).

Figura 7. Simulacin del retardo en colas.

El retardo en las colas (figura 7) es un desafo en cuanto a su medida basada en polling con SNMP elemento a elemento. En teora, el sistema de polling podra usar una rpida secuencia para interrogar a la cola de salida y estimar el retardo de la cola basndose en el tamao medio del paquete, junto con el conocimiento de la capacidad disponible de salida. Por supuesto, dicha metodologa de medida asume una simple cola FIFO, un tamao de la cola que vara lentamente con el tiempo y enlaces lentos. Dichas afirmaciones se cumplen raramente hoy en da en las redes IP. Al aumentar la velocidad del enlace, el tamao de la cola puede oscilar con relativa alta frecuencia en funcin del nmero y capacidad de los sistemas de entrada y la capacidad de los sistemas de salida. En general, el retardo de las colas no se puede medir fcilmente usando elementos que hacen uso del polling. 5.5 Netflow e IPFIX Netflow [16], tecnologa desarrollada por CISCO Systems en 1996, permite mejorar la capacidad de encaminamiento de sus routers. Siguiendo la filosofa encaminar una vez, conmutar muchas veces, identifica los flujos establecidos entre mquinas con el fin de agilizar el encaminamiento de futuros paquetes IP.

Medida del Retardo en Redes IP Alberto Castro Hinojosa

19 de 26

Para un router, un flujo de datos est constituido por un conjunto de paquetes IP con una misma combinacin de atributos (direcciones y puertos origen y destino, tipo de protocolo de transporte, tipo de servicio e interfaz de entrada) en un intervalo de tiempo. Cuando se detecta un nuevo flujo, Netflow guarda en la memoria interna la correspondencia entre el flujo y su interfaz de salida, de forma que para posteriores paquetes a consultas en sus tablas de encaminamiento, ahorrando de este modo, valiosos ciclos de CPU. Precisamente, esta capacidad de los dispositivos de encaminamiento de obtener informacin referente a los flujos cursados puede ser aprovechada para medir y caracterizar el trfico que atraviesa el router prcticamente en tiempo real, y ello de una manera convenientemente agregada facilita el anlisis de la calidad de servicio. Con el fin de ocupar el vaco existente en la definicin de mtricas que especifiquen de una manera formal el rendimiento de redes IP, el IETF organiz, en el ao 1998, un grupo de trabajo denominado IP Performance Metrics (IPPM) [17], encargado de formalizar parmetros que permitieran tanto a usuarios como proveedores de red cuantificar el estado de sus servicios de red. Si bien el grupo de trabajo IPPM define claramente aquellas mtricas tiles en la caracterizacin de calidad de servicio QoS, no precisa el modo de obtencin de dichas mtricas. Numerosas iniciativas como RMON [18], RTFM [19], PSAMP [20], Sflow [21] o IPFIX abordan la implementacin prctica de mtodos de adquisicin de medidas de calidad de servicio. RMON tiene problemas de interoperabilidad y la tecnologa PSAMP no est actualmente implementada en routers. Mediante el empleo de tcnicas pasivas de anlisis como IPFIX se puede disponer de una arquitectura no intrusiva e interoperable para calcular mtricas de calidad de servicio. El hecho de ser un mtodo pasivo permite disponer de numerosos puntos de medida sin que el trfico de datos se vea afectado, mientras que el hecho de ser interoperable contribuye a que diversos operadores puedan colaborar entre s para recabar informacin relacionada con sus enlaces y el trfico intercambiado entre ellas. Otra propiedad inherente a las tcnicas de anlisis basadas en flujos (IPFIX) es la de caracterizar el tipo de trfico cursado por los usuarios finales, lo cual facilita el desarrollo de metodologas de estimacin de QoS orientadas a la percepcin del usuario de los servicios de red. Un posible mtodo de estimacin del OWD consiste en disponer de dos o ms dispositivos IPFIX, normalmente routers, con la misma base de tiempos ya sea mediante sistemas GPS o mediante protocolos como NTP, siendo el primero capaz de asegurar precisiones del orden de nanosegundos y del orden de milisegundos el ltimo. De este modo es posible inferir el tiempo transcurrido entre el primer punto de medida y el ltimo, definiendo de este modo un estimador directo del retardo unidireccional. Mediante tcnicas de anlisis de flujos tambin es factible definir estimadores aproximados que permitan cuantificar la variacin en el retardo unidireccional (o jitter).

Medida del Retardo en Redes IP Alberto Castro Hinojosa

20 de 26

5.6 IPMP Actualmente, no hay un camino apropiado para realizar medidas en Internet que dividan el retardo en las componentes referidas a las diferentes partes de la red y sus usuarios. Se ha propuesto un nuevo protocolo (IP Measurement Protocol, IPMP [22]) que permite a los dispositivos de Internet insertar marcas de tiempo en los datos segn pasan por la red, creando una auditoria para los datos de Internet. Este seguimiento es medido en milsimas de segundo y debe ser creado a una velocidad que permita a los cientos de millones de paquetes que circulan por la red ser procesados cada segundo. Se espera que este protocolo les de a los usuarios, operadores de red y proveedores de servicio Internet un leguaje comn con el que comunicar los asuntos referidos a las prestaciones, validar las reclamaciones y competir entre ellos. El protocolo IPMP est basado en el intercambio de paquetes echo request y echo reply para medir el retardo de los paquetes y las mtricas asociadas, siendo similar a las tcnicas que ping usa con las propiedades de ICMP. El paquete echo reply ha sido diseado para que un host remoto pueda construir dicho paquete con muy pocas modificaciones respecto al echo request. El formato del paquete puede observarse en la figura 8.

Figura 8. Formato IPMP Echo Request.

La mayor diferencia entre IPMP y otros protocolos basados en echo es la introduccin del campo IPMP path record. Cada registro de camino requiere 12 bytes de datos para ser almacenados en el paquete IPMP. Los primeros 4 bytes del registro de camino representan la direccin IPv4 del interfaz de red por el que el paquete IPMP fue recibido. Los ltimos 8 bytes del registro es una representacin del tiempo (los primeros 4 bytes es la parte entera de la marca de tiempo, los segundos 4 bytes una fraccin). Adems de la habilidad de inferir el retardo extremo a extremo restando el tiempo en el que el paquete fue enviado del tiempo en el que fue recibido, los paquetes echo request pueden ser usados para deducir la longitud del camino

Medida del Retardo en Redes IP Alberto Castro Hinojosa

21 de 26

en saltos para cada direccin, y el one-way delay si el host destino inserta un path record cuando responde a un echo request. 5.7 One-Way Delay Protocol Como hemos visto, el grupo IPPM (IP Performance Metrics) ha publicado varios documentos RFC que definen las bases de trabajo para medir las prestaciones de las redes. Este grupo, est muy adelantado en el desarrollo del protocolo OWDP (One-Way Delay Measurement Protocol [23]) que ser construido desde el esqueleto diseado en la RFC 2679. La especificacin OWDP provee un mecanismo para medir el retardo de los paquetes con pruebas utilizando paquetes UDP. Adems, describe un mecanismo para controlar una sesin de medida entre dos host con una conexin TCP, para negociar los puertos UDP implicados el la medida del retardo, y para encriptar los datos de los paquetes de medida para protegerlos contra manipulaciones por terceras partes. 5.8 Monitorizacin de paquetes Un monitor de paquetes recoge copias de forma pasiva de todos los paquetes que atraviesan un enlace y almacena informacin a nivel IP, TCP/UDP o aplicacin. Recoger copias de los paquetes requiere un mtodo eficiente para tomarlos desde un enlace de la red. Esto es relativamente fcil en redes de rea local (LAN), consistentes en un medio compartido, como Ethernet, un anillo FDDI o una red wireless. Un monitor de paquetes podra ser un ordenador ordinario conectado a la LAN con una interfaz de red configurada en modo promiscuo para hacer una copia local de todos los paquetes que circulan por la red. Colocar puntos de medida en un enlace es ms difcil en el backbone de la red, que consiste en routers conectados mediante enlaces punto a punto de alta velocidad. Alternativamente, el propio router puede estar configurado para almacenar trazas de los paquetes. Copiar y analizar todos los paquetes que circulan por el enlace es tremendamente caro en cuanto a capacidad de almacenamiento se refiere, especialmente en redes con gran ancho de banda. Por eso, es imprescindible disminuir la carga de procesamiento y el volumen de los datos. Lo que se suele hacer es filtrar cierto tipo de trfico de inters y quedarse con algunos bytes de los paquetes y no con todo el contenido, por ejemplo con las cabeceras. La monitorizacin de paquetes es un mtodo efectivo para adquirir una informacin muy precisa sobre el trfico que circula por la red. Monitores basados en PCs son muy comunes en los entornos LAN y muchos de ellos ejecutan el conocido programa tcpdump [24]. Este mtodo permite analizar las prestaciones recibidas por los usuarios, ya que permite filtrar por ejemplo conexiones TCP y obtener las marcas de tiempo para calcular latencias, throughputs, etc, siendo adems trfico real de usuario y no paquetes de prueba. Otro famoso programa para captura, filtrado y anlisis de trfico

Medida del Retardo en Redes IP Alberto Castro Hinojosa

22 de 26

basado tambin en libreras libpcap es Ethereal [25], con una interfaz ms grfica que tcpdump.

Figura 9. Pantalla principal de Ethereal.

Medida del Retardo en Redes IP Alberto Castro Hinojosa

23 de 26

6- Resumen
En el presente estudio tecnolgico se ha presentado la necesidad de conocer las prestaciones en las redes IP en general y de por qu es necesario medir el retardo en particular. Se han discutido las ventajas y los inconvenientes de los dos principales tipos de tcnicas para medir las prestaciones: activas y pasivas. Fueron introducidos algunos trminos relacionados con el retardo, como son el round trip time delay, one way delay y jitter, que sern los objetos de medida. Finalmente hemos explorado algunas de las tcnicas ms conocidas para la medida y anlisis de la latencia. Son muchas las herramientas o programas de medida que podramos nombrar ([7], [26], [27]), con lo que podemos deducir el inters creciente por analizar las propiedades de la red en cuanto a calidad, por parte de los operadores y por parte de los usuarios. La medida del retardo no es especialmente difcil de conseguir y hay mtodos bastante simples que aproximan bastante bien el RTT, por ejemplo.

Medida del Retardo en Redes IP Alberto Castro Hinojosa

24 de 26

7- Bibliografa
[1] A One-way Delay Metric for IPPM (RFC 2679) (G. Almes, S. Kalidindi, M. Zekauskas; September 1999). [2] A Round-trip Delay Metric for IPPM (RFC 2681) (G. Almes, S. Kalidindi, M. Zekauskas; September 1999). [3] Framework for IP Performance Metrics (RFC 2330) (V. Paxson, G. Almes, J. Mahdavi, M. Mathis; May 1998). [4] Sistemas Multimedia Distribuidos (Aguirre Gutierrez Angel Ramn; 2002). http://exa.unne.edu.ar/depar/areas/informatica/SistemasOperativos/MonogSO/ SISMUL02.html#introd [5] Allowable Propagation Delay for VoIP Calls (Songun Na and Seungwha Yoo). of Acceptable Quality

[6] A Scalable and Lightweight QoS Monitoring Technique Combining Passive and Active Approaches (Masaki Aida, Naoto Miyoshi and Keisuke Ishibashi). [7] CAIDA cooporative association for internet data analysis. http://www.caida.org/tools/ [8] NLANR measurement and operation analysis team. http://moat.nlanr.net/ [9] IPMA: Internet performance measurement and analysis. http://www.merit.edu/ipma/ [10] Challenges and Lessons Learned in Measuring Path RTT for Proximity-based Applications (Zhiheng Wang Amgad Zeitoun Sugih Jamin). [11] Measurements and Analysis of End-to-End Internet Dynamics (Vern Paxson). [12] IP Packet Delay Variation Metric for IPPM (RFC 3393) (C. Demichelis, P. Chimento). [13] Internet Control Message Protocol (RFC 792) (J. Postel). [14] Echoping Home page. http://echoping.sourceforge.net/ [15] Netperf. http://www.netperf.org/netperf/NetperfPage.html

Medida del Retardo en Redes IP Alberto Castro Hinojosa

25 de 26

[16] Cisco Sytems NetFlow Services and Applications, White Paper, julio de 2002. [17] IP Performance Metrics. http://www.ietf.org/html.charters/ippm-charter.html [18] IETF, Remote Network Monitoring (rmonmib) Charter, http://www.ietf.org/html.charters/rmonmib-charter.html [19] IETF, Realtime Traffic Flow Measurement (RTFM) Charter, http://www.ietf.org/html.charters/OLD/rtfm-charter.html [20] IETF, Packet Sampling (IETF) Charter, http://www.ietf.org/html.charters/psamp-charter.html [21] Sflow, http://www.sflow.org [22] IPMP, IP Measurement Protocol, http://watt.nlanr.net/AMP/IPMP/ [23] One-way Active Measurement Protocol (OWAMP) Requirements http://www.faqs.org/rfcs/rfc3763.html [24] Tcpdump, http://www.tcpdump.org/ [25] Ethereal, http://www.ethereal.com/ [26] Tutorial on Internet Monitoring & PingER at SLAC, http://www.slac.stanford.edu/comp/net/wan-mon/tutorial.html [27] Network Tools, http://nextinet.ncsa.uiuc.edu/nextnet/ngi/network.html(opt,mozilla,unix,english,, NextINet