TCP Veno with Forward ACK

Una mejora a TCP VENO con Forward ACK
Resumen del Artículo Original Publicado en el 2008
Laura Piñeiro Méndez
Universidad Autónoma Metropolitana
DF, México
Keywords— Congestion control, Heterogeneous networks, TCP
Veno, Forward acknowledgement
I. INTRODUCCION
Con el crecimiento y desarrollo que se viene presentando
en las redes inalámbricas cada día, no queda duda que su papel
en las redes de telecomunicaciones irá en aumento. Sin
embargo, TCP presenta algunos problemas en las redes
inalámbricas debido a la alta tasa de bit erróneo (BER: Bit
Error Rate) que vale la pena analizar en aras de mejorar su
desempeño.
Originalmente TCP Reno fue ajustado para las redes
cableadas, donde la pérdida de paquetes es un buen indicador
de congestión. En respuesta a este evento TCP Reno disminuye
su tasa de envío con el objetivo de aliviar la congestión y
garantizar estabilidad en la red. Para las redes inalámbricas,
este escenario difiere un poco, debido a que la pérdida de
paquetes es a menudo provocada por un alto BER o por ruido
en la transmisión, en lugar de congestión (la literatura se refiere
en muchas ocasiones a este tipo de pérdida como pérdida de
paquetes aleatoria). Este error en la interpretación de la pérdida
de paquetes hace más lenta la tasa de transmisión y por
consiguiente disminuye el rendimiento de la red.
Con el objetivo de remediar este suceso se propuso una
nueva versión, llamada TCP Veno, pero aunque este muestra
una mejora notable del rendimiento de TCP en comparación
con su antecesor, no ha sido utilizado en todo su potencial. En
este artículo se hace un estudio de TCP Veno-F (TCP Veno
con Forward ACK).
TCP Veno hace uso de la idea del esquema de monitoreo de
la congestión que implementa TCP Vegas y la integra a TCP
Reno. TCP Veno solo modifica el algoritmo de incremento
aditivo - decremento multiplicativo (AIMD: Additive
Increment Multiplicative Decrement), pero no modifica los
mecanismos de retransmisión y recuperación acelerada (FF:
Fast Retransmit & Fast Recovery). Como es sabido estos
mecanismos reducen la ventana de congestión varias veces si la
pérdida de paquetes es detectada dentro de una ventana y
llevan la conexión a un estado de reinicio (TO: Time Out) lo
cual provoca una degradación del rendimiento de TCP.
Para tratar de eliminar este problema se propone TCP
Veno-F (TCP Veno FACK: TCP Veno Forward-ACK). TCP
Veno-F tiene como objetivo mejorar el desempeño de TCP a
través de una mejora en la eficiencia de recuperación. En el
artículo que se analiza, se hace un estudio de las ventajas que
añade TCP Veno-F a la red.
II. INVESTIGACIONES ANTERIORES
En los últimos años, algunos investigadores han estudiado
cómo mejorar el rendimiento de TCP a través de redes
cableadas e inalámbricas. TCP New Reno modifica el
comportamiento del lado del emisor, reconociendo una parte
de todos los paquetes pendientes (ACK parcial) cuando
múltiples paquetes se pierden en la fase de recuperación. Tras
la recepción de un ACK parcial, TCP New Reno retransmite el
paquete perdido, pero fija la ventana de congestión hasta que se
retransmiten todos los paquetes identificados como perdidos.
Como resultado de este mecanismo, TCP New Reno evita
múltiples reducciones de la ventana de congestión durante la
fase de recuperación. Otra variante de TCP es TCP FACK, este
mejora aún más la eficiencia de recuperación mediante una
mejor estimación de los paquetes pendientes en la red. TCP
FACK hace uso de la opción de reconocimiento selectivo
(SACK: Selective ACK) en el receptor TCP para informar con
precisión los paquetes perdidos, y luego los retransmite en un
tiempo de ida y vuelta (RTT: Round Trip Time) y envía nuevos
paquetes en la fase de recuperación.
TCP New Reno y TCP FACK no modifican nada en el
algoritmo AIMD de la fase de evasión de la congestión (CA:
Congestion Avoidance), por lo que la principal razón para los
problemas de rendimiento de TCP en las redes inalámbricas
todavía permanece allí. TCP Westwood, otra variante de TCP,
aborda este problema mediante la introducción de una nueva
técnica de estimación del ancho de banda del lado del
remitente. TCP Westwood estima el ancho de banda disponible
de la red, de forma dinámica mediante la medición de la tasa de
ACKs que llegan, y por lo tanto evita la reducción de la
ventana para pérdidas aleatorias de paquetes y mejora el
rendimiento de TCP en las redes inalámbricas.
Otra versión de TCP que también trata de mejorar este
problema es TCP Hybla, este elige una conexión de referencia
con el RTT0 de referencia, el algoritmo AIMD a continuación,
se ajusta para tener en cuenta el valor real de RTT de manera
que todas las conexiones Hybla co-existentes tienen un
rendimiento similar al de la conexión de referencia. TCP Hybla
exhibe una mejora significativa del rendimiento en los enlaces
que presentan grandes RTT. Sin embargo, es difícil estimar
dinámicamente el RTT de referencia más eficiente en la red.

Como se menciona anteriormente, la propuesta más
acertada para este problema ha sido TCP VENO-F por los
cambios que implementa en la etapa de CA [1].
III. TCP VENO-F
El mecanismo de TCP Veno-F se divide en dos partes: un
algoritmo para evitar la congestión (Veno CA: Veno
Congestion Avoidance) y el esquema de Forward-ACK
(FACK: Forward ACK). Este mecanismo hace uso del
esquema de monitoreo de la congestión que implementa TCP
Vegas, por lo que al igual que en este último, el esquema de
monitoreo de la congestión (Diff) es calculado por la diferencia
entre el caudal (throughput) de datos medidos (Actual) y el
esperado (Expected); se presenta a continuación la fórmula
utilizada, donde Cwnd es la ventana de congestión:
Diff = (Expected - Actual) (1)
Expected= Cwnd/RTTBase (2)
Actual= Cwnd/ RTT (3)
El RTTBase es el RTT mínimo de todos los RTT medidos y
es restablecido cuando se detecta la pérdida de paquetes. RTT
será el tiempo real de ida y vuelta de un paquete.
En el algoritmo Veno CA, para calcular el número de
paquetes acumulados en el cuello de botella se define la
variable N.
N= Diff*RTTBase (4)
Si N sobrepasa el umbral superior “b” de los paquetes que
están en cola para ser procesados, se dice que la red entro en
estado de congestión. Tal como en TCP Reno este estado
provocará la reducción de la ventana de congestión a la mitad,
sin embargo la perdida de paquetes en el estado de no-
congestión, solo hará que la ventana de congestión disminuya
1/5 de su valor. Por otra parte, se perfecciona la fase de
incremento aditivo de Reno al forzar la conexión TCP a
permanecer más tiempo en la región de operación. Todo el
algoritmo se muestra a continuación.
Decrecimiento Multiplicativo:
If (N < β) // pérdida aleatoria
ssthresh = cwnd *(4/5);
Else //pérdida por congestión
ssthresh = cwnd/2;
Incremento Aditivo:
If (N < β) //Ancho de banda disponible subutilizado
cwndþ += 1/cwnd //nuevo ACK recibido
Else // Ancho de banda disponible totalmente utilizado
cwnd+= 1/cwnd //Otro Nuevo ACK recibido
FACK es evocado cuando se detecta la pérdida de
paquetes. El esquema FACK se basa en la opción SACK de
TCP, y luego lleva a cabo un control preciso de los segmentos
pendientes. FACK utiliza las siguientes variables:
snd.fack: que representa los datos correctamente recibidos
con el número de secuencia más alto.
snd.una: que representa el primer segmento sin acuse de
recibo.
snd.nxt: que representa el siguiente nuevo segmento para
ser enviado.
retran_data: que representa el número de los segmentos
retransmitidos en el la red.
En la fase de CA, si no se produce ninguna pérdida de
paquetes, la variable snd.una debe ser igual a snd.fack, y más
pequeña que snd.nxt. Pero si se produce la pérdida de paquetes,
snd.una será menor que snd.fack, porque la opción SACK del
receptor informa los bloques no contiguos. Por lo tanto, la fase
de recuperación se desencadena por un triple duplicado ACK o
(snd.fack - snd.una)> 3. FACK utiliza una variable llamada
awnd para representar la estimación de los segmentos del
remitente que aún están en circulación. Cuando se retransmite
un segmento, el emisor aumenta la variable retran_data en un
segmento. Por otro lado, cuando se identifica que un segmento
ha dejado la red, el emisor disminuye esta variable nuevamente
en un segmento. En la fase de recuperación, si awnd es menor
que la ventana de congestión (Cwnd), el emisor puede inyectar
segmentos en la red, ya sean nuevos datos o retransmitir
segmentos que han sido reportados como perdidos a través de
los SACK. Si se envían nuevos datos, FACK avanza a snd.nxt;
si es la retransmisión de un segmento perdido, FACK aumenta
retran_data. Dado que FACK mantiene una estimación precisa
de la cantidad de segmentos pendiente en la fase de
recuperación, será más eficiente cuando hay pérdida de
múltiples paquetes en una ventana de datos.
3.1 Simulación
Los autores del artículo en cuestión, llevaron a cabo
pruebas de simulación para validar su investigación. Para esto
se utilizó el software Network Simulator 2.26 (NS 2.26) y se
desarrollaron dos topologías: escenario con un solo cuello de
botella (Fig 1.) para estudiar la sensibilidad de los parámetros
de TCP en este ambiente y otro escenario con múltiples cuellos
de botella (Fig 2.) que permite estudiar la compatibilidad entre
distintas conexiones TCP.
Fig 1. Escenario con un cuello de botella simple [1].

Fig 2. Escenario con cuellos de botella múltiples [1].
Para el primer escenario cada link entre los nodos y su
respectivo enrutador, fue configurado con una velocidad de 10
Mbps con un retardo de propagación de 0.1 ms. El enlace entre
los enrutadores es el cuello de botella en este escenario, y
utiliza una política de cola Drop Tail (FIFO: First In First Out,
no distingue entre paquetes) por defecto o política RED
(Random Early Detection: descarta paquetes de acuerdo a una
probabilidad determinada) si se indica lo contrario. Si el emisor
UDP es activado, enviará de forma continua los paquetes UDP
a su respectivo receptor. Se supone que todas las fuentes de
datos tienen infinitos datos para enviar, y que las ventanas de
recepción anunciadas se han fijado lo suficientemente grandes.
Para el escenario con múltiples cuellos de botella se definen
los enlaces entre los nodos y los enrutadores con los mismos
parámetros que para el primer escenario, para los enlaces entre
los enrutadores se define una velocidad de 4Mbps y un retardo
de extremo a extremo de 10 ms. Este escenario se utilizara para
analizar la compatibilidad de las conexiones TCP dado que el
medio esta compartido por varias conexiones TCP simultaneas
que deberán hacer una división equitativa de los recursos de la
red.
IV. ANÁLISIS DE LA SIMULACION A NIVEL DE PAQUETES.
Se inicia el análisis con el primer escenario para estudiar las
mejoras de rendimiento que se obtienen de la introducción de
TCP Veno-F. Para esto se definen los parámetros del enlace
cuello de botella:
* Ancho de Banda: 1.2 Mbps
* Retardo Extremo a Extremo: 60 ms
* Tamaño del buffer: 16 paquetes
* Producto Retardo-Ancho de Banda: 18 paquetes
De la simulación se obtiene que gracias al esfuerzo del
algoritmo Veno CA, TCP Veno-F detecta de forma inteligente
el estado de congestión de la red (N≥β) y activa su mecanismo
de disminución de la velocidad del crecimiento de la ventana.
Esto permite que TCP Veno-F permanezca más tiempo en la
región de alto rendimiento, y experimente un menor número de
oscilaciones de la ventana de congestión que sus variantes TCP
Reno y TCP New Reno.
Para mostrar este comportamiento en una red inalámbrica,
se introdujo a los parámetros de la red una tasa de pérdida
aleatoria del 1% en el último enlace y se mantuvieron el resto
de los parámetros. Se observa que, cuando la pérdida de
paquetes se produce condicionada por una N≥β, se reduce la
ventana de congestión a la mitad, tal como lo hace TCP Reno,
pero cuando la pérdida está condicionada por N˂β, TCP Veno-
F identifica la pérdida como aleatoria y disminuye la ventana
en 1/5 de su valor actual. Como resultado, TCP Veno-F
mantiene una ventana de congestión promedio más alta y por lo
tanto logra un mayor rendimiento que TCP Reno y las demás
variantes de Reno en las redes inalámbricas.
Para comprender los diferentes comportamientos en la fase
de recuperación, por TCP Veno-F y TCP-FACK
respectivamente, se hace en el artículo un análisis de un
escenario donde el valor de Cwnd es 16 y se pierden 4
paquetes en el intervalo de una ventana.
Al perderse estos cuatro paquetes, se envían los respectivos
ACK al emisor que indican la pérdida de los mismos. Cuando
el emisor recibe el segundo de los triple ACK-Duplicados, se
satisface la condición en su algoritmo de send.fack-send.una>3,
por lo que se activa en el emisor la fase de recuperación e
inmediatamente reenvía el primer segmento reconocido como
perdido sin esperar a la llegada del tercer ACK. Al detectar esta
pérdida en el estado de no congestión, la ventana de congestión
se reduce en 1/5 de su valor. Tras la recepción del próximo
ACK-Duplicado, el valor de awnd se reduce, por lo que Veno-
F retransmite el segundo segmento. A partir de entonces, más
ACK-Duplicados y ACKs parciales le permiten a Veno-F
retransmitir los restantes segmentos perdidos, así como
continuar con el envío de nuevos segmentos.
Suponiendo el mismo escenario pero esta vez, con TCP-
FACK. Cuando el remitente recibe el segundo ACK-
Duplicado, la fase de recuperación se desencadena tal como en
TCP Veno-F. Pero a diferencia de TCP Veno-F que detecta de
forma inteligente el estado no congestivo de la red, TCP-FACK
reduce ciegamente a la mitad la ventana de congestión. La
consecuencia directa es que el remitente debe esperar 6 ACK-
Duplicados para llevar a awnd a un valor menor que el de la
actual Cwnd, para retransmitir entonces el segundo segmento
perdido. A partir de entonces, más ACK-Duplicados y ACKs
parciales permiten que TCP-FACK retransmita el resto de los
segmentos perdidos y los nuevos segmentos.
Comparando estos dos escenarios se puede concluir que
TCP Veno-F es más eficiente que TCP-FACK en la fase de
recuperación pues para el primero, luego de la fase de
recuperación, la ventana de congestión recupera el valor inicial
que tenía antes de caer en esta fase, mientras que TCP-FACK
sale de la etapa de recuperación con la ventana disminuida a la
mitad.
Por lo tanto, Veno-F es más eficiente que Fack TCP en la
fase de recuperación [1].
V. EVALUACIÓN DEL RENDIMIENTO DE TCP VENO-F EN
DISTINTOS ESCENARIOS.
Para analizar el rendimiento de TCP Veno-F, los autores de
[1] trabajaron sobre tres escenarios: inalámbrico, tráfico
cruzado y multi-salto con tráfico inverso. Para cada simulación

que realizaron, se calculó la cantidad de datos efectivos
enviados a través de la red, este parámetro es definido como el
goodput y se calcula de la siguiente forma:
(6)
5.1 Escenario Inalámbrico
El primer escenario que se considera es la red heterogénea
cableada - inalámbrica. Se utiliza la topología de la Fig 1. El
remitente es el nodo estacionario y el cuello de botella es el
enlace por cable. El último enlace es inalámbrico. El ancho de
banda del enlace cuello de botella es 4,0 Mb, retardo de ida es
de 60 ms y el tamaño del búfer es de 42 paquetes. Para
considerar los efectos de las pérdidas de los segmentos en el
rendimiento de TCP, se utiliza el proceso de Markov de dos
estados para modelar la pérdida aleatoria [1].
El canal inalámbrico se considera que puede estar en un
estado alto, o en un estado bajo. La tasa de pérdida aleatoria en
un estado alto es Lg debido a la distribución exponencial; en el
estado bajo la tasa de pérdida aleatoria es Lb también por la
distribución exponencial. En el modelo analizado en [1], se
establece Lg=10-7
y Lb=10-1
. La probabilidad de transición entre
un estado alto y un estado bajo es 0.5 en ambos sentidos. La
duración de un estado alto es determinística e igual a 1s,
mientras que la duración del estado bajo también es
determinística, pero varía de 10-4
s a 10-1
s. En Fig 3. se
compara el goodput de varias versiones TCP para distintos
valores de duración de un estado bajo.
Fig 3. Impacto de la tasa de pérdidas aleatoria [1].
A medida que la duración del estado bajo aumenta, se
observa que, TCP Veno-F y TCP Westwood mantienen el más
alto goodput. Pero cuando aumenta la duración del estado bajo
a 0.01, la tasa de pérdida también aumenta y las pérdidas en el
medio inalámbrico dominan las pérdidas totales de paquetes.
TCP Veno-F experimenta menos recortes en la ventana de
congestión debido al esfuerzo del algoritmo Veno CA para
distinguir las pérdidas aleatorias, y se recupera rápidamente de
la pérdida de paquetes debido a su esquema Forward-ACK.
Como resultado, TCP Veno-F exhibe una mejora en el goodput
sobre TCP-FACK. Cuando la duración del estado bajo aumenta
a 0.1, la tasa de pérdida es muy alta y ni el algoritmo Veno CA,
ni el esquema Forward-ACK logran manejar tantas pérdidas de
paquetes, por lo que los goodputs de Veno y TCP-FACK se
ven degradados drásticamente. Pero Veno-F todavía mantiene
un valor de goodput bastante alto.
5.2 Escenario de Tráfico Cruzado.
Para este escenario se elimina la tasa de pérdida aleatoria, y
en su lugar, es introducido el tráfico UDP cruzado que varía de
0% a 80% del ancho de banda del cuello de botella.
Cuando el tráfico cruzado es 0%, caso común de ningún
tráfico cruzado, sin pérdida aleatoria y sin tráfico inverso, el
tamaño del búfer (normalización a 1) es 0,7. En este caso TCP
Veno-F, TCP Westwood, TCP Veno y TCP New Reno tienen
los mismos goodputs que TCP-FACK. Esto significa que TCP
Veno-F y las demás versiones de TCP mejoran en el uso
eficiente de todo el ancho de banda del enlace, tal como lo hace
TCP-FACK.
Al incrementar el tráfico cruzado, se obtiene que TCP
Veno-F y TCP-FACK presentan los más altos goodputs frente
a cualquier tipo de tráfico cruzado [1]. Este comportamiento
nos dice que el algoritmo de Veno para evitar la congestión
tiene un comportamiento similar al de Reno en la red cableada.
Otra observación es que TCP Veno tiene el goodput más bajo.
Esta observación nos dice que, Veno CA y Reno CA no tienen
mucha diferencia en la red cableada, entonces podemos decir
que aquí la fase de recuperación juega el papel principal en el
goodput de TCP. El goodput de TCP Veno es menor que TCP
Veno-F porque el esquema de Forward-ACK es más eficiente
que la retransmisión acelerada tradicional y que el algoritmo
de recuperación acelerada. Del mismo modo, se observa que el
goodput de TCP Veno está por debajo del de TCP Westwood y
TCP New Reno, que están basados en el esquema de
recuperación parcial de ACK de TCP New Reno.
5.3 Escenario de tráfico inverso y multisalto
En este escenario se utiliza la topología de cuello de botella
de la Fig 2. Los tráficos inversos Src2; Src4; . . . ; Src2n se
encienden, mientras que los tráficos hacia adelante SRC1;
SRC3; . . . ; Src2n- 1 se desconectan. El tráfico inverso maneja
TCP-FACK.
A medida que el número de saltos aumenta, el goodput de
TCP Veno-F disminuye y es más o menos lo mismo que FACK
TCP. Esta observación indica que TCP Veno-F no se ve
afectada negativamente por el tráfico inverso. Además,
proporciona más evidencia para apoyar el criterio de que TCP
Veno-F tiene el mismo comportamiento que TCP-FACK en las
redes cableadas. De nuevo se observa que el goodput de TCP
Veno está por debajo de TCP Veno-F y TCP-FACK, debido a
la falta del esquema Forward-ACK. Otra observación
importante es que, Westwood tiene el goodput más bajo,
debido a que mide la tasa de ACKs para estimar el ancho de
banda disponible. Si el tráfico inverso está encendido, el
intervalo de ACKs retornados es ampliado por los paquetes de
tráfico inverso. Esto hace que Westwood subestime el ancho de

banda disponible. Como resultado, se observa que Westwood
sufre una degradación significativa en este escenario [1].
5.4 Escenario Integral
Los resultados mostrados en las secciones anteriores
corresponden a distintos escenarios aislados, pero ¿qué pasaría
en un escenario más integral con pérdidas aleatorias, tráfico
cruzado y tráfico inverso?
Para dar respuesta a esta inquietud, los autores de [1]
utilizaron la topología de la Fig 1. El tráfico cruzado UDP se
establece en 20% del ancho de banda del enlace de cuello de
botella, el tráfico inverso está manejado por TCP-FACK y el
modelo de pérdida aleatoria en el último enlace es el mismo
que el utilizado en el escenario inalámbrico.
La Fig 4. muestra el goodput para TCP Veno-F, TCP
WestwoodNR, TCP Veno, TCP New Reno, and TCP-FACK
bajo este escenario.
Fig 4. Comparación del goodput en un escenario igntegral [1].
Observamos que, en el entorno integral, TCP Veno-F
presenta el mejor rendimiento. En comparación con las otras
versiones de TCP, TCP Veno-F se muestra robusto y flexible.
TCP Veno-F es capaz de mejorar el rendimiento de TCP
haciendo un mejor uso del ancho de banda del enlace, y su
mejora de rendimiento no se ve afectada negativamente por el
tráfico cruzado o el tráfico inverso.
VI. EQUIDAD Y COMPATIBILIDAD
6.1 Equidad Intra-protocolo
Para analizar este aspecto, se define un escenario con N
fuentes TCP encendidas que ejecutan la misma versión de
TCP, y con distintos valores de RTT distribuidos de forma
uniforme en un rango de 40 a 300 ms. La métrica de TCP para
la intra-equidad es el índice de equidad de Jain:
(7)
Donde Xi es el goodput de la i-ésima conexión y N es el
número de conexiones. El índice de equidad está acotado entre
0 y 1, J aumenta a medida que aumenta la equidad.
En el experimento realizado en [1], N varía de 10 a 100
conexiones. El enrutador del cuello de botella utiliza política de
cola RED que controla la longitud media de la cola y descarta
los paquetes de una manera probabilística.
Se observa con este experimento que TCP Veno-F y TCP
Veno muestran un buen desempeño; sus índices de equidad son
mejores que TCP-FACK en la mayoría de los casos. A grandes
rasgos, cuando el número de conexiones aumenta, los índices
de equidad también aumentan. Cuando N≥70 el índice de TCP
Veno-F aumenta hasta 0.9, pero en el caso de un ancho de
banda grande en el enlace cuello de botella, vemos que el
índice de TCP-FACK disminuye a 0.7, pero los índices de TCP
Veno-F y TCP Veno siguen siendo superiores a 0.8. Por lo
tanto, es posible afirmar que TCP Veno-F tiene una mejor
equidad intra-protocolo que TCP-FACK en la mayoría de los
casos.
6.2 Equidad Inter-Protocolos
Para el análisis de la equidad inter-protocolos es necesario
utilizar la topología de la Fig 2. con tráfico bidireccional
usando TCP VENO-F. El nodo fuente 0, utiliza de forma
alterna los protocolos TCP Veno-F, TCP Veno y TCP-FACK.
De las pruebas realizadas, se obtuvo que TCP Veno-F y TCP-
FACK casi tienen el mismo goodput, mientras TCP Veno no
pudo alcanzar todo el ancho de banda que le correspondía
debido a la falta del esquema Forward-ACK, por lo que los
otros dos protocolos obtienen mayor ancho de banda cuando
idealmente todos deberían obtener la misma cantidad.
Otro escenario que se analiza en este artículo es cuando el
tráfico en ambos sentidos está manejado por TCP-FACK y se
considera que el nodo emisor corre de forma alterna los
protocolos TCP Veno-F, TCP Veno, TCP-FACK y TCP
HyblaS. Para este caso, se obtiene que TCP HyblaS obtiene un
goodput mayor que TCP-FACK y sobrepasa el umbral de
equidad. Para el caso en que el enlace es compartido por TCP
Veno-F y TCP-FACK, ambos protocolos coexisten
armoniosamente en el enlace.
Con base en los resultados obtenidos por los investigadores
en estos escenarios, se llega a la conclusión de que TCP Veno-
F puede coexistir armoniosamente con TCP-FACK y además
se muestra que se adquiere una mejora del rendimiento del
enlace debido a que TCP Veno-F realiza un mejor uso del
ancho de banda disponible [1].
VII. CONCLUSIONES
En este trabajo se estudió el comportamiento de TCP Veno
con Forward-ACK. La motivación de los autores de [1] para
este estudio estuvo dada debido a que a pesar de que TCP Veno
ha logrado un éxito notable en la red inalámbrica, su potencial
no se ha utilizado plenamente porque los algoritmos de
retransmisión y recuperación rápida tienen una baja eficiencia
en la fase de recuperación. Como resultado, TCP Veno sufre
degradación del rendimiento en entornos de grandes pérdidas.
Debido a esto es que se propone la idea de añadir el esquema
Forward-ACK en TCP VENO con el fin de mejorar su
rendimiento en entornos de grandes pérdidas.

Como resultado de las simulaciones llevadas a cabo vemos
que la mejora del rendimiento en TCP Veno-F se obtiene a
partir de dos aspectos:
(1) el mantenimiento de una ventana de congestión en
promedio mayor al distinguir correctamente las pérdidas
aleatorias.
(2) conseguir una mayor eficiencia en la fase de
recuperación.
TCP Veno-F logra mayor goodput en comparación con
TCP-FACK y otras mejoras de TCP en una gran variedad de
entornos de red. Además, TCP Veno-F tiene destacada equidad
intra-protocolo y equidad inter-protocolo con TCP-FACK.
REFERENCIAS
[1] Ke Zhang , Cheng Peng Fu, “An enhancement of TCP Veno with
forward acknowledgement” School of Computer Engineering, Nanyang
Technological University, 639798 Singapore, Computer
Communications 31 (2008)

TCP Veno with Forward ACK

Más contenido relacionado

La actualidad más candente (20)

Similar a TCP Veno with Forward ACK (20)

Último (20)

TCP Veno with Forward ACK