Análisis y evaluación de los mecanismos de control de la congestión en Redes IP

Texto completo

(1)Departamento de Electrónica y Telecomunicaciones. TRABAJO DE DIPLOMA. Análisis y evaluación de los mecanismos de control de la congestión en Redes IP. Autor: Edgar G. Yero Igarza. Tutor: Dr. Félix Álvarez Paliza. Santa Clara 2009. “Año 50 de la Revolución”.

(2) Universidad Central “Marta Abreu” de Las Villas Facultad de Ingeniería Eléctrica Departamento de Electrónica y Telecomunicaciones. TRABAJO DE DIPLOMA Análisis y evaluación de los mecanismos de control de la congestión en Redes IP Autor: Edgar G. Yero Igarza E-mail: [email protected] Tutor: Dr. Félix Álvarez Paliza E-mail: [email protected] Santa Clara 2009 "Año 50 de La Revolución".

(3) Hago constar que el presente trabajo de diploma fue realizado en la Universidad Central “Marta Abreu” de Las Villas como parte de la culminación de estudios de la especialidad de Ingeniería en Automática, autorizando a que el mismo sea utilizado por la Institución, para los fines que estime conveniente, tanto de forma parcial como total y que además no podrá ser presentado en eventos, ni publicados sin autorización de la Universidad.. Firma del Autor Los abajo firmantes certificamos que el presente trabajo ha sido realizado según acuerdo de la dirección de nuestro centro y el mismo cumple con los requisitos que debe tener un trabajo de esta envergadura referido a la temática señalada.. Firma del Tutor. Firma del Jefe de Departamento donde se defiende el trabajo. Firma del Responsable de Información Científico-Técnica.

(4) i. PENSAMIENTO. “Si avanzo, seguidme; si me detengo, empujadme; si retrocedo, matadme.” Ernesto Che Guevara.

(5) ii. DEDICATORIA. A mis padres por ser un caudal inagotable de amor, por brindarme su apoyo incondicional, darme confianza y ser siempre la luz que ilumina mi camino..

(6) iii. AGRADECIMIENTOS. A mis padres por todo su amor incondicional y porque siguiendo su ejemplo he logrado las mejores cosas de mi vida. A Dios por haberme concedido este gran deseo. A mi abuela por su inmenso amor y cariño. A mi tutor Dr. Félix Álvarez Paliza por su dedicación, su tiempo y por haberme ofrecido todo su conocimiento y experiencia. A mis compañeros de aula y amigos de toda la vida. A todas las personas que han contribuido cabalmente en el transcurso de mi carrera y que han brindado todo su cariño, ayuda y confianza hacia mí..

(7) iv. TAREA TÉCNICA. 1. Análisis bibliográfico sobre los mecanismos de control de la congestión. 2. Selección y estudio de trabajos relacionados con los mecanismos de control de la congestión en redes IP. 3. Trabajo con simulador OPNET Modeler. 4. Selección de un proyecto de red como modelo de estudio. 5. Preparación y ejecución de las simulaciones en diferentes escenarios para diferentes mecanismos de control de la congestión. 6. Análisis de los resultados obtenidos. 7. Informe final del trabajo de diploma.. Firma del Autor. Firma del Tutor.

(8) v. RESUMEN. El propósito de este documento es analizar y comparar las diferentes mecanismos de control de la congestión y las formas de evitarla las cuales se han propuesto para el protocolo TCP/IP, particularmente en las implementaciones: Tahoe, Reno, Nuevo Reno, TCP Vegas y Sack. La solidez de TCP es como resultado de su conducta reactiva a la congestión y que la fiabilidad es garantizada por volver a las transmisiones. Todas las implementaciones mencionadas anteriormente, sugieren mecanismos para la determinación de cuando un segmento se debe volver a retransmitir y cómo debe comportarse el emisor cuando se enfrenta a la congestión y que modelo de transmisión debe seguirse para evitar la congestión. En este trabajo desarrolla un análisis pormenorizado de los diferentes factores que afectan la capacidad, la eficiencia y el rendimiento de TCP..

(9) vi. TABLA DE CONTENIDOS. PENSAMIENTO .....................................................................................................................i DEDICATORIA .................................................................................................................... ii AGRADECIMIENTOS ........................................................................................................ iii TAREA TÉCNICA................................................................................................................iv RESUMEN .............................................................................................................................v INTRODUCCIÓN ..................................................................................................................1 CAPÍTULO 1.. Análisis de los mecanismos de control de la congestión y de las diferentes. puestas en explotación del protocolo TCP..............................................................................5 1.1. Introducción ............................................................................................................5. 1.2. Protocolos TCP .......................................................................................................5. 1.3. Conclusiones del capítulo. ......................................................................................9. CAPÍTULO 2.. Fundamentación teórica de los nuevos mecanismos de control de la. congestión.. 10. 2.1. Introducción ..........................................................................................................10. 2.2. Mecanismo de control de la congestión................................................................10. 2.3. Conclusiones del capítulo .....................................................................................18. CAPÍTULO 3.. Modelación y simulación de diferentes escenarios. Presentación y análisis. de los resultados. 20 3.1. Introducción ..........................................................................................................20.

(10) vii 3.2. Configuración de la simulación ............................................................................20. 3.3. Análisis y obtención de los resultados..................................................................21. 3.3.1. Comportamiento de la ventana de control de la congestión .........................21. 3.3.2. Comportamiento del retardo, la razón de transferencia y la respuesta de. bajada de ficheros por el servicio de FTP con una pérdida de ráfaga conteniendo dos segmentos de un mismo flujo. ......................................................................................25 3.3.3. Comportamiento del retardo, la razón de transferencia y la respuesta de. bajada de ficheros por el servicio de FTP con dos pérdidas de ráfagas conteniendo dos segmentos de un mismo flujo. ......................................................................................27 3.4. Conclusiones del capítulo .....................................................................................30. CONCLUSIONES Y RECOMENDACIONES ...................................................................31 Conclusiones.....................................................................................................................31 Recomendaciones .............................................................................................................32 REFERENCIAS BIBLIOGRÁFICAS .................................................................................33 ANEXOS I Encabezado IP V.4 ............................................................................................37 ANEXOS II Formato del encabezado TCP .........................................................................39 GLOSARIO ..........................................................................................................................41.

(11) INTRODUCCIÓN. 1. INTRODUCCIÓN. TCP es el protocolo del nivel de transporte que da un servicio orientado a la conexión. Ocupándose de detectar y recuperar los errores del nivel de red.. Usa mecanismos de retransmisión basados en el algoritmo de ventanas deslizantes de transmisión con el fin de recuperar errores del nivel de red como paquetes perdidos o duplicados. También se ocupa del control de flujo entre las dos máquinas participantes en la comunicación.. Ese servicio de entrega confiable, orientado a la conexión y de flujo de octetos lo proporciona el protocolo TCP, el cuál fue definido en la RFC 793 en 1981, posteriormente en la RFC 1122 de 1989, se estableció su implementación y hasta los días de hoy ha recibido diferentes aportes (RFC 1323, RFC 2581, etc.) y cambios que serán indicados en este trabajo de diploma. El protocolo TCP se caracteriza por 5 funciones: -. Orientado a la conexión. -. Flujo de octetos entregados en orden. -. Conexión simultánea en ambas direcciones (full-duplex). -. Control de flujo mediante ventanas deslizantes. -. Flujo no estructurado.

(12) INTRODUCCIÓN. 2. Además el mismo posee un mecanismo de control de la congestión bien ajustado que es el objeto de estudio principal de este trabajo.. TCP tiene que enfrentar diferentes problemáticas para trabajar correctamente: 1- TCP tiene que soportar conexiones lógicas entre procesos que se están desarrollando entre dos estaciones en Internet. 2- En las conexiones TCP los tiempos de ida y vuelta (RTT) de los mensajes tienen marcadas diferencias. 3- Los paquetes tienen que ser reordenados a medida que atraviesan la interconexión, por lo que TCP tiene que estar preparado para recibir paquetes viejos y jugar con el tiempo de vida máximo de un segmento (MSL). 4- TCP tiene que incluir un mecanismo a cada lado de la conexión para “aprender” que recursos (por ejemplo que tamaño de Buffer) deben estar disponibles para la conexión. 5- En una conexión TCP en el lado del emisor no se tiene idea de los enlaces que serán atravesados para alcanzar el destino, por lo que hay que desarrollar mecanismos para evitar la congestión.. O sea que TCP tiene que vencer esas y otras situaciones para poder ser un protocolo que garantice una entrega confiable y ordenada.. Luego el objetivo fundamental de este trabajo es el control de la congestión en una Red IP, basada en el conjunto de protocolos TCP/IP. Aspecto que es complejo y difícil de abordar, lo que ha requerido numerosas investigaciones, experimentos y artículos durantes años. La tarea es difícil debido a los factores siguientes: 1. El protocolo IP es sin conexión y no ofrece formas para detectar y menos para controlar la congestión..

(13) INTRODUCCIÓN. 3. 2. TCP ofrece solamente control de flujo de extremo a extremo y solo puede deducir la presencia de congestión dentro de la red por métodos indirectos (por retardos). 3. No existencia de algoritmos distribuidos de cooperación entre entidades TCP.. La única herramienta en TCP que se relaciona con la congestión de la red son los mecanismos de control de flujo de ventanas deslizantes y los de control de error. Sin embargo algunas técnicas mas astutas han sido desarrolladas que posibilitan el uso de mecanismos para detectar, evitar y recuperarse de la congestión.. Por lo que es necesario primero profundizar más en los mecanismos de control de flujo de TCP, partiendo de la premisa de que la razón a la cuál una entidad TCP puede enviar datos está determinada por la razón de la llegada de reconocimientos ACK de los segmentos previos con nuevos créditos. Sin embargo en el caso de TCP la razón de arribo de los reconocimientos ACK está determinada por el cuello de botella en la trayectoria de ida y vuelta entre fuente y destino o por el cuello de botella que exista en el destino. Por ello como objetivos específicos está el análisis de los diferentes algoritmos para control de la congestión basados en TCP:. 1. Slow Start y Congestion Avoidance. 2. Fast Retransmit y Fast Recovery. 3. ACK Selectivo.. Para poder enfrentar las diferentes tareas del trabajo, el mismo se ha dividido acorde a la estructura siguiente: CAPITULO 1 Análisis del Estado del Arte en los mecanismos de control de la congestión y de las diferentes puestas en explotación del protocolo TCP. CAPITULO 2.

(14) INTRODUCCIÓN. 4. Fundamentación teórica de los nuevos mecanismos de control de congestión. CAPITULO 3 Modelación y simulación de diferentes escenarios. Presentación y análisis de los resultados. Conclusiones Recomendaciones Bibliografía Anexo.

(15) CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA. 5. CAPÍTULO 1. Análisis de los mecanismos de control de la congestión y de las diferentes puestas en explotación del protocolo TCP. 1.1. Introducción. TCP es un protocolo orientado a conexión de extremo a extremo, fiable. Contiene en sí mismo mecanismos para garantizar por la fiabilidad que requiere el receptor para reconocer los segmentos que recibe. La red no es perfecta y un pequeño porcentaje de los paquetes se pierden en ruta, ya sea debido a error de la red o por el hecho de que hay congestión en la red y los enrutadores están perdiendo paquetes. Las pérdidas de paquetes debidas a la red son mínimas y la mayoría de las pérdidas de paquetes se deben a los desbordamientos de la memoria (buffer) en los Router. Desde la publicación de la RFC 793 un número apreciable de técnicas han sido introducidas para mejorar las características de TCP en cuanto a control de la congestión. 1.2. Protocolos TCP. TCP Tahoe La versión TCP Tahoe se incorporó al sistema operativo BSD en 1988. Fue la primera en incorporar los mecanismos de control de congestión y de estimación de RTT propuestos por Van Jacobson [1]. El primero de los mecanismos que fue introducido fue el de Inicio Lento, y el segundo el de la estimación de RTT basado, además de la media, en medidas de la varianza. Otro mecanismo incorporado fue el de congestion avoidance. Por último, se introdujo el mecanismo de fast retransmit. TCP Tahoe tiene por tanto los mecanismos básicos de congestión y recuperación de pérdidas, y es el más común en las implementaciones actuales. No obstante, el principal inconveniente que presenta es el del slow start, concretamente en enlaces de retardo elevado, provocando el bajo rendimiento del protocolo. TCP Reno La versión TCP Reno se incorporó al sistema operativo BSD en 1990. Éste incorpora todas las características de TCP Tahoe y añade el algoritmo de fast recovery que actúa.

(16) CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA. 6. conjuntamente con el de fast retransmit [2]. De esta forma, tras la retransmisión no se invoca el algoritmo de slow start, sino el de congestion avoidance, permitiendo una recuperación más rápida tras la retransmisión. El inconveniente más destacado es que, en caso de tener múltiples pérdidas por ventana, el protocolo de retransmisión rápida no puede recuperar de forma rápida más que la primera pérdida. [4]. Fast TCP Fast TCP es un algoritmo de control de congestión para TCP, diseñado por investigadores del “Californian Institute of Technology” y que últimamente está dando de que hablar por la capacidad que tendría dicho algoritmo de incrementar las velocidades de transferencia en Internet, sin necesidad de modificar la infraestructura actual. En pocas palabras, actualmente Internet funciona bajo Reno TCP, diseñado en 1988 y que transmite paquetes de 1500 bytes, esperando confirmaciones del receptor. Si no hay respuesta, se retransmite un paquete a menor velocidad hasta que llega correctamente. Por el contrario, Fast TCP mide constantemente el tiempo que tardan en llegar los paquetes transmitidos, analizando retrasos y prediciendo la tasa de transferencia que podrá soportar la conexión para que no se produzcan perdidas. Con este sistema, se han llegado a alcanzar en Internet velocidades de 100 Gb/s en conexiones transatlánticas. TCP New Reno La versión TCP New Reno propone una modificación al algoritmo de fast recovery [3] de forma que en caso de que existan varias pérdidas por ventana se soluciona el problema de TCP Reno.[13] TCP Sack TCP Sack fue propuesto para resolver el problema existente en New Reno cuando hay múltiples pérdidas de paquetes de una ventana. En TCP Sack se usan los reconocimientos para que el transmisor tome decisiones inteligentes respecto a los paquetes descartados, con esto se aumenta el throughput y evita innecesarias retransmisiones de paquetes que ya fueron entregados al receptor mejorando así el desempeño..

(17) CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA. 7. TCP Sack mantiene las fases slow start y fast retransmit. Además posee timeout robusto para pérdida de paquetes, en caso que una pérdida no sea detectada por el algoritmo modificado. [5] TCP Vegas En 1995 se propone el protocolo denominado TCP Vegas. En ella se modifican algunos aspectos de los algoritmos de fast retransmit y fast recovery, así y como del de slow start. Como aspecto más relevante, no obstante, es la propuesta a actuar contra la congestión antes de que ésta se detecte por la expiración del temporizador de retransmisión. TCP Vegas introduce un algoritmo para la predicción de la cantidad de datos que el enlace puede cursar sin congestión, e inyecta en el enlace dicha cantidad. Esta predicción se basa en medidas de caudal. [6] TCP Amigable En el TCP Vegas, los ajustes de la ventana trabajan un poco más ligado a evitar la congestión [7]. La ventana de congestión aumenta linealmente si el RTT muestreado esta relativamente bajo, o disminuye linealmente si el RTT está relativamente alto. Aunque el TCP Vegas puede lograr un rendimiento más alto del sistema que el TCP estándar, este no puede garantizar equidad. A pesar de que. el control de congestión de TCP es básicamente apropiado para. transferencias de gran cantidad de datos, algunas aplicaciones de tiempo real como Video y Voz experimentan un disminución de la mitad de su tráfico, incluso cuando la ventana de congestión no necesita tal disminución del tráfico, causando esto. oscilaciones y en. ocasiones ruptura en la transmisión [8]. La suavidad del tráfico es esencial para las aplicaciones de tiempo real. Los protocolos TCP Amigable [9],[10] tienen dos propósitos fundamentales: 1.. Lograr ajustes del decrecimiento de la ventana; Esto se logra por el incremento de la. razón de decrecimiento de la ventana durante la congestión. 2.. Mantener el control sobre los flujos TCP; Esto es logrado reduciendo el paso de. incremento de transmisión de la ventana, manteniendo la estabilidad del TCP.. Esto.

(18) CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA. 8. significa que el protocolo TCP Amigable favorece la suavidad de la transmisión para aplicaciones de multimedia mediante el uso de un decremento suave en un incremento en la ventana de congestión. A continuación, para resumir lo expuesto anteriormente, se muestra en una tabla las técnicas más populares para medir y llevar un control de la congestión en las diferentes aplicaciones de TCP.. Mediciones. RFC. TCP. TCP. TCP. TCP. TCP. 1122. Tahoe. Reno. New Reno. Sack. Vegas. X. X. X. X. X. X. RTO exponencial. X. X. X. X. X. X. Algoritmo de Karn. X. X. X. X. X. X. Arranque suave. X. X. X. X. X. X. Ajuste de Ventana dinámico. X. X. X. X. X. X. X. X. X. X. X. X. X. X. X. X. X. X. Estimación de la variación de RTT. Retransmisión Rápida Recuperación Rápida Recuperación Rápida (Modificado).

(19) CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA. 1.3. 9. Conclusiones del capítulo.. En este capítulo después de un análisis general de los diferentes protocolos TCP se puede concluir que es una protocolo que esta en constante cambios con respecto a lo que va sucediendo en la actualidad, tiende a un cambio muy profundo para hacer un mejor uso del ancho de banda y cambios para reforzar la eliminación de la congestion en la redes de la actualidad..

(20) CAPÍTULO 2. MATERIALES Y METODOS. 10. CAPÍTULO 2. Fundamentación teórica de los nuevos mecanismos de control de la congestión. 2.1. Introducción. En la actualidad han surgido varios mecanismos de control de la congestión debido al incremento de las pérdidas de paquetes y el congestionamiento de la red por dichas pérdidas. Estos mecanismos han ido evolucionando debido a que iban siendo ineficientes a la hora de controlar los tipos de pérdidas en las redes. 2.2. Mecanismo de control de la congestión. Slow Start y Congestion Avoidance Slow Start [18] y Congestion Avoidance [18] son algoritmos totalmente independientes, no obstante, en la práctica, se implementan de manera conjunta. El algoritmo combinado mantiene dos variables para el control de la congestión: una ventana de congestión (cwnd) y un valor umbral (ssthresh) que permite conmutar entre los dos algoritmos. Su funcionamiento es el siguiente: • Inicialmente: cwnd = 1 ssthresh = Wmax (tamaño máximo de la ventana de transmisión) • Cuando ocurre un timeout, la mitad del tamaño actual de la ventana (y como mínimo dos segmentos) se guarda en la variable ssthresh: ssthresh=W/2 Este es el estrechamiento exponencial típico de Prevención de la Congestión. • Asigna a cwnd un único segmento: cwnd=1.

(21) CAPÍTULO 2. MATERIALES Y METODOS. 11. Esto indica el comienzo de slow start. • La llegada de un ACK que reconoce datos nuevos, incrementa el valor de cwnd según el siguiente procedimiento: • Si cwnd ≤ ssthresh significa que estamos en Slow Start por lo que incrementamos cwnd en una unidad. • Si cwnd > ssthresh significa que estamos en congestion avoidance por lo que incrementamos cwnd en 1/cwnd. El emisor siempre envía el mínimo entre cwnd y la ventana de control de flujo o transmisión. Fast Retransmit y Fast Recovery A medida que las redes y los protocolos van evolucionando, se van incorporado nuevos mecanismos, que tienen el propósito de mejorar el comportamiento del protocolo. En concreto los mecanismos de retransmisión y recuperación rápida detallados a continuación [Ste94, RFC2581], intentan optimizar y ajustar los algoritmos descritos anteriormente para adecuar el protocolo TCP a situaciones de congestión y pérdidas en general, y ayudarlo así a recuperarse más rápidamente de las mismas. Este algoritmo se conoce como retransmisión rápida con recuperación rápida ó fast retransmit [14] with fast recovery [14],[16] y opera como sigue: • Cuando llega el tercer ACK duplicado se retransmite el segmento perdido y: ssthresh= cwnd/2 cwnd=ssthresh + 3 • Con cada nuevo ACK duplicado recibido, se incrementa cwnd en una unidad y se transmite un nuevo paquete si lo permite el valor de cwnd. • Cuando se recibe el primer ACK que reconoce nuevos datos:.

(22) CAPÍTULO 2. MATERIALES Y METODOS. 12. cwnd = ssthresh (es decir la mitad del valor que tenía la ventana de congestión cuando se produjo la congestión). Debate sobre suavidad en TCP. Se ha demostrado que incluso cuando el sistema esta. relativamente estable, una. transmisión con ampliaciones de tiempo real (video, voz) no experimentan del todo un tráfico constante, debido a los ajustes no sincronizados de la ventana de transmisión provocados por indicaciones aleatorias de congestión. Analizamos y evaluamos el impacto negativo de los ajustes aleatorios de la ventana en la suavidad del TCP, en la equidad a corto y largo plazo. De aquí que proponemos un mecanismo experimental para evitar la congestión en TCP, basados en los ajustes sincronizados de la ventana, conociendo (α, β, γ, δ), que son parámetros que caracterizan el estado de la ventana de transmisión y poder predecir la congestión o el desaprovechamiento del ancho de banda del canal. La suavidad en el tráfico de TCP es mejorado significativamente para aplicaciones de tiempo real (video, voz), sin un costo en la equidad y la sensibilidad. La sensibilidad es incluso aumentada cuando el ancho de banda es poco utilizado.. Figure 2.1 Dinámica del Control de la Congestión. Primero nosotros extendemos el modelo de análisis de [2] tomando en cuenta la función de la cola de embotellamiento. Considere una simple topología de red mostrada anteriormente en la cual el ancho de banda del enlace y el retardo de propagación están marcados. En nuestro esquema, n Flujos TCP comparten un enlace de embotellamiento, con capacidad del ancho de banda bw, y demora. de lazo de propagación RTTo=2*. (src_delay+delay+sink_delay). Nuestro punto de vista en esta subsección esta en el.

(23) CAPÍTULO 2. MATERIALES Y METODOS. 13. comportamiento general del sistema, nosotros definimos como el tamaño de la ventana de congestión total del sistema en el tiempo t como: n. cwnd (t ) = ∑ cwndi (t ) i =1. (1). Donde cwnd i (t ) es el tamaño de la ventana de cada flujo. Consecuentemente, el rendimiento del sistema en el tiempo (t) debería ser:. throughput(t ) =. cwnd (t ) cwnd (t ) = RTT (t ) RTT0 + qdelay(t ). (2). Donde qdelay(t) es la demora en cola en el router 1 (R1). Asumimos que todos los flujos están en la etapa de incremento aditivo. Primero consideramos el caso donde el tamaño total de la ventana de congestión esta por debajo del punto de Umbral (knee) [11]:. cwnd (knee ) = RTT 0 × bw. (3). Entonces no existe un incremento de la cola en el router R1 (por ejemplo RTT(t)=RTTo), y de acuerdo con la expresión (2), el rendimiento crece proporcionalmente al tamaño de la ventana (cwnd). La capacidad de embotellamiento no es utilizada completamente hasta que la ventana total de los n flujo no se iguale a la ventana umbral cwnd(knee) Si el tamaño de la ventana total se incrementa más allá del umbral cwnd(knee), el sistema muestra diferentes dinámicas. La cola de embotellamiento comienza a construirse después que la capacidad de embotellamiento es saturada. En estas condiciones la ecuación para el tamaño de la ventana total seria igual a:.

(24) CAPÍTULO 2. MATERIALES Y METODOS. cwnd(t ) = cwndknee + ∆w(t )(∆w(t ) > 0) Desde que la mayoría de los paquetes en una ventana cwnd(knee). 14. (4) comiencen a. transmitirse en un RTTo, los paquetes de ∆w(t) se demorarán en la cola. Por lo tanto el retardo en la cola será:. qdelay. (t ) =. ∆ w (t ) bw. (5). Intuitivamente, el rendimiento del sistema estará definido por la capacidad física del ancho de banda (bw), a pesar del incremento de la ventana cwnd(t) más allá del umbral (knee), porque en el denominador de la expresión (2) qdelay(t) crece igualmente. Esto puede ser validado por (6):. (t) = throughput. scwndknee+ ∆w(t) RTT0 ×bw+ qdelay(t) ×bw = = bw RTT0 + qdelay(t) RTT0 + qdealy(t). (6). La dinámica de sistema puede estar continuamente descrita por las ecuaciones de la (4) a la (6), hasta que el largo de la cola alcance el tamaño máximo del buffer en el router, entonces es cuando el tamaño de la ventana toca el punto final (diff).. cwnd diff = (RTT0 + max qdelay ) × bw. (7). Entonces los trasmisores de TCP (7) decrecen multiplicativamente sus ventanas de congestión, después de detectadas las pérdidas de paquetes debido al desbordamiento del buffer del router. La ecuación (6) demuestra que el incremento la ventana cwnd por encima del umbral (knee) no enriquece el rendimiento del sistema, solo se obtiene un incremento del retardo.

(25) CAPÍTULO 2. MATERIALES Y METODOS. 15. en cola. Sin embargo, nuestro análisis además indica que algunas construcciones de colas son inevitables, para proveer un alcance operativo del algoritmo AIMD orientado a la equidad donde el rendimiento del sistema aproveche completamente el ancho de banda. Más precisamente, aunque el decrecimiento multiplicativo es necesario para lograr dinámicamente equidad [12, 15], este no necesariamente significa que el rendimiento del sistema será sacrificado, siempre y cuando el sistema opere entre el umbral (knee) y el tope (diff). Para impedir que el sistema opere por debajo del umbral (knee) donde el ancho de banda es subutilizado, y entre tanto mantenga una oscilación del algoritmo AIMD adecuada, una eficiente razón de decrecimiento de la ventana puede ser:. β =. cwnd knee 1 = cwnd diff 1+ k. where k = =. max qdelay max qdelay × bw = RTT 0 RTT 0 × bw BufferSize RTT 0 × bw. (8). Cuando el tamaño del buffer es igual al producto del retardo del ancho de banda, k=1 y β=0.5. La ecuación (8) corrobora que una eficiente razón de decrecimiento de la ventana depende de la configuración de la red. Esto demanda un esquema basado en la medición del control de la congestión que pueda adaptar los parámetros de control a las condiciones de la red. Estamos particularmente interesados en el impacto de la aleatoriedad del decrecimiento multiplicativo en la suavidad observada por un usuario final. Los autores en el articulo [17] muestran que la suavidad está directamente relacionada con la equidad a corto plazo. El rendimiento de i flujos en un tiempo t es:.

(26) CAPÍTULO 2. MATERIALES Y METODOS. throughput i (t ) =. cwnd i (t ) cwnd i (t ) = RTT (t ) RTT 0 + qdelay (t ). 16. (9). Dado que el parámetro qdelay es común para todos los flujos podemos decir que el rendimiento de cada flujo depende de su ventana de transmisión. Mecanismo para evitar la congestión: El remitente mide RTT mínimo y el máximo RTT percibido. El retardo en la cola puede ser deducido del RTT mínimo (que sea propio del retraso de propagación del lazo) y del RTT actual. El inicio lento del mecanismo de TCP no es modificado, para permitir que el largo de la cola crezca completamente para el desbordamiento durante la inicialización, de manera que el máximo RTT con el valor más alto del retardo en cola pueda ser observado antes de entrar en el estado de evitar congestión. En el estado de evitar congestión, la velocidad del incremento aditivo (α=1) del TCP estándar es intocable, y el remitente disminuye en la mitad la ventana de congestión cuando se pierde un paquete (β=0,5). Sin embargo, el control de congestión estándar es complementado con el siguiente mecanismo de evitar congestión. En la detección de la siguiente condición:. qdelay (t ) RTT (t ) − min RTT ≥ Th upper = max qdelay max RTT − min RTT. (10). donde Thupper es puesto experimentalmente en 0.5, la ventana de congestión es disminuida después de transcurrido un RTT, con una razón de decrecimiento de la ventana γ :.

(27) CAPÍTULO 2. MATERIALES Y METODOS. 17. cwndknee bw × min RTT = cwnd(t ) bw × RTT(t ) min RTT = Thupper × max RTT + (1 − Thupper ) min RTT. γ=. (11). Donde k es definido en la ecuación (8). Note que el decrecimiento multiplicativo basado γ esta corrida un RTT después de que la condición de la ecuación (10) es detectada, para asegurar que ningún remitente ajuste hacia abajo antes de que la condición sea observada por todos los otros remitentes. La ecuación (11) soporta algunas similitudes con (8). Ambas asumen un modelo sincronizado e intentan prevenir que el sistema no trabaje por debajo del umbral (knee). Sin embargo, la ecuación (8) presume que la extracción del último paquete del buffer sincrónicamente retroalimenta la indicación de congestión para todos los flujos, hecho este que no es cierto. Por lo contrario el ajuste hacia abajo basado en la ecuación (11) está controlado por un umbral en el retardo de cola, lo cual puede ser detectado sincronizadamente por todos los remitentes. Desde la perspectiva del control de congestión, γ determina la razón de decrecimiento de la ventana cuando ésta excede el umbral que indica que ocurrirá una congestión. El decrecimiento multiplicativo basado en. γ es aplicado cuando el sistema se encuentra operando en el medio entre el umbral (knee) y el tope (diff), γ es más grande que β. Otro parámetro optativo de control se introduce, para enriquecer. la velocidad de. incremento aditivo cuando la red es subutilizada. Cuando la siguiente condición persiste:. qdelay(t ) RTT (t ) − min RTT ≤ Thlower = max qdelay max RTT − min RTT La cola está próxima a vaciarse. (12). y muy probablemente el ancho de banda será. subutilizado. El incremento aditivo adopta una velocidad rápida: δ = 2. El umbral Thlower es experimentalmente puesto en 0.1. Una vez que el umbral es excedido, δ control sobre α.. manipula el.

(28) CAPÍTULO 2. MATERIALES Y METODOS. 18. Mecanismo de retransmisión, abolición de congestión y slow start modificado. Según TCP Vegas este mecanismo de retransmisión es una versión extendida del de Reno. Mantiene pista de cuando fue enviado cada segmento y calcula un RTT estimado al mantener la pista de cuanto le toma recibir el ACK correspondiente en volver. Cada vez que un ACK es recibido lo compara con el RTT estimado. De ser mayor reenvía el paquete inmediatamente, sin esperar a 3 ACK duplicados. Así supera el problema de Reno, el cual no es capaz de detectar pérdidas de paquetes cuando cwnd es pequeña y no recibía suficientes ACK duplicados. Para atrapar cualquier segmento que se haya perdido previo a la retransmisión, cuando un ACK no duplicado es recibido, si es el primero o el segundo después de un ACK nuevo revisa el valor de timeout y si es mayor al estimado retransmite sin esperar a un ACK duplicado. Así Vegas detecta múltiples pérdidas de paquetes. Además solo reduce la ventana si el segmento retransmitido fue enviado tras el último decremento. Así soluciona el problema de reno ante múltiples pérdidas de paquetes. La abolición de congestión no usa la pérdida de segmentos para señalar la congestión, sino que la disminución de la tasa de envío tras compararla con lo esperado, lo cual suele ser resultado de encolamiento en los routers. Si el aumento de la tasa de envío está muy por sobre lo esperado, incrementa transmisiones para aprovechar ancho de banda disponible. A medida que se acerca reduce su transmisión para evitar saturar el ancho de banda. Así Vegas evita sobrecargar ancho de banda y luego reducir drásticamente. El slow start funciona de manera diferente a los otros algoritmos en esta etapa. Esto obedece a que inicialmente se desconoce del ancho de banda disponible. Y es posible que durante la fase exponencial sobrecargue la red, induciendo congestión. Esto se soluciona realizando el incremento exponencial únicamente al final de un RTT, entretanto calcula el thoughput real de envío y cuando supera cierto nivel de threshold, sale de slow start y entra a abolición de congestión. 2.3. Conclusiones del capítulo. En este capítulo después de una explicación paso a paso de los mecanismos de control de la congestión se puede concluir que con la mejora en estos brinda grandes facilidades y beneficios para la contención de la misma, destacando las posibilidades de que hoy en la.

(29) CAPÍTULO 2. MATERIALES Y METODOS. 19. actualidad la perdida de paquetes y la congestión sea muy poca probabilidad de realizarse en las redes actuales..

(30) CAPÍTULO 3. RESULTADOS Y DISCUSIÓN. 20. CAPÍTULO 3. Modelación y simulación de diferentes escenarios. Presentación y análisis de los resultados. 3.1. Introducción. En el presente capítulo se muestra el escenario para la simulación. También se observan los resultados obtenidos en gráficos. Además se hace una comparación con los resultados obtenidos entre los diferentes TCP y sus mecanismos de control de la congestión en cuanto al comportamiento de la ventana de congestión, la demora y el rendimiento. 3.2. Configuración de la simulación. La simulación implica los siguientes pasos: Preparar un modelo o proyecto con un escenario, definir los parámetros y ejecutar la corrida. En es este cado se considera una red IP (nube IP) a la cual están conectadas una estación y un servidor con el servicio de FTP que contiene un tamaño del fichero de transferencia de 10000000 bytes, con un cantidad de tiempo entre los ficheros de transferencia de 3600 segundos y con un tipo de servicio de mejor esfuerzo (Best Effort).. Fig 3.1.1 Esquema de topología de red IP propuesta..

(31) CAPÍTULO 3. RESULTADOS Y DISCUSIÓN. 3.3. 21. Análisis y obtención de los resultados. Se tendrá en cuenta para la simulación y obtención de las gráficas los parámetros ventana de la congestion, el retardo, la razón de transferencia y el tiempo de bajado de ficheros por el servicio de FTP, luego se comparan estos resultados con los distintos TCP y sus mecanismos de control de la congestión y se llegará a una conclusión de cual de ellos es el mejor. También se demostrará el formato del encabezado IP V.4 y del TCP con la herramienta Opnet debugger (Anexo I y Anexo II).. 3.3.1 Comportamiento de la ventana de control de la congestión En la Fig 3.1.2 muestra el comportamiento del algoritmo de control de congestión de TCP Tahoe, presenta un esquema de control de congestión usando Fast Recovery. Tahoe comienza con ventana de 1xMSS y crece exponencialmente a 65535, en 72522 ocurre una caída de paquetes y empieza la fase de slow start reduciendo la ventana de congestión a la 1xMSS e incrementando nuevamente el tamaño de la ventana exponencialmente. La gráfica de múltiples pérdidas de paquetes es similar al de una sola pérdida por lo que una vez que Tahoe encuentra triple dack comienza con la fase de slow start, la ventana de congestión no crece a menos que llegue un nuevo ack.. 1. 2. 3. Fig 3.1.2 Gráfica de la ventana de congestión en TCP Tahoe con una pérdida de paquete..

(32) CAPÍTULO 3. RESULTADOS Y DISCUSIÓN. 22. TCP Reno usa los algoritmos de control de congestión fast recovery, fast retransmit, en la Fig 3.1.3 se observa que después de que se pierde el paquete (punto 1) en aproximadamente 1.47 seg. Reno entra en la fase fast recovery en lugar de slow start, por lo tanto el tamaño de la ventana se reduce a la mitad en lugar de 1 (punto 2), probando así que TCP Reno toma una acción menos agresiva y evita que se vacié el canal de comunicación y por lo tanto mejora la razón de transferencia.. 1. 2. Fig 3.1.3 Gráfica de la ventana de congestión en TCP Reno. Pérdida de una ráfaga conteniendo un solo segmento de un mismo flujo con TCP Reno. En la Fig 3.1.4 se muestra la ineficiencia que tiene Reno en el caso de pérdidas de ráfagas conteniendo dos o más segmentos de un mismo flujo TCP. Cuando se pierde una ráfaga que lleva dos o más segmentos de un mismo flujo, pueden darse dos escenarios posibles para la detección de la pérdida. Si la ventana de transmisión tiene un tamaño mayor o igual que el número de segmentos perdidos más tres, entonces el emisor acabará recibiendo tres asentimientos duplicados, detectando así la pérdida. Si la ventana de transmisión no alcanza dicho valor, entonces vencerá el temporizador de retransmisión..

(33) CAPÍTULO 3. RESULTADOS Y DISCUSIÓN. 23. En el caso de TCP Reno, tras producirse la pérdida (punto1), el emisor va a retransmitir el segmento, y va a reducir la ventana de congestión a la mitad más tres segmentos (punto 2). A medida que van llegando nuevos asentimientos duplicados, la ventana de congestión se va incrementando en un segmento (punto 3). Sin embargo, no puede enviar nuevos segmentos, ya que la ventana de transmisión es superior a la ventana de congestión, ya que tiene almacenados todos los segmentos que se han enviado después de la pérdida. A continuación, llega el asentimiento del primer segmento perdido, que ha sido generado tras la recepción del segmento retransmitido, y la ventana de congestión se reduce (punto 4). La ventana de transmisión en este punto, con el número de segmentos que hay en tránsito, no permite el envío de ningún segmento, por lo tanto el emisor permanece inactivo hasta que vence el temporizador de retransmisor asociado al segundo segmento perdido (punto 5), momento en el que se retransmite el segmento y se vuelve a show start.. 1 3. 4 2 5. Fig 3.1.4 Gráfica de la ventana de congestión en TCP Reno con dos pérdidas de paquetes conteniendo dos segmentos de un mismo flujo con TCP Reno. Evolución del tamaño de la ventana de congestión. En el caso de Sack (Fig 3.1.5), tras la pérdida de paquete (punto 1), cuando llegan los tres asentimientos duplicados (punto 2), se reduce la ventana a la mitad del número de segmentos en tránsito y se retransmite. A continuación van llegando más asentimientos duplicados (punto 3). Un RTT más tarde del envío del segmento retransmitido, llega el.

(34) CAPÍTULO 3. RESULTADOS Y DISCUSIÓN. 24. asentimiento que confirma su recepción, con lo que se continúa creciendo con congestion avoidance (punto 4).. TCP Sack usa ACKs selectivos y retransmisiones selectivas lo cual mejora el desempeño ya que los timeouts ocurren después que en las otras versiones de TCP.. 1. 2. 3. 4. Fig 3.1.5 Gráfica de la ventana de congestión en TCP Sack. Pérdida de ráfagas conteniendo un solo segmento de un mismo flujo con TCP Sack. En el caso de Sack (Fig 3.1.6), tras la pérdida de la ráfaga que lleva dos segmentos del flujo considerado (punto 1), cuando ocurre la detección de los tres asentimientos duplicados, se reduce la ventana a la mitad del número de segmentos en tránsito (punto 2). A medida que llegan los asentimientos duplicados con información de asentimientos selectivos, la variable pipe se va actualizando pero la ventana de congestión permanece constante (punto 3). Con la información de los asentimientos selectivos, retransmiten los segmentos perdidos. Cuando llega el asentimiento que confirma la recepción de todos los seguidos, se continúa con la fase de congestion avoidance (punto 4)..

(35) CAPÍTULO 3. RESULTADOS Y DISCUSIÓN. 25. De esta figura se observa que el comportamiento de Sack es el mismo que con una pérdida, esto se debe a que Sack puede tolerar y retransmitir selectivamente hasta 3 o 4 bloques de paquetes que se han perdido, por lo tanto para esta ejecución de la simulación Sack ajustó hasta 3 bloques de datos para el caso de múltiples perdidas, resultando un comportamiento similar al de la pérdida de un paquete.. 1. 2. 3. 4. Fig 3.1.6 Gráfica de la ventana de congestión en TCP Sack. Pérdida de dos ráfaga conteniendo dos segmentos de un mismo flujo con TCP Sack.. 3.3.2 Comportamiento del retardo, la razón de transferencia y la respuesta de bajada de ficheros por el servicio de FTP con una pérdida de ráfaga conteniendo dos segmentos de un mismo flujo. A continuación se comparan los diferentes TCP en cuanto a la respuesta de bajada por el servicio de FTP, se observa en al Fig 3.1.7 que en el caso del TCP Sack presenta el menor tiempo de respuesta de bajada por el servicio de FTP que TCP Tahoe y Reno..

(36) CAPÍTULO 3. RESULTADOS Y DISCUSIÓN. 26. Fig 3.1.7 Tiempo de respuesta de bajada por el servicio de FTP. En La Fig 3.1.8 se demuestra que para esta simulación el TCP Sack presenta menor retardo que el TCP Tahoe Y Reno gracias a las mejoras de sus mecanismos de control de congestión.. Fig 3.1.8 Gráfica del retardo de origen a destino de los paquetes (Delay)..

(37) CAPÍTULO 3. RESULTADOS Y DISCUSIÓN. 27. En la Fig 3.9 TCP Sack se define como el de mejor razón de transferencia que los otros TCP.. Fig 3.1.9 Gráfica de la razón de transferencia (Throughput). 3.3.3 Comportamiento del retardo, la razón de transferencia y la respuesta de bajada de ficheros por el servicio de FTP con dos pérdidas de ráfagas conteniendo dos segmentos de un mismo flujo.. Para este caso la respuesta de bajada de ficheros por el servicio de FTP, TCP Sack presenta una mejor respuesta que Reno y Tahoe demostrando que es mucho mejor antes múltiples pérdidas. A la hora de que el cliente y el servidor estén listos para el envío de los ficheros de FTP es importante el menor tiempo de bajada ya que este indica el tiempo en que se puede bajar este fichero..

(38) CAPÍTULO 3. RESULTADOS Y DISCUSIÓN. Fig 3.2.1 Tiempo de respuesta de bajada por el servicio de FTP. El retardo de paquetes cuando hay múltiples pérdidas de paquetes es mucho menor en TCP Sack que los otros dos TCP ya que presenta mecanismo para este tipo de pérdidas cuando TCP Tahoe y Reno no lo presentan.. Fig 3.2.2 Gráfica del retardo de origen a destino de los paquetes (Delay).. 28.

(39) CAPÍTULO 3. RESULTADOS Y DISCUSIÓN. 29. La razón de transferencia es mucho mejor en TCP Sack que en TCP Reno y Tahoe ya que este presenta un menor retardo por lo que la cantidad de datos que llegan exitosamente es mejor.. Fig 3.2.3 Gráfica de la razón de transferencia (Throughput). A continuación en la Tabla 3.1 se muestra algunos sistemas operativos con diferentes propiedades de los mecanismos de control de la congestión..

(40) CAPÍTULO 3. RESULTADOS Y DISCUSIÓN. 30. Windows 2000. Windows XP. Tamaño Máximo del Segmento. Auto. Auto. Conteo Inicial del Slow Start (MSS). 2. 1. Retransmisión Rápida. Habilitado. Habilitado (6). Recuperación Rápida. Reno. Reno. Selectivo ACK(Sack). Habilitado. Habilitado. Algoritmo Nagle. Habilitado. Habilitado. Algoritmo Karns. Habilitado. Habilitado. Tabla 3.1 Sistemas operativos y mecanismo de control de la congestión. 3.4. Conclusiones del capítulo. Como resultado final el desempeño de nuestra red con el TCP Sack es mejor que con los otros TCP ya que presenta un mejor comportamiento en cuanto al retardo de los paquetes y la razón de transferencia..

(41) CONCLUSIONES Y RECOMENDACIONES. 31. CONCLUSIONES Y RECOMENDACIONES. Conclusiones A lo largo del presente trabajo de diploma se arribó a las conclusiones siguientes: ¾ A partir del caso de estudio de los diferentes tipos de TCP, comparándolos se puede decir que el TCP Tahoe ya no es usado por sus grandes desventajas comparado con los demás TCP ya que este compromete más a la red a una mayor congestion de paquetes. ¾ Del estudio de los diferentes TCP con ayuda del OPNET Modeler, se observó la gran importancia como herramienta de simulación que es, con lo cual se mostró que se debe utilizar antes de cualquier estudio que tenga que ver con el estudio de las telemáticas. ¾ De los resultados obtenidos se observó que el retardo, la razón de transferencia y el tiempo de bajado por el servicio de FTP es mejor en TCP Sack dando un mejor un mejor rendimiento que los demás tipos de TCP simulados. ¾ Con el análisis de los resultados obtenidos se observó que con el uso de la herramienta de simulación OPNET Modeler se evidencia que con el TCP Sack evitamos a un más la congestión en la redes TCP/IP..

(42) CONCLUSIONES Y RECOMENDACIONES. 32. Recomendaciones Una vez concluido el trabajo se proponen las siguientes recomendaciones: ¾ Continuar el estudio de los diferentes TCP y sus mecanismo de control de la congestión. ¾ Profundizar el estudio de la herramienta de simulación OPNET Modeler en especial con el OPNET Debugger que estudia la información imprimida en los segmentos de TCP. ¾ Utilizar la herramienta de Network Simulator (NS) para un mejor comprendimiento de los nevos mecanismo de control de la congestion conjunto a sus TCP..

(43) REFERENCIAS BIBLIOGRÁFICAS. 33. REFERENCIAS BIBLIOGRÁFICAS. [1] V. Jacobson. “Congestion Avoidance and Control”. SIGCOMM Symposium no Communication Architecture and Protocols. [2] V.Jacobson “Modified TCP Congestion Control and Avoidance Alogrithms”.Technical Report 30, Apr 1990. [3] S.Floyd, T.Henderson “The New-Reno Modification to TCP’s Fast Recovery Algorithm” RFC 2582, Apr 1999. [4] O. Ait-Hellal, E.Altman “Analysis of TCP Reno and TCP Vegas”. [5] K.Fall, S.Floyd “Simulation Based Comparison of Tahoe, Reno and SACK TCP”. ACM Computer Communication Review, 26(3):5–21, July 1996. [6] L.S.Brakmo, L.L. Peterson, “TCP Vegas: End to End Congestion Avoidance on a Global Internet”, IEEE Journal on Selected Areas in Communication, vol. 13[1995], (14651490). [7] L. S. Brakmo and L. L. Peterson, “TCP Vegas: End to end congestion avoidance on a global internet,” IEEE J. Select. Areas Communi, vol. 13, no. 8, pp. 1465–1480, Oct. 1995. [8] D. Tan and A. Zakhor, “Real-time internet video using error resilient scalable compression and TCP-amigable transport protocol,” IEEE Trans. Multimedia, vol. 1, no. 2, pp. 172–186, Jun. 1999. [9] S. Floyd, Congestion Control Principles RFC 2914, Sep. 2000..

(44) REFERENCIAS BIBLIOGRÁFICAS. 34. [10] D. Sisalem and H. Schulzrinne, “The loss-delay adjustment algorithm: a TCPamigable adaptation scheme,” in Proc. ACM NOSSDAV 1998, July 1998, pp. 215–226. [11] D.-M. Chiu and R. Jain, “Analysis of the increase and decrease algorithms for congestion avoidance in computer networks,” Comput. Networks ISDN Syst., vol. 17, no. 1, pp. 1–14, 1989. [12] L. S. Brakmo and L. L. Peterson, “TCP Vegas: End to end congestion avoidance on a global internet,” IEEE J. Select. Areas Communi., vol. 13, no. 8, pp. 1465–1480, Oct. 1995. [13] J. Padhye, V. Firioiu, D. Towsley, and J. Kurose. Modeling TCP Throughput: A Simple Model and its Empirical Validation. In Proc. Of ACM SIGCOMM, pages 303–314, Vancouver, Canada, September 1998. [14] V. Jacobson. Berkeley TCP evolution from 4.3-Tahoe to 4.3 Reno. In Proc. of the 18th Internet Engineering Task Force, Vancouver, Canada, August 1990. [15] G. Appenzeller, I. Keslassy, and N. McKeown, “Sizing router buffers,” in Proc. ACM SIGCOMM 2004, Aug. 2004, pp. 281–292. [16] S. Floyd, T. Henderson, and A. Gurtov. The NewReno Modification to TCP’s Fast Recovery Algorithm. RFC 3782, April 2004. [17] Y. R. Yang, M. S. Kim, and S. S. Lam, “Transient behaviors of TCP amigable congestion control protocols,” in Proc. IEEE INFOCOM 2001, Apr. 2001, pp. 1716– 1725. [18] V. Jacobson. Congestion Avoidance and Control. In Proc. of ACM SIGCOMM, pages 314–329, Stanford, USA, August 1988. [19] V. Tsaoussidis and C. Zhang, “TCP-Real: Receiver-Oriented Congestion Control”, Computer Networks Journal (Elsevier),Vol. 40, No. 4, November 2002..

(45) REFERENCIAS BIBLIOGRÁFICAS. 35. [20] S. Floyd, and V. Jacobson, “Random Early Detection gateways for Congestion Avoidance”, IEEE/ACM Transactions on Networking, August 1993. [21] U. Hengartner, J. Bolliger and Th. Cross, “TCP Vegas Revisited”, In Proceedings of IEEE INFOCOM 2000, March 2000. [22] M. Allman, V. Paxson, and W. Stevens, “TCP Congestion Control”, RFC2581, April 1999. [23] M. Mathis, J. Mahdavi, S. Floyd, and A.Romanow, “TCP Selective Acknowledgement Options”, RFC 2018, IETF, October 1996. [24] H. Jiang and C. Dovrolis. Passive Estimation of TCP Round Trip Times. ACM Computer Communication Review, 32(3):75–88, July 2002. [25] A. Mahanti, D. Eager, and M. Vernon. Improving Multirate Congestion Control Using a TCP Vegas Throughput Model. Computer Networks, 48(2):113–136, June 2005. [26] B. Sikdar, S. Kalyanaraman, and K. Vastola. An Integrated Model for the Latency and Steady-State Throughput of TCP Connections. Performance Evaluation, 46(2-3):139–154, September 2001. [27] X. Yu, C. Qiao, Y. Liu y D. Towsley, “Performance Evaluation of TCP Implementations in OBS Networks”, Technical Report 2003-13, CSE Dept., SUNY, Buffalo, 2003. [28] A. Detti y M. Listanti, “Impact of Segments Aggregation on TCP Reno Flows in Optical Burst Switching Networks”, Proc. of INFOCOM 2002, Vol. 3, pp. 1803-1812. [29] V. Jacobson, R. Braden y D. Borma, “TCP Extensions for High Performance”, RFC 1323, Mayo 1992..

(46) REFERENCIAS BIBLIOGRÁFICAS. 36. [30] A. Medina, M. Allman y S. Floyd, “Measuring the evolution of Transport protocols in the Internet”, ACM SIGCOMM Computer Communication Review, Vol. 35, Abril 2005, pp. 37-52..

(47) ANEXOS. ANEXOS I Encabezado IP V.4. Encabezado IP V.4. 37.

(48) ANEXOS. Encabezado IP V.4 en el Opnet Debugger. 38.

(49) ANEXOS. ANEXOS II Formato del encabezado TCP. Formato del encabezado TCP. 39.

(50) ANEXOS. Formato del encabezado TCP en el Opnet Debugger. 40.

(51) GLOSARIO. GLOSARIO. ACK: Reconocimiento o acuse de recibo CWND: Ventana de congestión Delay: Retardo MSS: Máximo Tamaño de Segmento RTT: Tiempo de ida y vuelta Ssthresh: Umbral del inicio lento TCP: Protocolo de Control de Transporte Throughput: Razón de transferencia. 41.

(52)