Implementación y evaluación de TCP - Vegas usando la herramienta Qual Net®

Texto completo

(1)Implementación y Evaluación de TCP-Vegas usando la herramienta QualNet. R. por. Javier Leonardo Vargas Barato. Una tesis presentada al departamento de Ingeniería Eléctrica y electrónica como parte de los requisitos para el grado de Ingeniero Electrónico. Director: Nestor Peña. Universidad de los Andes Bogotá, Colombia Enero, 2005.

(2) Índice general 1. Introducción. 2. 2. TCP Tradicional. 4. 2.1. TCP Tahoe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2. TCP Reno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3. TCP NewReno . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 3. Mejoras a TCP. 3.1. TCP Vegas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2. TCP Probing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3. TCP Westwood . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 4. TCP Vegas en QualNet. 4.1. Introducción a TCP en QualNet R . . . . . 4.2. Implementación de TCP-Vegas en QualNet R 4.3. Escenario de simulación . . . . . . . . . . . 4.3.1. Características generales . . . . . . . 4.3.2. Adicionando errores . . . . . . . . . . 4.3.3. Ajustando alfa y beta en TCP-Vegas 4.3.4. Simulación . . . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. 5 6 8. 9. 10 11 13. 16. 16 18 28 29 29 31 31. 5. Resultados. 32. 6. Conclusiones. 35. Índice de guras. 39. A. Archivo congestión.cong. 40. B. Archivo *.stat. 48. C. Archivo tcptrace.ascii. 50. Bibliografía. 54.

(3) Implementación y Evaluación de TCP-Vegas usando la herramienta QualNet. R. por. Javier Leonardo Vargas Barato. Una tesis presentada al departamento de Ingeniería Eléctrica y electrónica como parte de los requisitos para el grado de Ingeniero Electrónico. Director: Nestor Peña. Universidad de los Andes Bogotá, Colombia Enero, 2005.

(4) Capítulo 1 Introducción El protocolo de Control de Transmisión (TCP) ha sido el mecanismo dominante de transporte para la transferencia conable de datos sobre Internet [9]. Internet ha ido evolucionado involucrando dentro de su estructura subredes inalámbricas, y, por otra parte, ofreciendo servicios más exigentes en cuanto a velocidad y conabilidad [8]. Tales servicios son principalmente los que involucran tiempo real o aplicaciones multimedia (audio y video), o transmisión de voz [8], servicios que pueden prestarse sin problemas sobre redes cableadas ya que cumplen los requisitos mencionados: velocidad y conabilidad. Sin embargo, las redes inalámbricas no necesariamente están bien en cuanto a estos dos aspectos; la velocidad de una transmisión inalámbrica difícilmente superará a la de una similar cableada y además las redes inalámbricas son más susceptibles a fallas en la comunicación ya que su medio (el aire) experimenta cambios de características en todo momento (temperatura, viento, interferencia, humedad, etc) alterando la relación señal a ruido en la comunicación y ,por lo tanto, alterando la tasa de errores BER (de sus siglas en inglés Bit Error Rate ). El protocolo TCP fue diseñado pensando en redes cableadas que presentan un bajo índice de BER (casi nulo), y por lo tanto asume cuando hay pérdidas de paquetes que éstas se deben a congestión en la red.

(5) 1.0. 3. y actúa siguiendo esa política ignorando que las pérdidas se deben a otros factores y por lo tanto su reacción debería ser diferente. Por lo tanto ha surgido la necesidad de hacer mejoras en el protocolo orientadas a diferenciar los dos diferentes tipos de pérdidas y actuar de acuerdo al tipo de pérdida encontrado; éstas mejoras se conocen como LDA's por sus siglas en inglés (Loss Dieerentiation Algorithms ) [11]. Con la herramienta QualNet R podemos modicar el protocolo y además crear escenarios para simularlo, por lo que en un principio es idónea para evaluar el desempeño de diferentes protocolos en redes inalámbricas y/o mixtas. El objetivo principal de éste trabajo es presentar una introducción a la estructura que tiene TCP en QualNet R para poder dar una guía, un punto de partida para implementar alguna alteración del código de TCP en QualNet R y mostrar algunas simulaciones que permitan evaluar los cambios realizados en el código de TCP. Al principio de este trabajo, en el capítulo 2 se explican los primeros protocolos basados en TCP que son TCP Tahoe, TCP Reno y TCP NewReno, en el capítulo 3 se explican los protocolos más evolucionados: TCP Vegas, TCP Reno y TCP Westwood, en el capítulo 4 se muestra la estructura que tiene TCP en QualNet R , en el capítulo 5 se presentan los resultados de las simulaciones y en el capítulo 5 se dan las conclusiones a las observaciones junto con sugerencias para mejorar el trabajo. Los anexos tienen la intención de presentar la manera en la que se trabaja con QualNet R en modo de texto y el modo en el que aparecen los resultados relevantes..

(6) Capítulo 2 TCP Tradicional Históricamente TCP Tahoe fue la primera modicación a TCP. Después apareció TCP Reno incluyendo, recuperación rápida de paquetes (Fast Recovery algo-. rithm ), seguida por NewReno que involucra un mecanismo de reconocimientos parciales para múltiples pérdidas en una misma ventana. TCP Tahoe, Reno y NewReno usan básicamente el mismo algoritmo en el receptor, pero implementan diferentes variaciones en la transmisión. El receptor informa el tamaño de su ventana (de recepción), y el transmisor se encarga de no sobrepasarla. Por cada segmento correctamente recibido, el receptor envía un acuse de recibo (ack ) que incluye el número de secuencia del siguiente segmento. El transmisor implementa una ventana de congestión que dene el máximo número de segmentos que puede transmitir y tener en el aire. Esta ventana puede crecer o decrecer, pero nunca superar la ventana de recepción. TCP aplica incrementos de la ventana de congestión que pueden ser gradualmente multiplicativos o aditivos. Las versiones del protocolo dieren esencialmente en la manera en que la ventana de congestión es manipulada como función de los acuses de recibo y los retardos (timeouts ). [8] El mecanismo de control de errores en TCP está orientado principalmente hacia un control de congestión. La idea básica es que cada fuente determine cuánta.

(7) 2.1. 5. capacidad está disponible en la red, así, estima cuantos segmentos pueden ser inyectados de forma segura. TCP utiliza los acuses de recibo como signos de buen ancho de banda y los timeouts como signos de congestión. En respuesta, el transmisor disminuye (o aumenta) la frecuencia de transmisión reduciendo (o incrementando) la ventana de congestión. Tahoe y Reno son las dos referencias más comunes de implementación de TCP. NewReno es una versión modicada de Reno que intenta resolver algunos de los problemas del rendimiento de Reno cuando múltiples paquetes se pierden en una misma ventana de datos. [18] El control de congestión involucra los siguientes algoritmos:. Slow Start : Por cada acuse de recibo que llegue se incrementa la ventana de transmisión en una unidad1 por lo que el incremento de la ventana sería exponencial.[1]. Congestion Avoidance : Se procede con Slow Start hasta un límite llamado ssthresh, a partir de ahí, por cada acuse de recibo que llegue, se incrementa la ventana de congestión (cwnd ) así: cwnd = cwnd + 1/cwnd, lo que genera un crecimiento lineal.[1]. Fast Retransmit : Después de tres acuses de recibo repetidos (el receptor se quedó esperando una secuencia), se retransmite la secuencia que está haciendo falta.[1]. 2.1.. TCP Tahoe. El algoritmo de control de congestión incluye Slow Start, Congestion Avoidance y. Fast Retransmit. Si el tiempo sin recibir un acuse de recibo excede una constante 1 Esto. si estamos midiendo la ventana en secuencias, si se mide en bytes el incremento sería. del máximo número de bytes que puede tener una secuencia..

(8) 2.2. 6. (timeout ), se asume que la red está muy congestionada por lo que se parte otra vez de Slow Start. Si se presenta un evento de Fast Retransmit se actúa de la siguiente forma como si fuera un evento de Time Out.[1] El problema, sin embargo, es que Slow Start no es siempre eciente, especialmente si el error fue un evento aislado (típico en una red inalámbrica) en cuyo caso, la reducción de la ventana de congestión es innecesaria y limita el envío de paquetes desaprovechando el ancho de banda mientras la ventana vuelve a crecer (Figura 2.1).. Figura 2.1: Reacción de TCP Tahoe ante la pérdida de un paquete.. 2.2.. TCP Reno. El algoritmo de control se efectúa con Congestion Avoidance, ante un evento de. Timeout se hace cwnd = 1 y se parte desde Slow Start, además de esto se cambia el n de la fase de Slow Start así: -ssthresh = ssthresh/2.

(9) 2.3. 7. También se implementa Fast Retransmit pero durante un evento de esa naturaleza, la reacción es la siguiente: -cwnd = cwnd + 3/cwnd, ya que como se recibieron acuses de recibo por duplicado, se puede pensar que el error fue aislado y no hay necesidad de ser tan drástico. Sin embargo, una vez se reenvía el paquete faltante y se recibe un acuse de recibo que no es duplicado, se reduce el tamaño de la ventana de la siguiente forma: -ssthresh = ssthresh/2 -cwnd = ssthresh, lo que se conoce como desinar la ventana.[1] El gran problema de TCP Reno es cuando se pierden dos paquetes muy próximos (en cuanto a número de secuencia, ya que en un evento de esta naturaleza (que puede ser normal en redes inalámbricas), es necesario esperar a que ocurra un evento de Timeout para reenviar el paquete que hace falta y, como consecuencia de eso, la ventana de congestión se reduce a su mínimo y se vuelve a comenzar la etapa de Slow Start [1](Figura 2.2).. Figura 2.2: Reacción de TCP Reno ante la pérdida de múltiples paquetes..

(10) 2.3 2.3.. 8 TCP NewReno. NewReno ataca el problema de múltiples pérdidas de paquetes introduciendo una estrategia de reconocimientos parciales en Fast Recovery conocida como Partial. Acknowledgment y consiste en: Después de Fast Retransmit, si no llega una conrmación de todos los paquetes que están en vuelo en ese momento, reenvía el paquete que no ha llegado. Esto mejora considerablemente las falencias de Reno en el sentido en que ya no es necesario esperar a un evento de Timeout para retransmitir un paquete que se perdió durante el mecanismo de Fast Retransmit. En las guras 2.3 y 2.2 se puede ver la manera en la que el mecanismo de Partial. Acknowledgment evita que la ventana de congestión se reduzca tan drásticamente. Figura 2.3: Reacción de TCP NewReno ante la pérdida de múltiples paquetes. TCP NewReno actúa de manera muy agresiva ante retardos que pueden ser cortos al no darle tiempo a algunos paquetes para que lleguen a su destino, el riesgo que se toma al implementar TCP NewReno es el de saturar la red con Paquetes que no se han perdido sino que están demorados..

(11) Capítulo 3 Mejoras a TCP Como se vio en la sección anterior al protocolo TCP se le pueden hacer variantes para mejorar su desempeño, la aparición de TCP data de nales de los años 60, Tahoe apareció en 1988, Reno en 1990 y para 1991 NewReno, que es el predominante actualmente, ya había hecho su aparición [12] . La naturaleza de las tres modicaciones al protocolo (Tahoe, Reno y NewReno) trabajan bien cuando la pérdida de paquetes es causada principalmente por congestión en los enlaces, y la pérdida de paquetes debida a errores es despreciable; o si se quiere verlo de otra manera, los algoritmos tradicionales son altamente ecientes cuando sólo se presenta un error en cada ventana. Sin embargo, en redes mixtas e inalámbricas se encuentran tres características adicionales que dicultan el desempeño de los protocolos pensados para redes cableadas, las características adicionales son:1 Mayor BER (Bit Error Rate ). Atenuación de la señal. Periodos muertos. 1 Leer. [4], [9] y [2].

(12) 3.1. 10. La reacción de los protocolos tradicionales frente a las características arriba mencionadas es deciente: en la primera, se actúa siempre con una reducción a la ventana de congestión que no siempre es necesaria, en la segunda se actúa de mejor manera ya que la ventana de congestión se reduce hasta alcanzar un tamaño bueno, pero en la tercera la reacción es la misma que si se presenta un evento de. Time Out y es disminuir drásticamente la ventana de congestión. Por lo tanto la peor reacción es cuando ocurren errores aleatorios, que dañen algunos de los paquetes, ya que se asume que éstos se están perdiendo debido a congestión en la red, es decir, que la red está saturada y eso no es siempre cierto, puede que la red no haya alcanzado a llenar su ancho de banda, por lo que lo mejor que se puede hacer para evitar una reducción innecesaria de la ventana de congestión es estimar el ancho de banda (BW ) de la red y actuar de acuerdo a lo estimado. A continuación se presentan tres algoritmos que se encargan de estimar este ancho de banda: TCP Vegas [2], TCP Probing [3] y TCP Westwood [4].. 3.1.. TCP Vegas. TCP Vegas apareció en 1994, su algoritmo para detectar la causa de la pérdida de paquetes es muy sencilla: Calcula el tiempo de ida y vuelta de los paquetes (RTT ) y se lo asigna a la variable RT TA , también tiene presente el mínimo RTT medido y se lo asigna a la variable RT T0 , se hace el siguiente cálculo: dif f =. cwnd cwnd − RT T0 RT TA. RT T0 = cwnd. RT TA − RT T0 RT TA. (3.1). Como (RT TE − RT T0 ) es la diferencia entre los tiempos de ida y vuelta (el actual y el mínimo) resulta estar estimando el tiempo que se están tomando de más los paquetes en llegar a su destino; cwnd/RT T es un estimado de la frecuencia de inyección de paquetes en la red, el producto de las dos representa de alguna manera.

(13) 3.2. 11. la cantidad de paquetes que están retrasados en la red. El objetivo de vegas es mantener di dentro de dos rangos,2 es decir establecer un máximo y un mínimo para los paquetes que estarían retrasados [2]. Para lograr el objetivo se actúa de la manera que sigue mientras se esté en la etapa de Congestion Avoidance :. cwnd =.    cwnd + 1   . cwnd      cwnd − 1. si. di < α. si. α ≤ di ≤ β. si. β < di. (3.2). Otra característica de Vegas es que la variable ssthresh no varía y se ja en ssthresh = (α + β)/2[2]. Existen otras cuatro características propias de TCP. Vegas que se pueden resumir en: Primero: en el inicio o después de Slow Start la ventana de congestión se igual a uno, no a dos. Segundo: Vegas graba el tiempo en el que cada paquete es enviado, de esta manera se reenvía el paquete no sólo después de un número acuses de recibo duplicados (DUPACK's ) repetidos sino también después de que se acaba el tiempo en un temporizador, lo que suceda primero. Tercero: Después de que se reenvía un paquete debido a DUPACK's, la ventana de congestión se reduce a la mitad sólo si el tiempo que ha transcurrido desde la última reducción del tamaño de la ventana excede RT TA (El tiempo de ida y vuelta actual). Cuarto: Cuando la ventana se reduce, no se reduce a la mitad sino en razón de tres cuartos de la ventana actual [2].. 3.2.. TCP Probing. TCP Probing aparece en el año 2000 y muestra un esquema para identicar el origen de las pérdidas de información en una comunicación. TCP Probing obedece el diagrama de ujo mostrado en la gura A. Después de un 2 En. [2] no se especica la forma de escoger α y β ..

(14) 3.3. 12. evento de Time Out o Fast Retransmit. Primero congela la transmisión y manda un paquete de prueba, si no vuelve su acuse de recibo, lo vuelve a mandar, pero si vuelve manda otro, si del otro no se recibe acuso de recibo, vuelve a comenzar pero si efectivamente se obtiene el acuse de recibo, se acaba ésta etapa de prueba y se actúa dependiendo del RTT calculado en la etapa de prueba. Las reglas de decisión que determinan la acción después del ciclo de prueba que se proponen en [3] son las siguientes: Los dos RTTs medidos se comparan; si están en el intervalo [Mejor RTT, último RTT ], se aplica Inmediate Recovery que consiste en poner las variables como estaban antes, si no está en ese intervalo, se actúa comenzando con Slow Start y se ajusta ssthresh como si se estuviera en Reno o NewReno [3].. Figura 3.1: TCP Probing después de Time Out o Fast Retransmit. Diagrama hecho. por el autor.

(15) 3.3 3.3.. 13 TCP Westwood. TCP Westwood aparece en 2001 con una idea sosticada y completa para estimar el ancho de banda disponible en la red basada principalmente en los RTT's y en la cantidad de datos enviados. La idea clave en TCP Westwood es explotar los acuses de recibo para hacer algunas mediciones. Después de un episodio de congestión (DUPACK's ), el transmisor usa el ancho de banda estimado para ajustar la venta usando un procedimiento que se conoce como Faster Recovery. TCP Westwood basa su desempeño (para redes cableadas) en la siguiente armación: Inmediatamente después de un episodo de congestión, la red está saturada, por lo tanto está al tope de su capacidad, dicho de otra manera, está en el mayor ancho de banda que podría alcanzar, por lo tanto: Antes de un episodio de. congestión, el ancho de banda usado es menor o igual que el disponible ya que la ventana de congestión todavía está creciendo en función de probar la capacidad de la red [4]. Como resultado, TCP Westwood ajusta su ventana teniendo en cuenta la capacidad de la red. Cada ACK recibido en un tiempo tk implica que un correspondiente monto de datos dk ha sido enviado con éxito, por lo que se podría medir el ancho de banda como [4]: bk =. dk tk − tk−1. Donde tk−1 es el tiempo en el que se recibió el anterior ACK. Sin embargo, estimar el ancho de banda es un proceso más delicado: vale la pena tener la información anterior, además de eso ponderarla con respecto al nuevo dato y por último, no dejar que el ancho de banda estimado sea muy oscilante mucho, por lo que se hace pasar por un ltro (Ecuación 3.3) y el ancho de banda estimado se calcula así:.

(16) 3.3. 14. b̂k =. 2τ tk −tk−1 2τ tk −tk−1. −1 +1. b̂k−1 +. bk + bk−1 2τ +1 tk −tk−1. (3.3). La ecuación 3.3 es la ecuación que sale de pasar los bk 's por un ltro pasa-bajas [4]. La variable τ está determinando el ancho de banda del ltro digital, sin embargo la mejor forma de interpretarlo es notar que está ponderando el ancho de banda estimado de mediciones anteriores (b̂k ) con el ancho de banda calculado con mediciones recientes (bk−1 , bk ). Notemos que en el fondo la ecuación 3.3 no es más que la de un ltro exponencial[10]:. b̂k = αb̂k−1 + (1 − α)bk. (3.4). Notemos que en la ecuación 3.3 no se están mencionando cosas importantes como pueden ser el número de DUPACK's que ha recibido ni tampoco los ACK's retardados que están dando fe de que muchos paquetes han sido bien recibidos. En [4] se especican mecanismos para tener ese par de variables en cuenta;3 también en westwood se aclara el procedimiento para la elección del valor de la variable τ (que es la frecuencia de corte del ltro). Westwood deja libre la elección del. número de DUPACK's que accionarían Fast Recovery pero [4] no da ninguna luz sobre la elección de ese número (n ). El proceder de Westwood después de recibir n DUPACK's es el siguiente [4]: - ssthresh = b̂k × RT Tmin - cwnd = mı́n{cwnd, ssthresh} De esta forma si se está en el proceso de Slow Start, cwnd no cambia y se puede seguir en Slow Start. EL proceder de Westwood después de un evento de Time Out es: 3 No. los tomo en cuenta en este documento debido a que éste tiene un carácter introductorio. más que un resúmen detallado de los mecanismo de TCP Westwood..

(17) 3.3. 15. - ssthresh = máx{2, b̂k × RT Tmin } - cwnd = 1 TCP Westwood nos brinda una de las estimaciones del ancho de banda más sosticada que hay, los resultados de los experimentos realizados en [4] demuestran que además de ser sosticada la aproximación es precisa, lo que permite optimizar los enlaces que utiliza y además convive satisfactoriamente con otras versiones de TCP sin acaparar el ancho de banda de la conexión mejorando el desempeño de las comunicaciones en las que se involucra, particularmente, su comportamiento en redes inalámbricas ha sido evaluado con resultados satisfactorios [4]..

(18) Capítulo 4 TCP Vegas en QualNet 4.1.. Introducción a TCP en QualNet. R. QualNet R desarrollado por Scalable Network Technologies es una herramienta computacional que tiene como objetivo brindar un recurso para diseñar y operar escenarios de comunicaciones. Para tal n ofrece una gran cantidad de opciones que van desde la posibilidad de alterar o crear cualquier capa de comunicación (física, enlace, red, transporte...), hasta la implementación de un mapa con accidentes naturales y construcciones con el ánimo de que la brecha entre simulación y experimentación sea lo más angosta posible. La versión 3.7 de QualNet R 1 tiene implementados cinco variantes de TCP y cada una de ellas presenta diferentes opciones. Las variantes que presenta son TAHOE, RENO, NEWRENO y además LITE y SACK.2 El código de TCP está escrito en código C, está dividido principalmente en 15 1 Que. fue con la que se efectuó la totalidad del trabajo. y SACK son variaciones de RENO, no se estudió su funcionamiento ni serán usadas. 2 LITE. más adelante..

(19) 4.1. 17. archivos de los cuales 9 son archivos de cabecera. El archivo principal es tcp.cpp. Los archivos, y la descripción incluida en los mismos se presenta a continuación: tcp.h: Contiene las deniciones vinculadas a la simulación de TCP. tcp_config.h: Contiene las opciones y constantes congurables. Se pueden ajusar. dependiendo de las necesidades del usuario. tcp_fsm.h: Contiene las deniciones de los diferentes estados de la máquina. (nita) de estados de TCP. tcp_hdr.h: Contiene la estructura del encabezado de TCP. tcp_proto.h: Contiene los prototipos de las funciones. tcp_seq.h: Contiene macros y constantes para operar los números de secuencia. de TCP. tcp_timer.h: Contiene las deniciones de las constantes usadas en los tempo-. rizadores de TCP. tcp_var.h: Contiene las deniciones del bloque de control y la estructura de las. estadísticas. tcpip.h: Contiene la estructura del encabezado de IP y de TCP cuando se quitan. las opciones de IP. tcp.cpp: Contiene el procesamiento de los mensajes en TCP. tcp_input.cpp: Contiene la rutina de entrada de TCP. tcp_output.cpp: Contiene la rutina de salida de TCP. tcp_subr.cpp: Contiene variadas subrutinas de TCP (inicialización por ejem-. plo). tcp_timer.cpp: Contiene las rutinas asociadas con el manejo de los tempo-. rizadores. tcp_usrreq: Contiene las funciones que procesan los requerimientos de la apli-. cación..

(20) 4.2. 18. El archivo principal es tcp.cpp, en él están incluidas como funciones principales tcp_input.cpp y tcp_output.cpp como sub-rutinas muy particulares, además. de sub-rutinas denidas en los otros archivos con extensión cpp.. 4.2.. Implementación de TCP-Vegas en QualNet. R. Las diferentes variantes de tcp (Tahoe, Reno, NewReno, Sack y Lite) denen los estados de un tipo de variable llamada TcpVariantType en el archivo tcp.h con el siguiente código: typedef enum{ TCP_VARIANT_TAHOE, TCP_VARIANT_RENO, TCP_VARIANT_LITE, TCP_VARIANT_SACK, TCP_VARIANT_NEWRENO, TCP_VARIANT_VEGAS }TcpVariantType. // // // // // //. 0 1 2 3 4 5 Se adiciona para Vegas. Donde el número que aparece como comentario es un número que se relaciona con cada variante. El tipo de variable TcpVariantType hace parte de la estructura TransportDataTcpStruct denida en tcp.h y es la que almacena todas las opciones relacionadas con TCP, algunas de éstas opciones las puede escoger el usuario usando el modo gráco de simulación, otras sólo se pueden escoger añadiendo texto en el archivo *.config de la simulación. Parte de la estructura se muestra a continuación: struct TransportDataTcpStruct { . . . TcpVariantType tcpVariant; // TAHOE | RENO | LITE | SACK | NEWRENO | VEGAS // TcpTraceType tcpTrace; // NONE|TCPPEEK|TCPDUMP|TCPDUMP-ASCII // ..

(21) 4.2. }. 19 . . double tcpRandomDropPercent;// percent of packets to drop randomly // . . .. Se muestran en la estructura otras variables relevantes para la implementación de TCP-Vegas, tal es el caso de: TcpTrace que elige si se crea un archivo (tcptrace) con la información de cada. paquete recibido (y/o enviado) y el formato en el cual se crea. tcpRandomDropPercent cuyo valor determina el porcentaje de paquetes TCP que. se dejan caer. Se denen también dentro de tcp_var.h valores boolenos mediante las funciones (macros) que se presentan a continuación. #define #define #define #define. TCP_VARIANT_IS_TAHOE(tp) ((tp)->tcpVariant <= TCP_VARIANT_TAHOE) TCP_VARIANT_IS_RENO(tp) ((tp)->tcpVariant <= TCP_VARIANT_RENO) TCP_VARIANT_IS_SACK(tp) ((tp)->tcpVariant == TCP_VARIANT_SACK) TCP_VARIANT_IS_NEWRENO(tp) ((tp)->tcpVariant == TCP_VARIANT_NEWRENO). // // // //. //para Vegas se adiciona #define TCP_VARIANT_IS_VEGAS(tp) ((tp)->tcpVariant == TCP_VARIANT_VEGAS) // ==5 //fin de lo adicionado #define TCP_SACK_REXT(tp). ((TCP_VARIANT_IS_SACK(tp)) \ && (tp->isSackFastRextOn)). Se usan cuando se necesitan condicionar los procedimientos dentro de cada variante, muy frecuentemente. Se necesitaban un par de variables de control que almacenaran el tiempo de ida y vuelta actual y el tiempo de ida y vuelta mínimo, tales variables se denieron dentro de tcp_var.h en la estructura tcpcb que es la estructura que maneja todas. <=0 <=1 ==3 ==4.

(22) 4.2. 20. las variables relacionadas con el control en TCP. Se presenta parte del código de la estructura con las variables de más interés.: struct tcpcb { . . . // congestion control (for slow start, source quench, retransmit after loss) unsigned long snd_cwnd; // congestion-controlled window unsigned long . . . int t_rtt; . . . unsigned long. snd_ssthresh;. // snd_cwnd size threshold for // for slow start exponential to // linear switch. // round trip time. max_sndwnd;. // largest window peer has offered. // adicionado para vegas int min_rtt_vegas; // Minimo Rtt adicionado por tato para Vegas (no se usa) int act_rtt_vegas; // Actual RTT (se usa éste porque el arriga definido // tiene un propósito bien particular //fin de lo adicionado . . . };. La principal estrategia de programación consistió en buscar los caracteres "tcp_variant", mirar en qué función se encontrabar, determinar si era pertinente para TCP-Vegas modicar el código y modicarlo de ser el caso. Así se llegó, dentro de tcp.cpp al lugar donde se lee el archivo *.config3 y se le atribuye algún valor a la variable tcpVariant, el código es el siguiente: 3 Mirar. apéndice A.

(23) 4.2. 21 // Initialize TCP Variant for the node // The <variant> is one of TAHOE | RENO | LITE | SACK | NEWRENO | VEGAS // Format is: TCP <variant>, for example // TCP LITE // [7 thru 10] TCP SACK // [11 13 15] TCP RENO // If not specified, default is VEGAS //Pero se puede cambiar // tcpLayer->tcpVariant = TCP_VARIANT_LITE; IO_ReadString( node->nodeId, ANY_ADDRESS, nodeInput, "TCP", &retVal, buf); if (retVal == TRUE) { if (strcmp(buf, "TAHOE") == 0) { tcpLayer->tcpVariant = TCP_VARIANT_TAHOE; } else if (strcmp(buf, "RENO") == 0) { tcpLayer->tcpVariant = TCP_VARIANT_RENO; } else if (strcmp(buf, "LITE") == 0) { tcpLayer->tcpVariant = TCP_VARIANT_LITE; } else if (strcmp(buf, "SACK") == 0) { tcpLayer->tcpVariant = TCP_VARIANT_SACK; } else if (strcmp(buf, "NEWRENO") == 0) { tcpLayer->tcpVariant = TCP_VARIANT_NEWRENO; }. // SE ADICIONA PARA VEGAS else if (strcmp(buf, "VEGAS") == 0) { tcpLayer->tcpVariant = TCP_VARIANT_VEGAS; } // FIN DE LA ADICIÓN PARA VEGAS else { // Preferably rewrite this this as // char aMsg[MAX_STRING_LENGTH]; // sprintf(aMsg, // "TCP: Unknown variant (%s) in configuration file.\n");.

(24) 4.2. 22. }. }. // ERROR_Assert(FALSE, aMsg); // Or suggest it as a library function // ERROR_Assert(FALSE, "TCP: Unknown variant in configuration file.\n");. La parte más importante es el control de congestión, lo cual se hace dentro de tcp_input.cpp, para poder hacer el control de congestión propuesto en Vegas,. es necesario tener los tiempos de ida y vuelta: el mínimo y el actual. El actual corresponde a la variable t_rtt y se usa en la rutina para calcular el tiempo de Time Out (tcp_xmit_timer) y después se borra, por lo que es necesario actualizarlo antes de borrarlo, así que dentro de la función tcp_xmit_timer se escriben las líneas que actualizan las variables t_rtt_vegas y min_rtt_vegas lo cual se hace con éstas líneas: static void tcp_xmit_timer( struct tcpcb *tp,int rtt, struct tcpstat *tcp_stat){ . . . tp->act_rtt_vegas = tp->t_rtt; if (tp->act_rtt_vegas < tp->min_rtt_vegas){ tp->min_rtt_vegas=tp->act_rtt_vegas; } . . . }. Ahora todo es cuestión de usar lo que se ha denido dentro del control de congestión, lo cual se hace dentro del archivo tcp_input.tcp. En la función tcp_input hay una subrutina marcada con la etiqueta process_ACK dentro de la cual se hace.

(25) 4.2. 23. todo el procesamiento asociado a recibir acuses de recibo en secuencia: el código es el siguiente: void tcp_input( Node *node, unsigned char *payload, int actual_len, int virtual_len, TosType priority, struct inpcb *p_head, tcp_seq *tcp_iss, long unsigned int tcp_now, struct tcpstat *tcp_stat) { . . . process_ACK: . . . if(TCP_VARIANT_IS_VEGAS(tp)){ // Primero se definen las variables necesarias unsigned int cw_vegas = tp->snd_cwnd; unsigned int incr_vegas = tp->t_maxseg; unsigned unsigned unsigned unsigned. int int int int. // el incremento es exponencial // por defecto. base_vegas = tp->min_rtt_tato; actrtt_vegas = tp->t_rtt; alpha_vegas = 5120; // ésta elección lleva trabajo beta_vegas = 7680; // ésta es un poco más libre si // ya se tiene la anterior unsigned int diff_vegas; unsigned int optim_vegas; unsigned int actual_vegas; // Asegrurarse de no dividir por cero, el RTT // puede ser cero si no es muy preciso // Se actualiza el rtt if(actrtt_vegas <= 0){ actrtt_vegas = 1; } base_vegas=MIN(base_vegas,actrtt_vegas); if(base_vegas <= 0){.

(26) 4.2. }. 24 base_vegas = 1;. // Se actualizan unas variables auxiliares. } . . .. optim_vegas = cw_vegas/base_vegas; actual_vegas = cw_vegas/actrtt_vegas; diff_vegas = (optim_vegas - actual_vegas)*base_vegas; if (cw_vegas > tp->snd_ssthresh) { if (diff_vegas < alpha_vegas){ incr_vegas = incr_vegas * incr_vegas / cw_vegas; } if (diff_vegas > beta_vegas){ incr_vegas = -incr_vegas * incr_vegas / cw_vegas; } else { incr_vegas = 0; } tp->snd_cwnd = MIN(cw_vegas + incr_vegas, (unsigned int) (TCP_MAXWIN<<tp->snd_scale));. El resto de programación es un poco más monótono, hasta éste punto, TCP-Vegas sólo tiene control de congestión y otras funciones generales que cumplen Tahoe, Reno, NewReno, Sack y Lite por defecto. Sin embargo, la implementación que se quiere tener de Vegas es tener la de NewReno y cambiar el control de congestión, así que lo que queda por ver es asegurarse de que Vegas haga exactamente lo mismo que NewReno. Entre otras debe hacer Fast Retransmit, Fast Recovery, Partial. Recovery, y otra cantidad de rutinas: Se presentan a continuación:. Se habilita la opción de uso de RFC 1323 para TCP Vegas: // Initialize tcpUseRfc1323 for the node // Format is: TCP-USE-RFC1323 NO | YES // If not specified, default is NO.

(27) 4.2. 25. // Was TCP_DO_RFC1323 in config.h tcpLayer->tcpUseRfc1323 = FALSE; if (tcpLayer->tcpVariant == TCP_VARIANT_LITE || tcpLayer->tcpVariant == TCP_VARIANT_SACK || tcpLayer->tcpVariant == TCP_VARIANT_NEWRENO || tcpLayer->tcpVariant == TCP_VARIANT_VEGAS)) { IO_ReadString( node->nodeId, ANY_ADDRESS, nodeInput, "TCP-USE-RFC1323", &retVal, buf); if (retVal == TRUE) { if (strcmp(buf, "NO") == 0) { tcpLayer->tcpUseRfc1323 = FALSE; } else if (strcmp(buf, "YES") == 0) { tcpLayer->tcpUseRfc1323 = TRUE; } else { ERROR_Assert(FALSE, "TCP-USE-RFC1323: Unknown value in configuration file.\n"); } } }. Se activa la opción de fast retransmit: if (TCP_VARIANT_IS_NEWRENO(tp)) { tp->isNewRenoFastRextOn = TRUE; }. Se habilitan reconocimientos parciales (Partial // // // // //. Recovery ). When the third duplicate ACK is received and the sender is not already in the Fast Recovery procedure, set ssthresh to no more than the value given in ssthresh = max (FlightSize / 2, 2*MSS).

(28) 4.2 // // // // // // // if. 26. where FLIGHT SIZE:The amount of data that has been sent but not yet acknowledged. Record the highest sequence number transmitted in the variable "recover".. (TCP_VARIANT_IS_NEWRENO(tp)||TCP_VARIANT_IS_VEGAS(tp)) { if ( SEQ_GEQ(ti->ti_ack, tp->send_high) && (tp->isNewRenoFastRextOn == FALSE)) { tp->flightSize = tp->snd_max - tp->snd_una; tp->recover = tp->snd_max; if ((tp->t_ecnFlags & TF_ECN_STATE) == 0) { tp->snd_ssthresh = MAX(tp->flightSize / 2 / tp->t_maxseg, 2) * tp->t_maxseg; } } else { goto drop; }. En la siguiente opción se desina la ventana de congestión en todas las variantes salvo en NewReno y Vegas: // If the congestion window was inflated to account // for the other side's cached packets, retract it. // if ((!TCP_VARIANT_IS_NEWRENO(tp))&&(!TCP_VARIANT_IS_VEGAS(tp))) { if (!TCP_VARIANT_IS_SACK(tp)) { if (!TCP_VARIANT_IS_TAHOE(tp)) { if (tp->t_dupacks >= tcprexmtthresh && tp->snd_cwnd > tp->snd_ssthresh) { tp->snd_cwnd = tp->snd_ssthresh; TransportTcpTrace(node, 0, 0, "recovery end"); } } tp->t_dupacks = 0; TransportTcpTrace(node, 0, 0, "Normal: Faxt ends : 3"); } }.

(29) 4.2. 27. En la siguiente opción se ejecuta el mecanismo de reconocimientos parciales: // // // // // if. }. If any partial ACK comes then retransmit the first unacknowledged segment. Deflate the congestion window by the amount of new data acknowledged, then add back one MSS and send a new segment if permitted by the new value of cwnd. (tp->t_dupacks >= tcprexmtthresh) { if (TCP_VARIANT_IS_NEWRENO(tp)) { if (SEQ_GEQ(tp->snd_una, tp->recover)) { tp->snd_cwnd = tp->snd_ssthresh; tp->t_dupacks = 0; { unsigned int cw = tp->snd_cwnd; unsigned int incr = tp->t_maxseg; if (cw > tp->snd_ssthresh) { incr = incr * incr / cw; } tp->snd_cwnd = MIN(cw + incr, (unsigned int) (TCP_MAXWIN<<tp->snd_scale)); } tp->isNewRenoFastRextOn = FALSE; TransportTcpTrace(node, 0, 0, "recovery end"); } else { tcp_seq onxtII = tp->snd_nxt; tcp_seq ocwnd = tp->snd_cwnd; tp->snd_nxt = ti->ti_ack; tp->snd_cwnd = tp->t_maxseg; tp->t_timer[TCPT_REXMT] = 0; tcp_output(node, tp, tcp_now, tcp_stat); tp->snd_nxt = onxtII; tp->snd_cwnd = ocwnd - acked + tp->t_maxseg; tp->t_ecnFlags |= TF_REXT_PACKET; tcp_output(node, tp, tcp_now, tcp_stat); } }. Con el siguiente código se eliminan los problemas de múltiples Retransmisiones:.

(30) 4.3 // // // //. 28 To eliminates the problem of multiple Fast Retransmits we uses this new variable "send_high", whose initial value is the initial send sequence number. After each retransmit timeout, the highest sequence numbers transmitted so far is recorded in the variable "send_high".. if (TCP_VARIANT_IS_NEWRENO(tp)||TCP_VARIANT_IS_VEGAS(tp)) { tp->send_high = tp->iss; tp->isNewRenoFastRextOn = FALSE; }. 4.3.. Escenario de simulación. Para probar el desempeño de TCP-Vegas, se simuló una sesión de red usando la topología mostrada en la gura 4.1. Se escogió esa estructura con el único n de generar congestión y así provocar que se perdieran paquetes por congestión.. Figura 4.1: Escenario de simulación.

(31) 4.3. 29. 4.3.1.. Características generales. La estructura presentada, es conocida como cuello de botella,4 ya que cualquier comunicación entre los nodos de la derecha y los nodos de la izquierda tiene que pasar entre los nodos 4 y 5, saturando el enlace y saturando también la ventana de recepción de los nodos intermediarios. Pensando también en eso, el enlace entre los nodos 4 y 5 se hizo más lento, todos los enlaces soportan una velocidad de 10Mbps mientras que el enlace entre los nodos 4 y soporta una velocidad diez veces menor, 1Mbps. Los nodos 1, 2, y 3 inician una sesión FTP enviando paquetes a los nodos 6 y 7, en particular el nodo 1 le envía paquetes al nodo 6 y los nodos 2 y 3, le envían paquetes al nodo 7. Las características de las diferentes sesiones FTP son las siguientes: Paquetes enviados: 100. Tamaño de los paquetes: 512.5 La idea es hacer un seguimiento a la comunicación entre el nodo 1 y el nodo 6, las otras sesiones sólo son para generar tráco y saturar las colas.. 4.3.2.. Adicionando errores. En un principio se pretendía usar un escenario inalámbrico y variar sus parámetros para mirar el comportamiento de las diferentes variantes pero eso complicó el 4 Es. la estructura usada en una buena parte de la bibligrafía para crear congestión, mirar por. ejemplo [5], [13] o [17] 5 Se escogieron éstas características tomando como punto de partida los experimentos presentados en [18].

(32) 4.3. 30. trabajo y no se lograron buenos resultados con eso. En [2] y [3] se usan modelos de erroes para evaluar el desempeño de variantes de TCP para redes inalámbricas, la justicación es que las características de las redes inalámbricas (Periodos muertos, Baja relación señal a ruido, interferencia etc) se reejan a nivel de capa de transporte como paquetes caídos, así que el BER del principio se va a convertir en PER (Packet error rate). En [2] y [3] se usan modelos usando cadenas de Markov y otras herramientas para producir el modelo de error más conveniente para simular una red inalámbrica. Qualnet R , dentro del código TCP, nos ofrece la posibilidad de hacer que cierto porcentaje de paquetes se pierda, el código se presenta a continuación: // Initialize random drop percent for the node // Format is: TCP-RANDOM-DROP-PERCENT <value>, for example // [3] TCP-RANDOM-DROP-PERCENT 10 // [1] TCP-RANDOM-DROP-PERCENT 5 // For an FTP transfer from node 1 to 3, this would drop // 10% data packets at node 3 and 5% acks at node 1 // This option is for internal use // IO_ReadDouble( node->nodeId, ANY_ADDRESS, nodeInput, "TCP-RANDOM-DROP-PERCENT", &retVal, &aDropPercent); if (retVal == TRUE) { if (aDropPercent >= 0.0 && aDropPercent <= 100.0) { tcpLayer->tcpRandomDropPercent = aDropPercent; } else { ERROR_Assert(FALSE, "TCP-RANDOM-DROP-PERCENT: " "Out of range value in configuration file.\n"); } } else { tcpLayer->tcpRandomDropPercent = 0.0; }.

(33) 4.3 4.3.3.. 31 Ajustando alfa y beta en TCP-Vegas. Dentro de la bibliografía consultada ([2],[10] y [21]), sólo [21] ofrece una propuesta básica para ajustar los valores de α y β usando el buer asociado a TCP y que en QualNet R tiene un valor de 16384 bytes así entonces se ja α en 1 × buer = 16384(Bytes) y β en 3 × buer = 49152(Bytes).. También se intentó ajustar los parámetros observando las mediciones en simulaciones de TCP Tahoe pero es más plausible la conguración presentada por [21] debido a que no depende de observaciones que pueden estar sesgadas por la conguración de la red o por el tráco presente en el momento. Como contraparte tiene el defecto de depender de un valor que no es constante en todos los nodos de una red, es constante para cada nodo pero no es un valor absoluto en una red.. 4.3.4.. Simulación. Con el objetivo de dar una buena estimación del desempeño de la variación implementada, se simularno TCP Tahoe, TCP Reno, TCP NewReno y TCP Vegas en el escenario presentado en la gura 4.1. El error se hizo variar desde 0 % a 10 % en saltos de 1 %, cada protocolo con cada error se simuló con cinco semillas distintas para un total de 200 simulaciones..

(34) Capítulo 5 Resultados El primer resultado que vale la pena destacar es el éxito que se tuvo implementando el control de congestión de TCP Vegas, tomando en cuenta que el ambiente encontrado en QualNet R es complicado y engorroso, principalmente por que todas las variantes que tiene QualNet R del protocolo TCP están ubicadas en una sola estructura de archivos por la sencilla razón de que todas comparten la mayor parte del código, sin embargo, una vez se encuentra el código del control de congestión y las variables relevantes para hacer los cambios, el trabajo se convierte en un trabajo de buenas escritura de programación en Visual C. Obviamente, haber logrado programar una variante de TCP lleva consigo otro resultado secundario pero importante y es haber descifrado el código y la manera en la que están ordenados los procesos, las funciones y las estructuras dentro de los protocolos que, sinceramente fue el trabajo más exahustivo, complicado y el que se llevó la mayor parte del tiempo. El otro resultado que vale la pena mencionar es, después de implementar el protocolo y hacerlo compatible con QualNet R lograr simularlo y evaluarlo comparativamente con las principales variantes de TCP: Tahoe, Reno y NewReno. Para lograr tal evaluación se observó el comportamiento de TCP Vegas, TCP Tahoe,.

(35) 5.0. 33. TCP Reno y TCP NewReno ante pérdida deliberada de paquetes mirando el. goodput de la comunicación entre los nodos 1 y 6 (ver gura 4.1). goodput =. bytes de mensaje tiempo de comunicación. Los datos obtenidos se pueden apreciar en la gura 5.1.. Figura 5.1: Goodput en función del % de pérdida de paquetes. (5.1).

(36) 5.0. 34. También se miró el throughput :. throughput =. total bytes enviados tiempo de comunicación. (5.2). Cuyo comportamiento se ve en la gura 5.2.. Figura 5.2: Throughput en función del % de pérdida de paquetes QualNet R , en el archivo *.stat nos entrega el throughput, el tiempo en el que se entrega el primer paquete y el tiempo en el cual se entrega el último paquete, con una resta se obtienen el tiempo de comunicación. Los bytes de mensaje se calculan multiplicando el 100 (el número de paquetes) y 512 que es el total de paquetes y ya con todos los datos se puede calcular fácilmente el goodput..

(37) Capítulo 6 Conclusiones Por complementar De la gráca que ilustra el goodput se puede observar NewReno es la variante que mejor se desempeña; el goodput, en otras palabras nos está diciendo quién se demora menos transmitiendo cien paquetes de mensaje, de la gráca también se observa que Reno y Tahoe tienen un comportamiento muy similar. Si se observa el throughput nos damos cuenta que si NewReno es la que presenta mejor goodput es precisamente por lo agresiva que es a la hora de reenviar paquetes. Cosa que se puede convertir en algo negativo ya que NewReno puede terminar viéndose como un protocolo 'egoísta' dispuesto a tomar todo el ancho de banda que pueda, con el único objetivo de re-transmitir un paquete que asume perdido. Esta linea recién escrita es clave, y sobre todo en redes inalámbricas donde cada señal que se envíe se convierte en ruido para todos los que oigan el mensaje menos para el que es el interesado. Así que en un escenario como el que se presentó, la agresividad de NewReno le dio éxito en la comunicación, pero en otro escenario puede terminar perjuidcando todas las comunicaciones. Los algoritmos basados en la estimación de ancho de banda previenen situaciones de ése estilo aunque por lo general sacrican rapidez en las comunicaciones y por lo tanto goodput. Ahora,.

(38) 6.0. 36. observando el comportamiento de Reno podemos ver que no alcanza el gran nivel de NewReno y más bien se mantiene en el perl de Reno y de Tahoe, obvio, todo eso es suceptible a cambio tan sólo modicando los parámetros α y β , si se eleva el parámetro α Vegas tendrá una reacción más agresiva y seguramente llevaría la ventana de congestión a niveles más altos. Sorprende un poco lo parecidos que se comportan Tahoe y Reno, si bien Reno es Tahoe con una pequeña mejora, de las grácas se podría decir que en presencia de pérdida de paquetes, la "mejora"de Reno en cuanto a Tahoe termina siendo un perjuicio. Ahora, si se observa el throughput los resultados son algo sorprendentes en cuanto a Reno y Vegas, se comportan muy similarmente, no sorprende para nada el comportamiento de NewReno, con un caudal muy superior a los otros, su reacción ante la pérdida de paquetes es muy agresiva, tampoco sorprende que Tahoe tenga el menor caudal, ya que cada vez que pierde un paquete su ventana se reduce drásticamente. Como conclusión importante de las observaciones es que el comportamiento de Vegas es en cierta manera el esperado, se esperaba que no inundara la red con mensajes innecesarios y que a su vez tuviera un buen desempeño, cosa que logró ya que la frase anterior se puede enunciar de la siguiente forma: Mantener un. goodput competente sin necesidad de elevar el caudal. Algo muy importante para decir es que éste modelo de pérdida de paquetes no es necesariamente el más adecuado para simular una red inalámbrica, ya que en una red inalámbrica los errores suelen venir en pequeñar ráfagas y es muy difícil que.

(39) 6.0. 37. haya una tasa de error constante en la cual cada paquete tenga exactamente la misma posibilidad de dañarse que cualquier otro. Qualnet R ofrece herramientas para simular una red inalámbrica de una forma más realista, sin embargo se optó por la presente debido a que era ligeramente más fácil evaluar el desempeño de los protocolos y que en la bibliografía consultada, las evaluaciones se hacen bajo situaciones similares. Es decir, las pérdidas de paquetes ocurren sólamente en la capa de transporte (!) siendo que sabemos que la información puede corromperse en otras instancias de la comunicación, sobre todo a nivel de capa física. A pesar de lo explícito de los resultados de las simulaciones, hizo falta tomar más datos, apreciar otro tipo de escenarios y otro tipo de errores. Éste trabajo abre una puerta importante al ser de los primeros en atreverse a adicionar lineas al código y no sólo modicar parámetros, la implementación de TCP Vegas se hizo de tal manera en que no se sacricó nada de las otras variantes además de quedar con la misma estructura que maneja el programa. Se queda corto ya que no se pudo encontrar una mejor variable para medir parámetros como el tiempo de ida y vuelta que es tan importante en TCP Vegas y, tampoco se pudo trabajar mucho en el ajuste adecuado de las variables α y β que de todas formas no es un trabajo fácil. Si bien el resultado no fue el mejor posible, sobre todo en cuanto a la evaluación del nuevo protocolo, los objetivos propuestos se cumplieron. De Qualnet R hay que decir que es una herramienta que presenta muchos recursos y ayudas en la construcción y simulación de escenarios, mientras que para la construcción y simulación de protocolos se queda corto. El código trabajado es difícil de seguir, las funciones están bien especicadas pero eso no basta. Desde sus primeras versiones, todas las variaciones de TCP están escritas en los mismos.

(40) 6.0. 38. archivos, haciendo de su modicacióy y/o entendimiento algo tedioso y en ocasiones frustrante. Esto hace que la escritura de nuevo código sea meticulosa en extremo, ya que con cada nueva línea es posible estar dañando cosas de protocolos que nisiquiera conocíamos. No obstante, la experiencia de programar un protocolo o parte de él enriquece muchos conceptos..

(41) Índice de guras 2.1. Reacción de TCP Tahoe ante la pérdida de un paquete. . . . . . . 2.2. Reacción de TCP Reno ante la pérdida de múltiples paquetes. . . . 2.3. Reacción de TCP NewReno ante la pérdida de múltiples paquetes.. 6 7 8. 3.1. TCP Probing después de Time Out o Fast Retransmit. Diagrama hecho por el autor . . . . . . . . . . . . . . . . . . . . . . . . . . .. 12. 4.1. Escenario de simulación . . . . . . . . . . . . . . . . . . . . . . .. 28. 5.1. Goodput en función del % de pérdida de paquetes . . . . . . . . . . 5.2. Throughput en función del % de pérdida de paquetes . . . . . . . .. 33 34.

(42) Apéndice A Archivo congestión.cong Se presena el archivo congestión.config, que fue el usadoe en las simulaciones los comentarios van precedidos del signo #. # Copyright (c) 2001-2002, Scalable Network Technologies, Inc. All Rights Reserved. # 11022 Santa Monica Boulevard # Suite 260 # Los Angeles, CA 90025 # [email protected] # # # # # # # # # #. This source code is licensed, not sold, and is subject to a written license agreement. Among other things, no portion of this source code may be copied, transmitted, disclosed, displayed, distributed, translated, used as the basis for a derivative work, or used, in whole or in part, for any program or purpose other than its intended use in compliance with the license agreement as part of the QualNet software. This source code and certain of the algorithms contained within it are confidential trade secrets of Scalable Network Technologies, Inc. and may not be used as the basis for any other software, hardware, product or service.. # ***** QualNet Configuration File ***** # ************* General *********** # ************* General *********** VERSION 3.7 EXPERIMENT-NAME zzz SIMULATION-TIME 10000S # The random number seed is used to initialize part of the seed of various # randomly generated numbers in the simulation. Use different seeds to see # the consistency of the results of the simulation. SEED 11.

(43) A.0 # ************* Parallel Settings *********** # Method for assigning nodes to parallel partitions PARTITION-SCHEME AUTO # ************* Terrain *********** # The size of the physical terrain in which the nodes are being simulated. COORDINATE-SYSTEM CARTESIAN # The size of the terrain in meters. TERRAIN-DIMENSIONS ( 1500, 1500 ) # Terrain altitude in meters. DUMMY-ALTITUDES ( 1500, 1500 ) # If this is set to YES, the simulation terminates when it attempts to use # an elevation not included in the terrain data files. If it is NO, the # execution simply assumes that such elevations are 0.0. TERRAIN-DATA-BOUNDARY-CHECK YES # ************* Node Positioning *********** # ************* Nodes *********** # The number of nodes being simulated. DUMMY-NUMBER-OF-NODES 7 # The node placement strategy. NODE-PLACEMENT FILE NODE-POSITION-FILE C:\qualnet\3.7\gui\scenarios\congestion\congestion.nodes # ************* Mobility *********** MOBILITY NONE MOBILITY-POSITION-GRANULARITY 1.0 # If yes, nodes get their altitude coordinate from the terrain file, # if one is specified. MOBILITY-GROUND-NODE NO # ************* Wireless Settings *********** # ************* Channel *********** PROPAGATION-CHANNEL-FREQUENCY 2400000000 PROPAGATION-MODEL STATISTICAL # Signals with powers below PROPAGATION-LIMIT (in dBm) (before the antenna # gain at the receiver) are not delivered. PROPAGATION-LIMIT -111.0 PROPAGATION-PATHLOSS-MODEL TWO-RAY PROPAGATION-SHADOWING-MODEL CONSTANT # in dB PROPAGATION-SHADOWING-MEAN 4.0 PROPAGATION-FADING-MODEL NONE. 41.

(44) A.0. 42. # ************* Radio/Physical Layer *********** PHY-MODEL PHY802.11b PHY802.11-AUTO-RATE-FALLBACK NO # bandwidth in bps. supported data rates: 1Mbps, 2Mbps, 5.5Mbps, 11Mbps PHY802.11-DATA-RATE 2000000 PHY802.11b-TX-POWER--1MBPS 15.0 PHY802.11b-TX-POWER--2MBPS 15.0 PHY802.11b-TX-POWER--6MBPS 15.0 PHY802.11b-TX-POWER-11MBPS 15.0 PHY802.11b-RX-SENSITIVITY--1MBPS -93.0 PHY802.11b-RX-SENSITIVITY--2MBPS -89.0 PHY802.11b-RX-SENSITIVITY--6MBPS -87.0 PHY802.11b-RX-SENSITIVITY-11MBPS -83.0 PHY802.11-ESTIMATED-DIRECTIONAL-ANTENNA-GAIN 15.0 PHY-RX-MODEL PHY802.11b # Channels the radio is capable of listening to. PHY-LISTENABLE-CHANNEL-MASK 1 # Channels the radio is currently listening to. Can be changed during run time. PHY-LISTENING-CHANNEL-MASK 1 # Temperature of the environment in K PHY-TEMPERATURE 290.0 PHY-NOISE-FACTOR 10.0 ANTENNA-MODEL OMNIDIRECTIONAL # antenna gain in dB ANTENNA-GAIN 0.0 # antenna height in meters ANTENNA-HEIGHT 1.5 # efficiency of the antenna ANTENNA-EFFICIENCY 0.8 # antenna mismatch loss in dB ANTENNA-MISMATCH-LOSS 0.3 # antenna cable loss in dB ANTENNA-CABLE-LOSS 0.0 # antenna connection loss in dB ANTENNA-CONNECTION-LOSS 0.2 # ************* MAC Protocol *********** MAC-PROTOCOL MAC802.11 MAC-802.11-DIRECTIONAL-ANTENNA-MODE NO MAC-802.11-SHORT-PACKET-TRANSMIT-LIMIT 7 MAC-802.11-LONG-PACKET-TRANSMIT-LIMIT 4 MAC-802.11-RTS-THRESHOLD 0 # specifies an additional delay for messages sent by the MAC layer to the # phy layer. Some MAC protocols use a multiple of this value. MAC-PROPAGATION-DELAY 1US # must be set to YES if nodes want to overhear packets destined to the # neighboring node. PROMISCUOUS-MODE YES.

(45) A.0. 43. # ************* Network Protocols *********** # ************* Network Protocol *********** NETWORK-PROTOCOL IP IP-QUEUE-NUM-PRIORITIES 3 IP-QUEUE-PRIORITY-INPUT-QUEUE-SIZE 50000 DUMMY-PRIORITY-QUEUE-SIZE NO IP-QUEUE-PRIORITY-QUEUE-SIZE 50000 DUMMY-PRIORITY-WISE-IP-QUEUE-TYPE NO IP-QUEUE-TYPE FIFO # ECN as presented in RFC 2481. Requires one of the IP-QUEUE-TYPE # (RED, RIO, or WRED). Furthermore, the source and destination nodes # must be ECN enabled. ECN NO IP-QUEUE-SCHEDULER STRICT-PRIORITY # ************* Routing Protocol *********** DUMMY-ROUTING DYNAMIC ROUTING-PROTOCOL AODV # The maximum possible number of hops between two nodes in the network AODV-NET-DIAMETER 35 # Conservative estimate of the average one hop traversal time for packets # and should include queuing, transmission, propagation and other delays AODV-NODE-TRAVERSAL-TIME 40MS # Timeout time for an active route; each time a data packet is received, # the lifetime of that route is updated to this value. A default value # of 10 seconds is suggested for error detection through MAC layer message # (like what 802.11 does) AODV-ACTIVE-ROUTE-TIMEOUT 3S # The destination of a RREQ replies with AODV-MY-ROUTE-TIMEOUT as the # lifetime of the route. AODV-MY-ROUTE-TIMEOUT 6S # Lifetime of a hello message is determined by # AODV-ALLOWED_HELLO_LOSS * AODV-HELLO_INTERVAL AODV-HELLO-INTERVAL 1S # Lifetime of a hello message is determined by # AODV-ALLOWED_HELLO_LOSS * AODV-HELLO_INTERVAL AODV-ALLOWED-HELLO-LOSS 2 # Specifies the number of times AODV will repeat expanded ring search for # a destination if no Route Reply is received within specified amount of time. AODV-RREQ-RETRIES 2 # A constant use for calculating the time after which an active route should # be deleted. After timeout of an active route, the route is finally deleted # from the routing table after a time period of # (K * max (AODV-ACTIVE_ROUTE_TIMEOUT, AODV-ALLOWED_HELLO_LOSS * AODV-HELLO_INTERVAL)), # Here K is AODV-ROUTE-DELETION-CONSTANT. AODV-ROUTE-DELETION-CONSTANT 5 # If the value is set to YES, a node will send a hello message if there is # no broadcast within the last hello interval. Simulation time will increase # depending on the frequency of the hello updates. AODV-PROCESS-HELLO NO.

(46) A.0. 44. # If this value is set to YES, the node will try to locally repair a broken # route, if possible. AODV-LOCAL-REPAIR NO # If the source node of a route gets a route error message, it will initiate # a new Route Request for the destination if the value is set to YES. AODV-SEARCH-BETTER-ROUTE NO # Maximum number of packets the message buffer of AODV can hold. If the buffer # fills up, incoming packets for the buffer will be dropped. AODV-BUFFER-MAX-PACKET 100 # If nothing is specified, buffer overflow will be checked by number of packets # in the buffer. If some value is specified here, incoming packets will be # dropped if the incoming packet size + current size of the buffer exceeds this value. AODV-BUFFER-MAX-BYTE 0 AODV-OPEN-BI-DIRECTIONAL-CONNECTION YES AODV-TTL-START 1 AODV-TTL-INCREMENT 2 AODV-TTL-THRESHOLD 7 HSRP-PROTOCOL NO # Static routes have priority over those discovered by routing protocols STATIC-ROUTE NO # Default routes have less priority than static routes and those # discovered by routing protocols DEFAULT-ROUTE YES DEFAULT-ROUTE-FILE C:\qualnet\3.7\gui\scenarios\congestion\congestion.routes-default # ************* MPLS configuration *********** MPLS-PROTOCOL NO # ************* Transport Layer *********** TCP TAHOE TCP-DELAY-ACKS YES TCP-DELAY-SHORT-PACKETS-ACKS TCP-USE-NAGLE-ALGORITHM YES TCP-USE-KEEPALIVE-PROBES YES TCP-USE-PUSH YES TCP-MSS 512 [1] TCP-RANDOM-DROP-PERCENT [2] TCP-RANDOM-DROP-PERCENT [3] TCP-RANDOM-DROP-PERCENT [4] TCP-RANDOM-DROP-PERCENT [5] TCP-RANDOM-DROP-PERCENT [6] TCP-RANDOM-DROP-PERCENT [7] TCP-RANDOM-DROP-PERCENT. NO. 5 5 5 5 5 5 5. [1] TCP-TRACE TCPDUMP-ASCII [1] TCP-TRACE-DIRECTION INPUT TCP-SEND-BUFFER 16384 TCP-RECEIVE-BUFFER 16384 # ************* Traffic and Status ***********.

(47) A.0. # ************* Application Layer *********** # Used to setup applications such as FTP and Telnet. Will be added to any # applications configured manually. APP-CONFIG-FILE C:\qualnet\3.7\gui\scenarios\congestion\congestion.app # ************* Extras *********** # ************* Tracing *********** # Generates trace data compatible with Tracer viewing tool. PACKET-TRACE NO ACCESS-LIST-TRACE NO # ************* Statistics *********** # ************* Statistics *********** # All the statistics are compiled together into a file called # "ExperimentName.stat"(where experiment name is specified on the General # settings) at the end of the simulation. APPLICATION-STATISTICS YES TCP-STATISTICS YES UDP-STATISTICS YES ROUTING-STATISTICS YES ICMP-STATISTICS NO IGMP-STATISTICS NO EXTERIOR-GATEWAY-PROTOCOL-STATISTICS YES NETWORK-LAYER-STATISTICS YES QUEUE-STATISTICS YES SCHEDULER-STATISTICS YES MAC-LAYER-STATISTICS YES PHY-LAYER-STATISTICS YES MOBILITY-STATISTICS YES MPLS-STATISTICS NO MPLS-LDP-STATISTICS NO RSVP-STATISTICS NO SRM-STATISTICS NO DIFFSERV-EDGE-ROUTER-STATISTICS NO QOSPF-STATISTICS NO # Network Statistics should be on ACCESS-LIST-STATISTICS NO ROUTE-REDISTRIBUTION-STATISTICS NO H323-STATISTICS NO # ************* Node Specific *********** # ************* Device properties ***********. 45.

(48) A.0. USE-NODE-ICON YES NODE-ICON C:\qualnet\3.7\gui\scenarios\congestion\DEFAULT.GIF # ************* Router Specs *********** # ************* Router Configuration Specs *********** # ************* Node Orientation *********** AZIMUTH 0 ELEVATION 0 # ************* Parallel Properties *********** # Parallel partition to which to assign node. PARTITION 0 LINK N8-192.0.0.0 { 1, 4 } [ 192.0.0.1 192.0.0.2 ] LINK-PHY-TYPE WIRED [ 192.0.0.1 192.0.0.2 ] LINK-PROPAGATION-DELAY 1MS [ 192.0.0.1 192.0.0.2 ] LINK-BANDWIDTH 10000000 [ 192.0.0.1 192.0.0.2 ] NETWORK-PROTOCOL IP [ 192.0.0.1 192.0.0.2 ] SWITCH-STATION-VLAN-ID 0 [ 192.0.0.1 192.0.0.2 ] SWITCH-STATION-VLAN-TAGGING NO LINK N8-192.0.1.0 { 2, 4 } [ 192.0.1.1 192.0.1.2 ] LINK-PHY-TYPE WIRED [ 192.0.1.1 192.0.1.2 ] LINK-PROPAGATION-DELAY 1MS [ 192.0.1.1 192.0.1.2 ] LINK-BANDWIDTH 10000000 [ 192.0.1.1 192.0.1.2 ] NETWORK-PROTOCOL IP [ 192.0.1.1 192.0.1.2 ] SWITCH-STATION-VLAN-ID 0 [ 192.0.1.1 192.0.1.2 ] SWITCH-STATION-VLAN-TAGGING NO LINK N8-192.0.2.0 { 3, 4 } [ 192.0.2.1 192.0.2.2 ] LINK-PHY-TYPE WIRED [ 192.0.2.1 192.0.2.2 ] LINK-PROPAGATION-DELAY 1MS [ 192.0.2.1 192.0.2.2 ] LINK-BANDWIDTH 10000000 [ 192.0.2.1 192.0.2.2 ] NETWORK-PROTOCOL IP [ 192.0.2.1 192.0.2.2 ] SWITCH-STATION-VLAN-ID 0 [ 192.0.2.1 192.0.2.2 ] SWITCH-STATION-VLAN-TAGGING NO LINK N8-192.0.3.0 { 4, 5 } [ 192.0.3.1 192.0.3.2 ] LINK-PHY-TYPE WIRED [ 192.0.3.1 192.0.3.2 ] LINK-PROPAGATION-DELAY 1MS [ 192.0.3.1 192.0.3.2 ] LINK-BANDWIDTH 10000000 [ 192.0.3.1 192.0.3.2 ] NETWORK-PROTOCOL IP [ 192.0.3.1 192.0.3.2 ] SWITCH-STATION-VLAN-ID 0 [ 192.0.3.1 192.0.3.2 ] SWITCH-STATION-VLAN-TAGGING NO. 46.

(49) A.0 LINK N8-192.0.4.0 { 5, 6 } [ 192.0.4.1 192.0.4.2 ] LINK-PHY-TYPE WIRED [ 192.0.4.1 192.0.4.2 ] LINK-PROPAGATION-DELAY 1MS [ 192.0.4.1 192.0.4.2 ] LINK-BANDWIDTH 10000000 [ 192.0.4.1 192.0.4.2 ] NETWORK-PROTOCOL IP [ 192.0.4.1 192.0.4.2 ] SWITCH-STATION-VLAN-ID 0 [ 192.0.4.1 192.0.4.2 ] SWITCH-STATION-VLAN-TAGGING NO LINK N8-192.0.5.0 { 5, 7 } [ 192.0.5.1 192.0.5.2 ] LINK-PHY-TYPE WIRED [ 192.0.5.1 192.0.5.2 ] LINK-PROPAGATION-DELAY 1MS [ 192.0.5.1 192.0.5.2 ] LINK-BANDWIDTH 10000000 [ 192.0.5.1 192.0.5.2 ] NETWORK-PROTOCOL IP [ 192.0.5.1 192.0.5.2 ] SWITCH-STATION-VLAN-ID 0 [ 192.0.5.1 192.0.5.2 ] SWITCH-STATION-VLAN-TAGGING NO [ 1 thru 7 ] TCP RENO IP-FORWARDING NO [ 4 5 ] IP-FORWARDING YES [ 1 thru 7 ] MOBILITY NONE COMPONENT 0 {1 2 3 4 5 6 7} 7 750.0 750.0 0.0 1500.0 1500.0 3000.0. 47.

(50) Apéndice B Archivo *.stat Se presentan los resultados de una simulación, en éste caso en particular se presentan los resultados pertinentes a las capas de transporte y de aplicación, asociados al nodo 1 y al nodo 6 obtenidos al simular el escenario con la variante Vegas, con semilla 4 y con un 4 % de los paquetes saboteados. Sólo se presenta lo relacionado con el nodo 1 y lo relacionado con el nodo 6 y sólo lo relacionado con la capa de transporte y la capa de aplicación debido a que de ahí se saca la información relevante para hacer los análisis. 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,. , , , , , , , , , , , , , , , , , , , , , ,. , , , , , , , , , , , , , , , , , , , , , ,. Transport, Transport, Transport, Transport, Transport, Transport, Transport, Transport, Transport, Transport, Transport, Transport, Transport, Transport, Transport, Transport, Transport, Transport, Transport, Transport, Transport, Transport,. UDP,Packets from Application Layer = 0 UDP,Packets to Application Layer = 0 TCP,Packets Sent to Network Layer = 6508 TCP,Data Packets Sent = 6404 TCP,Data Packets in Sequence = 6160 TCP,Data Packets Retransmitted = 244 TCP,Data Packets Fast Retransmitted = 122 TCP,ACK-only Packets Sent = 102 TCP,Pure Control (SYN|FIN|RST) Packets Sent = 2 TCP,Window Update-Only Packets Sent = 0 TCP,Window Probes Sent = 0 TCP,Total Packets Received From Network Layer = 3658 TCP,Data Packets Received = 100 TCP,In Sequence ACK Packets Received = 2772 TCP,Duplicate ACK Packets Received = 784 TCP,Pure Control (SYN|FIN|RST) Packets Received = 2 TCP,Window Update-Only Packets Received = 0 TCP,Window Probes Received = 0 TCP,Total Packets with Errors = 0 TCP,Packets Received with Checksum Errors = 0 TCP,Packets Received with Bad Offset = 0 TCP,Packets Received that are Too Short = 0.

(51) B.0 1, 1, 1, 1, 1, 1, 1,. 49 , , , , , , ,. [1], [1], [1], [1], [1], [1], [1],. Application, Application, Application, Application, Application, Application, Application,. FTP FTP FTP FTP FTP FTP FTP. Client,Server address = 192.0.4.2 Client,First Packet Sent at (s) = 1.102827660 Client,Last Packet Sent at (s) = 125.410912286 Client,Session Status = Closed Client,Total Bytes Sent = 3123596 Client,Total Bytes Received = 3004 Client,Throughput (bits/s) = 201022.

(52) Apéndice C Archivo tcptrace.ascii Se presenta parte del archivo tcptrace.ascii con las variables relevantes a tcp impresas cada vez que se recibía un paquete: las últimas dos variables (RTT y snd_cwnd) no vienen programadas para salir, se modicó el código del programa para poder mostrarlas. 0:3:48.465442479 0:3:48.473461679 0:3:48.481480879 0:3:48.489036079 0:3:48.496591279 0:3:48.504146479 0:3:48.511701679 0:3:48.512629679 0:3:48.519720879 0:3:48.520648879 0:3:48.527276079 0:3:49.967180933 0:3:49.975200133 0:3:49.983219333 0:3:49.990774533 0:3:49.998329733 0:3:50.005884933 0:3:50.013440133 0:3:50.014368133 0:3:50.021459333 0:3:50.029014533 0:3:50.029478533 0:3:50.036569733 0:3:50.037033733 0:3:50.044588933 0:3:50.052608133 0:3:50.060163333 0:3:50.068182533 0:3:50.075737733. 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21. > > > > > > > > > > > > > > > > > > > > > > > > > > > > >. 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024:. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack. 2428475 2429499 2430523 2431547 2432571 2433595 2434619 2435643 2436667 2436667 2436667 2438203 2439227 2440251 2441275 2442299 2443323 2444347 2445371 2446395 2446907 2446907 2446907 2446907 2449467 2450491 2451515 2452027 2452027. win win win win win win win win win win win win win win win win win win win win win win win win win win win win win. 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384. rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt. 0 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1. snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd. 1 2 3 3 3 3 4 4 4 4 4 1 2 3 3 3 3 4 4 4 4 5 5 5 5 3 3 3 3.

(53) C.0 0:3:51.469457451 0:3:51.477476651 0:3:51.485495851 0:3:51.493051051 0:3:51.500606251 0:3:51.508161451 0:3:51.515716651 0:3:51.516644651 0:3:51.523735851 0:3:51.524663851 0:3:51.531755051 0:3:51.532683051 0:3:51.539310251 0:3:51.540238251 0:3:51.540702251 0:3:51.546865451 0:3:51.547329451 0:3:51.554884651 0:3:51.562439851 0:3:51.569995051 0:3:51.577550251 0:3:51.585105451 0:3:51.592660651 0:3:51.600215851 0:3:51.607771051 0:3:51.615326251 0:3:51.622881451 0:3:51.630436651 0:3:51.637991851 0:3:51.645547051 0:3:51.653102251 0:3:51.660657451 0:3:52.971493761 0:3:52.979512961 0:3:52.987532161 0:3:52.995087361 0:3:52.996015361 0:3:53.003106561 0:3:53.004034561 0:3:53.010661761 0:3:53.012053761 0:3:53.012517761 0:3:53.012981761 0:3:53.018216961 0:3:53.018680961 0:3:53.020536961 0:3:53.028556161 0:3:53.029484161 0:3:53.036111361 0:3:53.037039361 0:3:53.043666561 0:3:53.044594561 0:3:53.051221761. 51 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21 192.0.4.2.21. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >. 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024: 192.0.0.1.1024:. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack ack. 2453563 2454587 2455611 2456635 2457659 2458683 2459707 2460731 2461755 2462779 2463803 2464827 2465851 2465851 2465851 2465851 2465851 2465851 2465851 2465851 2465851 2465851 2465851 2465851 2465851 2465851 2465851 2465851 2465851 2465851 2465851 2465851 2476091 2477115 2478139 2479163 2480187 2481211 2482235 2482747 2482747 2482747 2482747 2482747 2482747 2487355 2488379 2489403 2490427 2491451 2492475 2493499 2494523. win win win win win win win win win win win win win win win win win win win win win win win win win win win win win win win win win win win win win win win win win win win win win win win win win win win win win. 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384 16384. rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt rtt. 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 1 0 0 0 1 1 1 1 1 1 1. snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd snd_cwnd. 1 2 3 3 3 3 4 4 4 4 5 5 5 5 5 5 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 1 2 3 4 5 6 7 8 9 9 9 7 8 9 5 5 5 5 5 5 6.