Evaluacin de rendimiento de algoritmos de Congestin TCP en Riverbed

Modeler Academic Edition

Laura Daniela Acosta Contreras
Universidad Distrital Francisco Jos de Caldas
Bogot, Colombia
[email protected]

Sergio Alexander Gutirrez Bustos

Universidad Distrital Francisco Jos de Caldas
Bogot, Colombia
[email protected]

RESUMEN: TCP es el protocolo de transmisin ms

popular en internet. Han surgido muchos algoritmos de
control de congestin para mejorar el rendimiento de este
protocolo; gestin de conexin, manejo de prdida de datos y
reducir el nmero 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 congestin y el proceso de recuperacin
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 tamao
de ventana ya que esta tiene un comportamiento estable en
5,000 , aunque aumenta el tiempo de duracin de la
transmisin, ya que el promedio de duracin con los dems es
de 2m 28 s y el de Cubic es de 3m 50 s.

El algoritmo de control de congestin es un mdulo integrado de TCP

que determina el rendimiento del protocolo. Los algoritmos estndares
de control de congestin 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.

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.

Funcionamiento de Slow Start:

1.

Slow Start proporciona una manera de controlar el flujo de datos

inicial al comienzo de una comunicacin y durante una
recuperacin 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 ningn
recurso, por lo que los nuevos datos se pueden enviar.

El receptor enva un nmero de segmentos igual al MINIMO de

lo indicado por la ventana anunciada por el receptor y lo
indicado por la ventana de congestin. Gestin de cwnd:

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

tcp.

1 INTRODUCCIN
El Protocolo de Control de Transmisin TCP es actualmente el
ms utilizado en Internet, soportando aproximadamente el 90 %
del trfico de Internet tanto en redes cableadas como inalmbricas
[1]. Con el avance de la ciencia surgen nuevas tecnologas y
dispositivos, y cada vez es mayor el nmero de conexiones y el
trfico en internet, provocando posibles errores en la transmisin
debido a la cantidad de conexiones simultneas recibiendo y
enviado datos. Esto requiere un mximo rendimiento en el
protocolo TCP, con mnimos errores en transmisin y control de
congestin, 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.

SLOW START

Inicio de la conexin: UN segmento de tamao

mximo igual al anunciado por el receptor. La primera
transmisin 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 enva 2 segmentos.
Cada vez que recibe un ack, el transmisor incrementa
en uno el nmero de segmentos transmitidos
(incrementa la ventana de congestin).

Slow-start impone un ritmo inicial lento de envo de datos a la

red, ritmo que se incrementa muy rpidamente si las redes lo
permiten.
Un parmetro: Round-Trip -Time, perodo que va desde el
momento en que se enva un segmento y aquel en el que se
recibe su ack.

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 contina hasta que TCP est a
medio camino de donde estaba cuando se produjo la congestin
(ya que registr la mitad del tamao de la ventana que caus el
problema en el paso 2) y, a continuacin, congestion avoidance
se hace cargo.

2.

CONGESTION AVOIDANCE
Es un algoritmo que adapta la transmisin de datos a los
recursos disponibles. Despus de Slow Start ha alcanzado
un cierto umbral, la congestion avoidance comienza a
retrasar la apertura de la ventana.
La congestin se puede producir cuando los datos llegan en
un gran canal y se enva a un canal ms pequeo,
produciendo el efecto cuello de botella. La congestin
tambin puede ocurrir cuando mltiples flujos de entrada
llegan a un router cuya capacidad de produccin es menor
que la suma de las entradas. Evitar la congestin es una
manera de lidiar con la prdida de paquetes. Hay dos
indicaciones de prdida de paquetes: un tiempo de espera se
produce y la recepcin de ACKs duplicados.
Congestion Avoidance y Slow Start son algoritmos
independientes con diferentes objetivos. Pero cuando se
produce la congestin TCP congestion avoidance debe
frenar la velocidad de transmisin de paquetes en la red, y
luego invocar Slow Start para que funcione de nuevo. En la
prctica se implementan juntos.
Congestion Avoidance y Slow Start requieren que se
mantengan dos variables para cada conexin: una ventana
de congestin, cwnd, y un tamao de umbral de inicio lento,
ssthresh. El algoritmo combinado funciona de la siguiente
manera:
1.
2.
3.

4.

Inicializacin por conjuntos de conexin dadas CWND

a un segmento y ssthresh a 65.535 bytes.
La rutina de salida TCP nunca enva ms que el mnimo
de cwnd y la ventana anunciada del receptor.
Cuando se produce la congestin (indicada por un
tiempo de espera o de la recepcin de ACKs
duplicados), se establece el tamao a la mitad de la
ventana actual. (el mnimo de cwnd y ventana
anunciada del receptor, pero al menos dos segmentos)
se guarda en el ssthresh. Adems, si la congestin es
indicada por un tiempo de espera, cwnd se establece en
un segmento (es decir, Slow start).
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.

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 congestin dicta que cwnd
se incrementa en SEGSIZE * SEGSIZE / cwnd cada vez que se
recibe un ACK, donde SEGSIZE es el tamao de segmento y
cwnd se mantiene en bytes. Este es un crecimiento lineal de
cwnd, en comparacin con el crecimiento exponencial de
comienzo lento. El aumento de cwnd debe ser como mximo de
un segmento cada vez de ida y vuelta (sin tener en cuenta el
nmero de ACKs se reciben en ese RTT), mientras que los
incrementos comienzo lento CWND por el nmero 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
slo un segmento se pierde, pero en un escenario inalmbrico,
habr segmento de mltiples drops en una transferencia y
tambin en los medios de comunicacin no fiables. En caso de
mltiples segmentos perdidos, hace el tamao de la ventana
utilizable para cada segmento se reduzca a la mitad. Adems, la
ventana utilizable disminuye durante la fase de Fast recovery, y
se enva ms informacin, cada vez que un duplicado reconoce
que es recibida. Cuando el temporizador de retransmisin expira
la ventana de congestin 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 rfagas de errores. Los algoritmos tradicionales dan poca
informacin sobre los segmentos que tienen o no han llegado a
su destino. Esta informacin permite retransmitir slo un
segmento por el tiempo de ida y vuelta. Adems, el transmisor
puede crear una situacin en la que los paquetes que han llegado
correctamente a su destino se retransmiten, cuando no haba
ninguna necesidad de hacerlo. Esto podra suceder si el
transmisor utiliza un tiempo de retransmisin corto. Por otra
parte, esta situacin sera aumentar la congestin 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 retransmisin se produce slo para
paquetes perdidos. Sack informa de los segmentos que han
alcanzado el receptor aunque llevan nmeros de secuencia no
consecutivos. Esto significa que, si hay un segmento que falta
entre otros dos segmentos, el receptor puede reconocer tanto

cul de ellos es. Y esto se hara 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], evalan el
rendimiento de TCP Tahoe, Reno, Reno con SCAK y New
Reno usando Opnet moder. La evaluacin de los algoritmos
se hace sobre un escenario inalmbrico. La simulacin
consiste en un cliente mvil usando el protocolo de
transferencia FTP conectado a un router con un cable de
10Mbps, y un router inalmbrico conectado a un router a 1.5
Mbps. Los archivos de transferencia usados sobre FTP tienen
un tamao de 50MB. Se Analiza la congestin y el proceso
de recuperacin de cada algoritmo TCP mediante la
observacin de la congestin tamao de la ventana, el tiempo
de respuesta de descarga de archivos, rendimiento, y goodput.
Los resultados de la simulacin indicaron que las redes
inalmbricas con atenuacin de seal, fading y multipah, TCP
Reno supera a otros algoritmos de control de congestin en
trminos de tamao de ventana y en tiempo de respuesta en la
descarga de archivos. TCP Reno con SCAK muestra un
mayor rendimiento y goodput en comparacin 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
transmisin 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. Despus de analizar los resultados llegan a
la conclusin 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 ms de un error. Usuario.
Yuan-Cheng Lai, Chang-Li Yao en su trabajo titulado TCP
congestion control algorithms and performance comparison
[6]. Realizan una comparacin 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 propagacin, con un tamao de paquete
fija que es de 512. Llegando a la conclusin 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 tambin eleva el rendimiento pero tiene un
problema de equidad.

TCP K-Reno. Tambien realizan la comparacin del rendimiento de una

sola conexin TCP sin trfico 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 caracterstica que es de
extremo a extremo y modifica slo el lado del remitente de una
implementacin TCP. Mantiene el receptor TCP y la red desconoce las
modificaciones. Est caracterstica hace que sea adecuado para el
despliegue en el escenario de la vida real. Como trabajos futuros van a
incorporar el patrn RTT en la congestin 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 congestin
TCP llamado TCP-FIT, para redes que presentan perdidas como las
inalmbricas. Los reultados obtenido en el paper muestran mejora de
rendimiento significativo, En la simulacin la SINR de LTE UE vario de -1
dB a 15 dB, junto con otros parmetros modificados, Tambien hicieron uso
de la capa de aplicacin de tcnicas en paralelo que es E-MULTCP, en la
que incluan mayor rendimiento , bajaba la latencia y mantenan la
equidad.

El algoritmo no requiere modificaciones por parte de los clientes y

de las aplicaciones de software

3 SIMULACIN
El modelo propuesto para el anlisis y simulacin de los algoritmos de
congestin 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
estacin de trabajo y un router conectados a travs de cable 100BasteT.
La Imgen 1., muestra el modelo recreado. La conexin de las dos
redes (Bogota - Brasilia) con la WAN Internet se estableci a travs
de cable Duplex Link PPP DS3.
La simulacin se realiza durante 600 segundos, en los distintos
escenarios de cada algoritmo, Se configura una prdida de datos en
0.5% con el fin de visualizar el rendimiento de recuperacin de los
algoritmos.

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 congestin que se pueda incorporar con cualquier
varieante TCO existente y es capaz de interactuar de manera eficiente
con redes heterogneas. Realizan la simulacin con una nica
conexin TCP con 2 UDP activada por diferentes variantes de TCP

Imgen 1Modelo de Red Diseado de Riverbed Modeler

Se crean dos aplicaciones de servicios (HTTP y FTP) configurados

en los servidores de la red Bogota, y consumidos por la estacin de
trabajo ubicada en la red Brasilia. Los parmetros de configuracin
de cada servicio se presentan en la Tabla 1.

RTO durante la duracin de una conexin de acuerdo con el algoritmo

de Kanrns [5].
Parameters TCP
Receive Buffer (bytes)

6553
5
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 2Parmetros TCP Generales

Command Mix (Get/Total): especifica la proporcin entre el

nmero de operacin y el nmero total de operaciones de FTP.
Inter_request Time: especifica la cantidad de tiempo entre
operaciones consecutivas de FTP. La hora de inicio de la prxima
transferencia de archivos se calcula aadiendo el valor de este
atributo a la vez de cuando comenz la operacin 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 tamao en bytes de los archivos
que van a ser transmitidos.
HTTP Specification: Define la versin del protocolo HTTP:
Page Interarrival Time (seconds): especifica el tiempo de entre
la solicitud de pgina web consecutivos. Este atributo define
efectivamente el comportamiento del usuario de navegacin web.

Objetive Size (bytes): especifica el tamao de un objeto

simple dentro de una pgina web.
Number of Objects: especifica el nmero de objetos de un
determinado tipo dentro de la pgina 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.1
Page Interarival Time
Constant (3600)
Objetive Size (bytes)
Constant (9000000)
Number of Objects
Single Object
Tabla 1Parmetros de configuracin para las aplicaciones
Los parmetros 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 transmisin a las capas superiores.
Maximum ACK Delay (sec): especifica la duracin mxima de
tiempo en segundos que esperar un proceso TCP antes de enviar
un "dataless" ACK.
Maximum ACK Segments: especifica el nmero mximo de
segmentos TCP debe recibir antes de enviar un "dataless" ACK.
Duplicate ACK Threshold: especifica el nmero 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): especfica valores iniciales, mnimos y mximos para el

3.1 ESCENARIO TCP SLOW START Y

CONGESTION.
En este primer escenario se presenta la configuracin del Slow Start y
Congestion Avoidance para los dos servicios, en este punto el protocolo
TCP no tiene implementado ningn algoritmo de Fast Retransmit y ni
de Fast Recovery.
En la Grafica 1. La lnea 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 estndar 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 comunicacin y durante la
recuperacin de errores de los ACKs controlando el flujo de datos
inicial. Congestion Avoidance adapta la transmisin de datos a los
recursos disponibles justo despus que Slow Start termina el ciclo en
menos de un segundo, provocando retrasar la apertura de la ventana. En
la grfica llega hasta 130 bytes a los 2m 23s para el servicio FTP,
despus de un intervalo de aproximadamente 30s que el tiempo de vida
del algoritmo Congestion Avoidance. Para el servicio HTTP (lnea
roja), tiene un comportamiento idntico.
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 algn error y recuperacin en la trasmisin,
el flujo de datos es detenido totalmente provocando lentitud en la
trasmisin.

Grfica 1Rendimiento TCP Slow Start - Congestion Avoidance

Grfica 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 tambin una mejora en los tiempos de la transmisin para
algunos servicios. En la Grfica 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 aumentndolo 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 transmisin de 3.5 segundos.

Grfica 2Rendimiento TCP Slow Start y Congestion Avoidance

con prdida 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
Grfica 3. Muestra la mejora de tiempo que se obtiene al
implementar Fast Retrasmit, en relacin a la Grfica 2., en el
escenario dos con 0.5% de perdida de datos. El servicio FTP tiene
una mejora de tiempo de50 segundos, adems de una mejora en la
congestin 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
transmisin de 35 segundos, aunque el tamao de ventana de
congestion aumento con un promedio de uso mximo de 42 bytes,
en comparacin al anterior con un promedio mximo de 39 bytes.

Grfica 4. Rendimiento TCP Reno.

3.4 ESCENARIO NEWRENO CON SACK

En este escenario se presenta la configuracin de TCP NewReno
junto con Sack, donde hay una leve mejora de congestion en la
transmisin, ampliando la ventana de congestion utilizable
restante, como se aprecia en la Grfica 5., la congestion del
servicio HTTP disminuyo en 0.90%, pero se aument levemente el
tiempo de transmisin cerca de 3 segundos. El servicio FTP
obtuvo un mejor resultado el tamao de congestion de ventana
disminuy casi 1.01 % y adems disminuyo el tiempo de
transmisin aproximadamente en 3 segundos.

Grfica 6. Rendimiento TCP CUBIC.

Grfica 5. Rendimiento TCP NewReno con Sack

3.5 ESCENARIO CUBIC CON SACK

Con el algoritmo CUBIC se obtiene un mayor rendimiento en el
tamao de ventana de congestion muy significativo a pesar de que
el tiempo de transmisin aumenta considerablemente. En la
Grfica 6., se puede observar que despus los 3 primeros segundos
de transmisin la el tamao de ventana disminuye en ms de un
90%, pero el tiempo aumenta proporcionalmente.

Grfica 7 Comparacin de los algoritmos de congestion TCP en el

servicio FTP.

En la Grfica 7. Se muestra el rendimiento de la ventana de congestion

sobre el servicio FTP en los diferentes algoritmos de congestion
implementados. La lnea amarilla representa el protocolo TCP estndar,
se observa que el tiempo de transmisin es bastante largo con un
tamao de ventana de congestion promedio entre los dems algoritmos,
la lnea azul, representa el algoritmo CUBIC, es el que tiene mayor
rendimiento aunque el tiempo de duracin de la transmisin sea el ms
prolongado. La Grfica 8. , que representa el rendimiento de ventana de
congestion sobre el servicio HTTP, muestra resultados similares.

Estndar
Slow Start - Congestion
Avoidance
TCP Tahoe

130,57

100,79

17,5

66,52

23,38

54

65,52

22,19

21

TCP Reno
TCP New Reno con
Sack

66,27

19,28

25,6

66,52

20,32

25,8

115,
9
Tabla 4. Resultados del anlisis de congestion en el servicio HTTP.
TCP Cubic

65,7

5 DISCUSIN

11,79

DE RESULTADOS

MTV (bytes)
PTV

TT
(sec)

SERVICIO HTTTP
SERVICIO FTP
Tabla 5. Comparacin de resultados de Servicio HTTTP yFTP

6 CONCLUSIONES
Grfica 8 Comparacin de los algoritmos de congestion TCP en
el servicio HTTP.

4 RESULTADOS
Para obtener los resultados a partir de anlisis de las grficas y los
datos obtenidos desde Opnet Modeler, se procede a tomar todos
los puntos que arrojan las grficas segn el algoritmo utilizado,
tanto del tamao de ventana (bytes) como en tiempo de duracin
de la transmisin. Para el tamao de ventana se sacan dos datos;
MTV que representa el Mximo umbral alcanzado, y PTV, que
representa el promedio del tamao de ventana utilizado durante la
transmisin. Para el tiempo, se saca el intervalo de tiempo que
dura la transmisin TT. En la Tabla 3 y 4 se visualizan los datos
analizados segn el tipo de servicio FTP y HTTP .
SERVICIO FTP

130,57

100,76

TT
(SEC
)
18,5

67,83

18,93

79

68,92

20,60

28

TCP Reno

68,29

19,53

32

TCP New Reno con Sack

69,96

19,16

27,5

ALGORITMO
Estndar
Slow Start - Congestion
Avoidance
TCP Tahoe

MTV
(BYTES)

PTV

En el servicio FTP, el algoritmo que logra un mayor rendimiento en la

ventana de congestin es TCP CUBIC, con un promedio de utilizacin
en la ventana de congestion de 8.42% frente al algoritmo estndar de
TCP, donde no se presenta perdida de datos. En el tiempo de
transmisin CUBIC es el ms prolongado con 130 segundos frente al
resto de algoritmos que no superan los 35 segundos, excepto el
algoritmo estndar Slow Start junto con Congestion Avoidance, que
ocupan un tiempo de 79 segundos cuando se presenta una prdida de
datos del 0.5%.
El segundo algoritmo que presenta buen rendimiento es TCP NewReno
con Sack, que tiene un promedio de utilizacin de tamao de ventana
del 19.16% con una duracin de 27,5 segundos.
En el servicio HTTP, el algoritmo que logra mayor rendimiento tambin
es TCP CUBIC, con un promedio de utilizacin del tamao de ventana
de 11.79% y un tiempo de duracin en la transmicin de 115.9
segundos. En este servicio el algoritmo TCP Reno otorga mayor mejora
a TCP que el algoritmo TCP NewReno con Sack.
Segn la observacin de los resultados, indican que para hacer contra
aun problema de rendimiento del protocolo TCP, se sacrifica el
rendimiento de otro. Las grficas muestran que cuando hay un mayor
rendimiento
en
la
ventana
de
congestion
de
TCP,
(descongestionamiento), el tiempo de transmisin se prolonga
proporcionalmente se reduzca el tamao de la ventana utilizable. El
algoritmo Cubic que fue el que obtuvo una mayor reduccin del tamao
de ventana utilizable tambin fue el que prolongo ms el tiempo de la
trasmisin.

7 REFERENCIAS

TCP Cubic
65,7
8,42
130
Tabla 3. Resultados del anlisis de congestion en el servicio FTP.
[1]

ALGORITMO

SERVICIO HTTTP
MTV
(bytes)

PTV

TT
(sec)

[2]

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.
Simulation-based study of TCP flow control mechanisms using OPNET
Modeler Guiomar Corral, Agustin Zaballos, Tomas Fulgueira, Jaume

[3]
[4]
[5]
[6]

[7]

Abella Enginyeria i Arquitectura La Salle, Universitat Ramon Llull,

Spain, EUROPE.
RFC. TCP Slow Start, Congestion Avoidance, Fast Retransmit, and
Fast Recovery Algorithms. [En lnea] Diponible en:
https://tools.ietf.org/html/rfc2001.
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
Adarshpal S. Sethi, Vasil Y. Hnatyshi . The Practical OPNET User
Guide for Computer Network Simulation. CRC Press, Aug 24, 2012.
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
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. Matas Robles LINTI - Facultad de Informtica,
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)