Evaluación de rendimiento de algoritmos de Congestión TCP en Riverbed Modeler Academic Edition

Laura Daniela Acosta ContrerasUniversidad Distrital Francisco José de Caldas

Bogotá, ColombiaLauradaniela92@gmail.com

Sergio Alexander Gutiérrez BustosUniversidad Distrital Francisco José de Caldas

Bogotá, ColombiaSergut18@gmail.com

RESUMEN: TCP es el protocolo de transmisión más popular en internet. Han surgido muchos algoritmos de control de congestión para mejorar el rendimiento de este protocolo; gestión de conexión, manejo de pérdida de datos y reducir el número de errores. En este documento se utiliza la herramienta Riverbed Modeler, para simular y demostrar el comportamiento de algunos de estos algoritmos: Slow Start, Congestion Avoidance, Tahoe, Reno, NewReno y Cubic. Se analiza la ventana de congestión y el proceso de recuperación de cada algoritmo sobre un escenario recreado de una red a nivel internacional. A partir de los resultados obtenidos, el algoritmo Cubic tiene mejor resultado, minimizando el tamaño de ventana ya que esta tiene un comportamiento estable en 5,000 , aunque aumenta el tiempo de duración de la transmisión, ya que el promedio de duración con los demás es de 2m 28 s y el de Cubic es de 3m 50 s.

ABSTRACT: TCP is the most popular transmission protocol in the internet. Many congestion control algorithms have emerged to improve the perfomance of this protocol, the connecction management, data loss management and to reduce the number of errors. In this document the Riverbed Modeler toodl is used to simulate and demonstrate the behaviour of some algorithms like: Slow Start, Congestion Avoidance, Tahoe, Reno, NewReno and Cubic, The congestion window and the recovery proccess of each algorithm is analized based

on a scenario of an international netwwork. From the results obtained, the Cubic algorithm has better result, minimizing the size of window, but increases the duration of the transmission time.

PALABRAS CLAVE: congestion, flujo, ftp, http, rendimiento, tcp.

1 INTRODUCCIÓN

El Protocolo de Control de Transmisión TCP es actualmente el más utilizado en Internet, soportando aproximadamente el 90 % del tráfico de Internet tanto en redes cableadas como inalámbricas [1]. Con el avance de la ciencia surgen nuevas tecnologías y dispositivos, y cada vez es mayor el número de conexiones y el tráfico en internet, provocando posibles errores en la transmisión debido a la cantidad de conexiones simultáneas recibiendo y enviado datos. Esto requiere un máximo rendimiento en el protocolo TCP, con mínimos errores en transmisión y control de congestión, por lo tanto es de vital importancia hacer mejoras en este protocolo. En la actualidad hay gran cantidad de algoritmos propuestos e implementados en diferentes escenarios para solventar esta necesidad.

El algoritmo de control de congestión es un módulo integrado de TCP que determina el rendimiento del protocolo. Los algoritmos estándares de control de congestión son TCP Tahoe, TCP Reno y TCP New Reno [2], que son el resultado de las implementaciones y combinaciones de los algoritmos Slow Start, Congestion Avoidance, Fast Retransmit y Fast Recovery.

1. SLOW START

Slow Start proporciona una manera de controlar el flujo de datos inicial al comienzo de una comunicación y durante una recuperación de errores basado en los acuses de recibos. Cada acuse de recibo significa que un segmento, o un grupo de segmentos, han dejado a la red y no está utilizando ningún recurso, por lo que los nuevos datos se pueden enviar.

Funcionamiento de Slow Start:

El receptor envía un número de segmentos igual al MINIMO de lo indicado por la ventana anunciada por el receptor y lo indicado por la ventana de congestión. Gestión de cwnd:

Inicio de la conexión: UN segmento de tamaño máximo igual al anunciado por el receptor. La primera transmisión será pues de 1 segmento:

Valor inicial de cwnd: 1 segmento (en realidad 1xMSS bytes).

Cuando recibe el ack correspondiente, cwnd se incrementa para permitir 2 segmentos (cwnd=2xMSS) (1+1). Si la ventana ofrecida es mayor o igual, el transmisor envía 2 segmentos.

Cada vez que recibe un ack, el transmisor incrementa en uno el número de segmentos transmitidos (incrementa la ventana de congestión).

Slow-start impone un ritmo inicial lento de envío de datos a la red, ritmo que se incrementa muy rápidamente si las redes lo permiten. Un parámetro: Round-Trip -Time, período que va desde el momento en que se envía un segmento y aquel en el que se recibe su ack.

1

2. CONGESTION AVOIDANCE

Es un algoritmo que adapta la transmisión de datos a los recursos disponibles. Después de Slow Start ha alcanzado un cierto umbral, la congestion avoidance comienza a retrasar la apertura de la ventana. La congestión se puede producir cuando los datos llegan en un gran canal y se envía a un canal más pequeño, produciendo el efecto cuello de botella. La congestión también puede ocurrir cuando múltiples flujos de entrada llegan a un router cuya capacidad de producción es menor que la suma de las entradas. Evitar la congestión es una manera de lidiar con la pérdida de paquetes. Hay dos indicaciones de pérdida de paquetes: un tiempo de espera se produce y la recepción de ACKs duplicados.

Congestion Avoidance y Slow Start son algoritmos independientes con diferentes objetivos. Pero cuando se produce la congestión TCP congestion avoidance debe frenar la velocidad de transmisión de paquetes en la red, y luego invocar Slow Start para que funcione de nuevo. En la práctica se implementan juntos.

Congestion Avoidance y Slow Start requieren que se mantengan dos variables para cada conexión: una ventana de congestión, cwnd, y un tamaño de umbral de inicio lento, ssthresh. El algoritmo combinado funciona de la siguiente manera:

1. Inicialización por conjuntos de conexión dadas CWND a un segmento y ssthresh a 65.535 bytes.

2. La rutina de salida TCP nunca envía más que el mínimo de cwnd y la ventana anunciada del receptor.

3. Cuando se produce la congestión (indicada por un tiempo de espera o de la recepción de ACKs duplicados), se establece el tamaño a la mitad de la ventana actual. (el mínimo de cwnd y ventana anunciada del receptor, pero al menos dos segmentos) se guarda en el ssthresh. Además, si la congestión es indicada por un tiempo de espera, cwnd se establece en un segmento (es decir, Slow start).

4. Cuando los datos nuevos se reciben por el otro extremo, se aumenta cwnd, pero la forma en que aumenta depende de si TCP está realizando Slow start o congestion avoidance.

Si cwnd es menor o igual a ssthresh, TCP está en arranque lento – Slow start; de lo contrario TCP está llevando a cabo en congestion avoidance. Slow start continúa hasta que TCP está a medio camino de donde estaba cuando se produjo la congestión (ya que registró la mitad del tamaño de la ventana que causó el problema en el paso 2) y, a continuación, congestion avoidance se hace cargo.

Congestion avoidance comienza en un segmento, y se incrementa en un segmento cada vez que se recibe un ACK. Como se mencionó anteriormente, esto abre la ventana de manera exponencial: enviar un segmento, luego dos, luego cuatro, y así sucesivamente. Evitar la congestión dicta que cwnd se incrementa en SEGSIZE * SEGSIZE / cwnd cada vez que se recibe un ACK, donde SEGSIZE es el tamaño de segmento y cwnd se mantiene en bytes. Este es un crecimiento lineal de cwnd, en comparación con el crecimiento exponencial de comienzo lento. El aumento de cwnd debe ser como máximo de un segmento cada vez de ida y vuelta (sin tener en cuenta el número de ACKs se reciben en ese RTT), mientras que los incrementos comienzo lento CWND por el número de ACKs recibidos en un tiempo de ida y vuelta [3].

3. RENO

El flavour que utiliza tanto de Fast Retransmit y Fast Recovery juntos se llama Reno TCP [5]. Reno funciona bien hasta que sólo un segmento se pierde, pero en un escenario inalámbrico, habrá segmento de múltiples drops en una transferencia y también en los medios de comunicación no fiables. En caso de múltiples segmentos perdidos, hace el tamaño de la ventana utilizable para cada segmento se reduzca a la mitad. Además, la ventana utilizable disminuye durante la fase de Fast recovery, y se envía más información, cada vez que un duplicado reconoce que es recibida. Cuando el temporizador de retransmisión expira la ventana de congestión se cierra a 0 y comienza a crecer con algoritmos de Slow start y congestion avoidance.

4. SACK

TCP adolece de algunos problemas de rendimiento relacionados con ráfagas de errores. Los algoritmos tradicionales dan poca información sobre los segmentos que tienen o no han llegado a su destino. Esta información permite retransmitir sólo un segmento por el tiempo de ida y vuelta. Además, el transmisor puede crear una situación en la que los paquetes que han llegado correctamente a su destino se retransmiten, cuando no había ninguna necesidad de hacerlo. Esto podría suceder si el transmisor utiliza un tiempo de retransmisión corto. Por otra parte, esta situación sería aumentar la congestión en la red.El mecanismo TCP SACK, ayuda a evitar estas limitaciones. El receptor informa al transmisor, que los paquetes se han recibido correctamente, por lo que la retransmisión se produce sólo para paquetes perdidos. Sack informa de los segmentos que han alcanzado el receptor aunque llevan números de secuencia no consecutivos. Esto significa que, si hay un segmento que falta entre otros dos segmentos, el receptor puede reconocer tanto

2

cuál de ellos es. Y esto se haría sin reconocer el segmento que falta entre ellos [2].

2 TRABAJOS PREVIOS

Laxmi Subedi, Mohamadreza Najiminaini, y Ljiljana Trajković en su trabajo titulado “Performance Evaluation of TCP Tahoe, Reno, Reno with SACK, and Performance Evaluation of TCP Tahoe, Reno, Reno with SACK, and NewReno Using OPNET Modeler” [1], evalúan el rendimiento de TCP Tahoe, Reno, Reno con SCAK y New Reno usando Opnet moder. La evaluación de los algoritmos se hace sobre un escenario inalámbrico. La simulación consiste en un cliente móvil usando el protocolo de transferencia FTP conectado a un router con un cable de 10Mbps, y un router inalámbrico conectado a un router a 1.5 Mbps. Los archivos de transferencia usados sobre FTP tienen un tamaño de 50MB. Se Analiza la congestión y el proceso de recuperación de cada algoritmo TCP mediante la observación de la congestión tamaño de la ventana, el tiempo de respuesta de descarga de archivos, rendimiento, y goodput.Los resultados de la simulación indicaron que las redes inalámbricas con atenuación de señal, fading y multipah, TCP Reno supera a otros algoritmos de control de congestión en términos de tamaño de ventana y en tiempo de respuesta en la descarga de archivos. TCP Reno con SCAK muestra un mayor rendimiento y goodput en comparación a los otros tres algoritmos.

Guiomar Corral, Agustin Zaballos, Tomas Fulgueira, Jaume Abella en su trabajot titulado “Simulation-based study of TCP flow control mechanisms using OPNET Modeler” [2], resumen el estudio de TCP y los mecanismos de control de transmisión de datos. Estudian los algoritmos Slow Start, congestion avoidance, Fast Retransmit y Fast Recovery, que puede ser implementado de manera diferente dando nombre a TCP Tahoe, Reno, y NewReno. El objetivo principal se centra en el conocimiento de TCP y los mecanismos de control de flujo. El estudio se realiza mediante simulaciones en Opnet Modeler. Después de analizar los resultados llegan a la conclusión de que Tahoe TCP proporciona un mejor rendimiento que Reno TCP en respuesta al primer error encontrado, sin embargo NewReno TCP supera los dos algoritmos cuando se produce más de un error. Usuario.

Yuan-Cheng Lai, Chang-Li Yao en su trabajo titulado “TCP congestion control algorithms and performance comparison” [6]. Realizan una comparación de los algoritmos de sus ventajas y desventajas, utilizando el simulador de red como herramienta, el enlace se etiqueta con su ancho de banda y tiene un retardo de propagación, con un tamaño de paquete fija que es de 512. Llegando a la conclusión de que NewReno promueve el rendimiento, pero gasta mucho tiempo recuperando los paquetes perdidos, SACK por su parte incrementa el rendimiento y equidad sin embargo requiere de un control, SSDR también eleva el rendimiento pero tiene un problema de equidad.

Ahmed Khurshid , Md. Humayun Kabir, and Md. Anindya, en su trabajo titulado “An Improved TCP Congestion Control Algorithm forWireless Networks.”[7]. Ellos proponen un nuevo algoritmo de control de congestión que se pueda incorporar con cualquier varieante TCO existente y es capaz de interactuar de manera eficiente con redes heterogéneas. Realizan la simulación con una única conexión TCP con 2 UDP activada por diferentes variantes de TCP TCP K-Reno. Tambien realizan la comparación del rendimiento de

una sola conexión TCP sin tráfico UDP, como resultado K-Reno se comporta mejor.Finalmente ellos realizan la propuesta del nuevo algoritmo, verificando los resultados con las simulaciones hechas, con una característica que es de extremo a extremo y modifica sólo el lado del remitente de una implementación TCP. Mantiene el receptor TCP y la red desconoce las modificaciones. Está característica hace que sea adecuado para el despliegue en el escenario de la vida real. Como trabajos futuros van a incorporar el patrón RTT en la congestión de control.

Networks.Jingyuan Wang, Jiangtao Wen, Jun Zhang and Yuxing Han, en su trabajo titulado “TCP-FIT - A Novel TCP Congestion Control Algorithm for Wireless” [8] proponen un nuevo algoritmo de control de congestión TCP llamado TCP-FIT, para redes que presentan perdidas como las inalámbricas. Los reultados obtenido en el paper muestran mejora de rendimiento significativo, En la simulación la SINR de LTE UE vario de -1 dB a 15 dB, junto con otros parámetros modificados, Tambien hicieron uso de la capa de aplicación de técnicas en paralelo que es E-MULTCP, en la que incluían mayor rendimiento , bajaba la latencia y mantenían la equidad.El algoritmo no requiere modificaciones por parte de los clientes y de las aplicaciones de software

3 SIMULACIÓN

El modelo propuesto para el análisis y simulación de los algoritmos de congestión TCP, se realiza sobre Riverbed Modeler 17.5 en un mapa internacional. Se crea una red LAN 802.3u en la ciudad de Bogotá que consiste en dos servidores Ethernet (HTTP - FTP) y un router conectados con cable 100BaseT - Fast Ethernet de 100 Mbit/s, y una red LAN 802.3u ubicada sobre la ciudad de Brasilia, compuesta por una estación de trabajo y un router conectados a través de cable 100BasteT.

La Imágen 1., muestra el modelo recreado. La conexión de las dos redes (Bogota - Brasilia) con la WAN – Internet se estableció a través de cable Duplex Link PPP DS3. La simulación se realiza durante 600 segundos, en los distintos escenarios de cada algoritmo, Se configura una pérdida de datos en 0.5% con el fin de visualizar el rendimiento de recuperación de los algoritmos.

Imágen 1Modelo de Red Diseñado de Riverbed Modeler

3

Se crean dos aplicaciones de servicios (HTTP y FTP) configurados en los servidores de la red Bogota, y consumidos por la estación de trabajo ubicada en la red Brasilia. Los parámetros de configuración de cada servicio se presentan en la Tabla 1.

Command Mix (Get/Total): especifica la proporción entre el número de operación y el número total de operaciones de FTP.Inter_request Time: especifica la cantidad de tiempo entre operaciones consecutivas de FTP. La hora de inicio de la próxima transferencia de archivos se calcula añadiendo el valor de este atributo a la vez de cuando comenzó la operación anterior de FTP. Las operaciones FTP son independientes lo que significa que una nueva transferencia de archivos puede comenzar antes de las anteriores operaciones FTP se han completado.File Size (bytes): Especifica el tamaño en bytes de los archivos que van a ser transmitidos.

HTTP Specification: Define la versión del protocolo HTTP:Page Interarrival Time (seconds): especifica el tiempo de entre la solicitud de página web consecutivos. Este atributo define efectivamente el comportamiento del usuario de navegación web.Objetive Size (bytes): especifica el tamaño de un objeto simple dentro de una página web.Number of Objects: especifica el número de objetos de un determinado tipo dentro de la página web [5].

FTP Application

Command Mix (Get/Total) 100%

Inter_request Time Constant (100)

File Size (bytes) Constant (9000000)HTTP Application

HTTP Specification HTTP 1.1Page Interarival Time Constant (3600)Objetive Size (bytes) Constant (9000000)Number of Objects Single Object

Tabla 1Parámetros de configuración para las aplicaciones

Los parámetros que se usan para TCP en todas las versiones para los servicios se indican en la Tabla 2. Como Slow Start initial count, Receive Buffer, Duplicate ACK Threshold, Initial, Minimum y Maximum RTO entre otros.

Receive Buffer (bytes): especifica la cantidad total de espacio disponible en el receptor para almacenar los datos que llegan antes de su transmisión a las capas superiores.Maximum ACK Delay (sec): especifica la duración máxima de tiempo en segundos que esperará un proceso TCP antes de enviar un "dataless" ACK.Maximum ACK Segments: especifica el número máximo de segmentos TCP debe recibir antes de enviar un "dataless" ACK.Duplicate ACK Threshold: especifica el número de ACKs duplicados que provoca el inicio de la fase de Fast Retransmit.Slow-Start Initial Count (MSS): especifica el valor inicial cwnd al comienzo de la fase Slow Start.Initial RTO (sec), Minimum RTO (sec) y Maximum RTO (sec): específica valores iniciales, mínimos y máximos para el

RTO durante la duración de una conexión de acuerdo con el algoritmo de Kanrn’s [5].

Parameters TCP

Receive Buffer (bytes) 65535

Maximum ACK Delay (sec) 0.200

Maximum ACK Segments 2

Duplicate ACK Threshold 3

Slow-Start Initial Count (MSS) 1

Initial RTO (sec) 1.0

Minimum RTO (sec) 0.5

Maximum RTO (sec) 64

Deviation Gain 0.25

RTT Deviation Coefficient 4.0

Tabla 2Parámetros TCP Generales

3.1 ESCENARIO TCP SLOW START Y CONGESTION.

En este primer escenario se presenta la configuración del Slow Start y Congestion Avoidance para los dos servicios, en este punto el protocolo TCP no tiene implementado ningún algoritmo de Fast Retransmit y ni de Fast Recovery.

En la Grafica 1. La línea azul representa la congestion de ventana en el servicio FTP que tiene igual umbral de congestion comparado con el servicio HTTP representado en rojo. Se puede visualizar el comportamiento de los algoritmos Slow Start y Congestion Avoidance, que se consideran como los requisitos estándar del protocolo TCP, modifican el rendimiento de la ventana deslizante para resolver algunos problemas relacionados con la congestion en la redes, estos algoritmos siempre trabajan juntos como si de uno solo se tratara. Slow Start siempre se ejecuta al comienzo de la comunicación y durante la recuperación de errores de los ACKs controlando el flujo de datos inicial. Congestion Avoidance adapta la transmisión de datos a los recursos disponibles justo después que Slow Start termina el ciclo en menos de un segundo, provocando retrasar la apertura de la ventana. En la gráfica llega hasta 130 bytes a los 2m 23s para el servicio FTP, después de un intervalo de aproximadamente 30s que el tiempo de vida del algoritmo Congestion Avoidance. Para el servicio HTTP (línea roja), tiene un comportamiento idéntico.

Estos dos algoritmos significan una mejora en el rendimiento de TCP pero no es suficiente, el control de flujo necesita ser mejorado, porque cuando se encuentran con algún error y recuperación en la trasmisión, el flujo de datos es detenido totalmente provocando lentitud en la trasmisión.

4

Gráfica 1Rendimiento TCP Slow Start - Congestion Avoidance

Gráfica 2Rendimiento TCP Slow Start y Congestion Avoidance con pérdida de datos en 0.05%

3.2 ESCENARIO TCP TAHOE - FAST RETRANSMIT.

Fast Retrasmit mejora el protocolo TCP reduciendo el tiempo de espera de un emisor antes de retransmitir un segmento perdido. La Gráfica 3. Muestra la mejora de tiempo que se obtiene al implementar Fast Retrasmit, en relación a la Gráfica 2., en el escenario dos con 0.5% de perdida de datos. El servicio FTP tiene una mejora de tiempo de50 segundos, además de una mejora en la congestión con un promedio de uso de 35 bytes en la ventana de congestion comparado con el anterior que tiene un promedio de 41 bytes. El servicio HTTP tiene una mejora de tiempo de transmisión de 35 segundos, aunque el tamaño de ventana de congestion aumento con un promedio de uso máximo de 42 bytes, en comparación al anterior con un promedio máximo de 39 bytes.

Gráfica 3 Rendimiento TCP Tahoe.

3.3 ESCENARIO RENO – FAST RECOVERY.

Con el uso del algoritmo Reno que es la implementado de Fast junto a Retrasmit Fast Recovery para el control de flujo evitando detener el flujo por completo cuando se presentan perdidas de datos y volver a retransmitir, se logra una leve mejora en la congestion para el protocolo TCP y también una mejora en los tiempos de la transmisión para algunos servicios. En la Gráfica 4. Se observa una mejora en la ventana de congestion para el servicio FTP en un promedio aproximado de 36 bytes, pero sacrifica el tiempo aumentándolo en 4 segundos. Para el servicio HTTP se obtiene una mejora en la ventana de congestion de 38 bytes y un aumento en el tiempo de transmisión de 3.5 segundos.

Gráfica 4. Rendimiento TCP Reno.

5

3.4 ESCENARIO NEWRENO CON SACK

En este escenario se presenta la configuración de TCP NewReno junto con Sack, donde hay una leve mejora de congestion en la transmisión, ampliando la ventana de congestion utilizable restante, como se aprecia en la Gráfica 5., la congestion del servicio HTTP disminuyo en 0.90%, pero se aumentó levemente el tiempo de transmisión cerca de 3 segundos. El servicio FTP obtuvo un mejor resultado el tamaño de congestion de ventana disminuyó casi 1.01 % y además disminuyo el tiempo de transmisión aproximadamente en 3 segundos.

Gráfica 5. Rendimiento TCP NewReno con Sack

3.5 ESCENARIO CUBIC CON SACK

Con el algoritmo CUBIC se obtiene un mayor rendimiento en el tamaño de ventana de congestion muy significativo a pesar de que el tiempo de transmisión aumenta considerablemente. En la Gráfica 6., se puede observar que después los 3 primeros segundos de transmisión la el tamaño de ventana disminuye en más de un 90%, pero el tiempo aumenta proporcionalmente.

Gráfica 6. Rendimiento TCP CUBIC.

Gráfica 7 Comparación de los algoritmos de congestion TCP en el servicio FTP.

En la Gráfica 7. Se muestra el rendimiento de la ventana de congestion sobre el servicio FTP en los diferentes algoritmos de congestion implementados. La línea amarilla representa el protocolo TCP estándar, se observa que el tiempo de transmisión es bastante largo con un tamaño de ventana de congestion promedio entre los demás algoritmos, la línea azul, representa el algoritmo CUBIC, es el que tiene mayor rendimiento aunque el tiempo de duración de la transmisión sea el más prolongado. La Gráfica 8. , que representa el rendimiento de

6

ventana de congestion sobre el servicio HTTP, muestra resultados similares.

Gráfica 8 Comparación de los algoritmos de congestion TCP en el servicio HTTP.

4 RESULTADOS

Para obtener los resultados a partir de análisis de las gráficas y los datos obtenidos desde Opnet Modeler, se procede a tomar todos los puntos que arrojan las gráficas según el algoritmo utilizado, tanto del tamaño de ventana (bytes) como en tiempo de duración de la transmisión. Para el tamaño de ventana se sacan dos datos; MTV que representa el Máximo umbral alcanzado, y PTV, que representa el promedio del tamaño de ventana utilizado durante la transmisión. Para el tiempo, se saca el intervalo de tiempo que dura la transmisión TT. En la Tabla 3 y 4 se visualizan los datos

analizados según el tipo de servicio FTP y HTTP.

SERVICIO FTP

ALGORITMOMTV

(BYTES)PTV

TT (SEC

)

Estándar 130,57 100,76 18,5

Slow Start - Congestion Avoidance

67,83 18,93 79

TCP Tahoe 68,92 20,60 28

TCP Reno 68,29 19,53 32

TCP New Reno con Sack 69,96 19,16 27,5

TCP Cubic 65,7 8,42 130

Tabla 3. Resultados del análisis de congestion en el servicio FTP.

SERVICIO HTTTP

ALGORITMO MTV PTV TT

(bytes) (sec)

Estándar 130,57 100,79 17,5

Slow Start - Congestion Avoidance

66,52 23,38 54

TCP Tahoe 65,52 22,19 21

TCP Reno 66,27 19,28 25,6

TCP New Reno con Sack

66,52 20,32 25,8

TCP Cubic 65,7 11,79115,

9Tabla 4. Resultados del análisis de congestion en el servicio HTTP.

5 DISCUSIÓN DE RESULTADOS

MTV (bytes)

PTVTT

(sec)

SERVICIO HTTTP

SERVICIO FTP

Tabla 5. Comparación de resultados de Servicio HTTTP yFTP

6 CONCLUSIONES

En el servicio FTP, el algoritmo que logra un mayor rendimiento en la ventana de congestión es TCP CUBIC, con un promedio de utilización en la ventana de congestion de 8.42% frente al algoritmo estándar de TCP, donde no se presenta perdida de datos. En el tiempo de transmisión CUBIC es el más prolongado con 130 segundos frente al resto de algoritmos que no superan los 35 segundos, excepto el algoritmo estándar Slow Start junto con Congestion Avoidance, que ocupan un tiempo de 79 segundos cuando se presenta una pérdida de datos del 0.5%.El segundo algoritmo que presenta buen rendimiento es TCP NewReno con Sack, que tiene un promedio de utilización de tamaño de ventana del 19.16% con una duración de 27,5 segundos.

En el servicio HTTP, el algoritmo que logra mayor rendimiento también es TCP CUBIC, con un promedio de utilización del tamaño de ventana de 11.79% y un tiempo de duración en la transmición de 115.9 segundos. En este servicio el algoritmo TCP Reno otorga mayor mejora a TCP que el algoritmo TCP NewReno con Sack.

Según la observación de los resultados, indican que para hacer contra aun problema de rendimiento del protocolo TCP, se sacrifica el rendimiento de otro. Las gráficas muestran que cuando hay un mayor rendimiento en la ventana de congestion de TCP, (descongestionamiento), el tiempo de transmisión se prolonga proporcionalmente se reduzca el tamaño de la ventana utilizable. El algoritmo Cubic que fue el que obtuvo una mayor reducción del tamaño de ventana utilizable también fue el que prolongo más el tiempo de la trasmisión.

7 REFERENCIAS

[1] Performance Evaluation of TCP Tahoe, Reno, Reno with SACK, and Performance Evaluation of TCP Tahoe, Reno, Reno with SACK, and NewReno Using OPNET Modeler. Laxmi Subedi, Mohamadreza Najiminaini, and Ljiljana Trajković. Simon Fraser University Vancouver, British Columbia.

7

[2] Simulation-based study of TCP flow control mechanisms using OPNET Modeler Guiomar Corral, Agustin Zaballos, Tomas Fulgueira, Jaume Abella Enginyeria i Arquitectura La Salle, Universitat Ramon Llull, Spain, EUROPE.

[3] RFC. TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms. [En línea] Diponible en: https://tools.ietf.org/html/rfc2001.

[4] Modified Tahoe TCP for Wireless Networks Using OPNET Simulator. M. N. Akhtar, M. A. O. Barry and H. S. Al-Raweshidy. Department of Electronic Engineering, University of Kent, U.K

[5] Adarshpal S. Sethi, Vasil Y. Hnatyshi . The Practical OPNET User Guide for Computer Network Simulation. CRC Press, Aug 24, 2012.

[6] TCP congestion control algorithms and performance comparison.Yuan-Cheng Lai, Chang-Li Yao. Departament of computer Science and Information Engineering National Cheng Kung University. 2001

[7] An Improved TCP Congestion Control Algorithm forWireless Networks. Ahmed Khurshid Department of Computer Science, University of Illinois at Urbana-Champaign ,Md. Humayun Kabir, and Md. Anindya Tahsin Prodhan. Department of Computer Science and Engineering Bangladesh University of Engineering and Technology. Dhaka, Bangladesh. 2011

[8] TCP-FIT - A Novel TCP Congestion Control Algorithm for Wireless Networks.Jingyuan Wang, Jiangtao Wen, Jun Zhang and Yuxing Han, State Key Laboratory on Intelligent Technology and SystemsTsinghua National Laboratory for Information Science and Technology (TNList) Department of Computer Science and Technology, Tsinghua University, Beijing, China. 2010

[9] Comparison of TCP congestion control mechanisms Tahoe, Newreno and Vegas Digvijaysinh B Kumpavat1, Prof. Paras S Gosai2, Prof. Vyomal N Pandya3.2013.

[10] Performance Evaluation and Comparison of Westwood+, New Reno, and Vegas TCP Congestion Control. Luigi A. Grieco and Saverio Mascolo Dipartimento di Elettrotecnica ed Elettronica, Politecnico di Bari, Italy

[11] TCP Performance - CUBIC, Vegas & Reno. Ing. Luis Marrone, Lic. Andr´es Barbieri, Mg. Mat´ıas Robles LINTI - Facultad de Informática, Universidad Nacional de La Plata La Plata, Buenos Aires, Argentina (2013)

[12] Performance Analysis of TCP Congestion Control Algorithms. International Journal Of Computers And Communications. Habibullah Jamal, Kiran Sultan (2008)

8