TCP Reno vs TCP Vegas en EasySim - Instituto de Ingeniería Eléctrica

Implementación del TCP en el simulador de redes
EasySim. Análisis de las versiones Reno y Vegas del
TCP.
1 Introducción
EasySim es un simulador de redes desarrollado en Java realizado por estudiantes de
Ingeniería Eléctrica para un proyecto de fin de carrera. Su funcionamiento es parecido al
simulador NS-2 de Berkeley, pero su utilidad esencialmente menor debido al poco
tiempo de desarrollo del mismo. Sin embargo, la arquitectura de EasySim es tal que
permite de forma relativamente fácil la adición de diferentes elementos que brinden
mayor funcionalidad al mismo.
En la etapa actual del simulador, se cuenta con herramientas para simular redes sin
protocolos de enrutamiento ni de transporte. Los paquetes generados por las fuentes
seguirán siempre el mismo camino a través de la red, caminos establecidos en base a
tablas de ruteo estáticas definidas por el usuario en la etapa de configuración de la red.
El enrutamiento de los paquetes se realiza en base a etiquetas que estos llevan consigo,
del mismo modo que ocurre en una red MPLS. La etiqueta que cada paquete lleva
adosada también se define en la etapa de configuración de la red junto con otros
parámetros de calidad de servicio que permite la simulación de redes con mecanismo
DiffServ.
Hasta el momento, no existe ningún agente de transporte que asegure una confiable
entrega de paquetes al destino. Simplemente, EasySim posee un generador de tráfico
incluido en cada Host que inyecta paquetes en la cola de salida del nodo para su envío
inmediato a través del enlace. Si los paquetes se pierden por el camino ya sea por
problemas en los enlaces o overflows en las colas, nada se puede hacer.
La idea del presente trabajo es la inclusión de un agente de transporte a EasySim,
concretamente la inclusión del TCP, como entidad encargada de una comunicación
confiable extremo a extremo de la comunicación, y la puesta en practica del simulador
con dicho protocolo. Para esto último se decidió analizar y comparar la performance de
una conexión cuando el agente de transporte es TCP Reno por una lado, y cuando se
trata de una conexión TCP Vegas. Estas versiones del TCP se diferencian
principalmente, como se verá mas delante, en el mecanismo de control de congestión, y
ambas fueron definidas en el simulador.
El resto del trabajo esta organizado de la siguiente manera: el capítulo 2 da una breve
reseña a la arquitectura del simulador EasySim. El capítulo 3 describe el algoritmo TCP,
tanto para Reno como para Vegas implementado en el simulador. El capítulo 4 analiza
el comportamiento de las versiones Reno y Vegas del TCP.
2 Arquitectura de los Hosts del simulador
En este capítulo se intentará dejar en claro el mecanismo de inclusión de un agente de
transporte en el simulador. Para ello será necesario entender el funcionamiento de un
Host de EasySim. La figura 2.1 ilustra la arquitectura interna de un host. En esta figura
aparecen los tres componentes fundamentales de un host, a saber, los generadores de
tráfico, el agente de transporte y la cola de salida. A cada lado de esta entidades
abstractas aparecen las definidas hasta el momento, incluidas las versiones del TCP
Reno y Vegas incluidas en esta etapa.
Figura 2.1. Arquitectura de un host en EasySim
Como se observa en la figura, en cada host del simulador, los generadores de tráfico
inyectan de paquetes a los agentes de transporte. Estos a su vez, generan sus propios
paquetes dependiendo de la clase de protocolo. Por ejemplo, el TCP construye paquetes
de 1500 bytes con los datos recibidos de las aplicaciones y los envía a la capa inferior
de la pila de protocolos.
Antes de incluir el TCP como agente de transporte en el simulador, los paquetes, si bien
atravesaban por un agente de transporte, eran de inmediato colocados en la cola de
salida del host, vale decir, el agente definido hasta ese entonces no creaba nuevas
estructuras de paquetes ni realizaba ninguna gestión sobre ellos. La idea que se tubo en
la etapa de diseño del simulador era justamente la creación de un agente abstracto que
brindara únicamente la conectividad necesaria con las demás entidades del sistema, y
dejar el esqueleto para la inclusión de agentes reales de transporte.
Los paquetes generados por los agentes de transporte son enviados a la cola de salida
del host para su futuro envió por el enlace de comunicación. La rapidez con que un
paquete deja la cola dependerá del scheduler definido para la cola. Como se observa en
la figura 2.1, se han definido hasta el momento 6 schedulers 1 y 2 queue management2
para el funcionamiento de las colas. Cuatro de estos seis schedulers atienden parámetros
de calidad de servicio, vale decir, despachan paquetes de acuerdo a la prioridad del
retardo que estos posean. Los queue management funcionan como un filtro de paquetes
colocado a la entrada de cada cola. Este filtro decidirá si el paquete que arriba entra a la
cola o es descartado por el sistema. El queue management mas conocido es Drop Tail,
donde simplemente se descarta en paquete cuando la cola alcanza el estado de overflow.
Sin embargo, los routers de hoy día están siendo equipados con el mecanismo RED en
las colas del los enlaces, mecanismo especialmente útil cuando se trata de una red
TCP/IP ya que este sistema permite la cancelación de las oscilaciones de las colas. En el
simulador también fue incluido este mecanismo como queue management alternativo al
Drop Tail. Tanto los schedulers como los queue management son seleccionados por el
usuario desde la interfaz gráfica en la etapa de configuración de la red.
Tanto la inclusión de nuevos agentes de transporte, nuevos generadores de tráfico o
nuevos tipos de colas se realiza de manera relativamente sencilla en el simulador, y se
remite al lector a leer la documentación al respecto en el manual del simulador. [2]
3 Descripción del TCP incluido en EasySim
Como se mencionó anteriormente, EasySim provee del esqueleto para la inclusión de
nuevos agentes de transporte, el cual brinda la conectividad con las otras clases del
sistema. Los paquetes que alimentan al agente provienen de los generadores de tráfico y
los paquetes generados por los agentes deben ser colocados en la cola de salida del host.
Una vez creado el agente de transporte, la conexión con los generadores de tráfico como
con la cola de salida del hosts estarán ya implementadas por el sistema.
3.1 Conexiones TCP
Como sucede en la realidad, un mismo agente TCP puede estar manejando varias
conexiones a la vez, identificadas cada una de ellas por puertos TCP. El agente TCP
creado no escapa a esta regla, y por cada generador de tráfico que se incluya en el host,
el agente TCP creara una nueva conexión que se abrirá una vez que el generador
comience a producir paquetes. Cada conexión creada por el sistema trabajará de manera
independiente de las demás, compartiendo por supuesto, el ancho de banda del enlace
de comunicación.
3.2 Establecimiento de una conexión
El protocolo TCP es orientado a la conexión. Esto significa que antes de comenzar a
intercambiar paquetes, las entidades TCP de los extremos de la comunicación
establecen una conexión. El TCP usa el protocolo de acuerdo de tres vías ( three way
handshake ) para llevar a cabo la misma.
1
1
2
1
2
Proceso encargado de despachar los paquetes de la cola.
Proceso encargado de controlar el estado del buffer.
La versión del TCP incluida en el simulador realiza un algoritmo parecido al three way
handshake , no exactamente el mismo, ya que el interés primario es el análisis de la
performance le protocolo una vez establecida la conexión, vale decir, cuando el TCP ha
alcanzado el estado de ESTABLISHED. La descripción del algoritmo es como sigue:
Con el primer paquete producido por cada generador, el TCP abre una nueva conexión,
asignándole un nuevo número de conexión, y envía un paquete TCP con un flag SYN=1
y ACK=0 hacia el otro extremo de la comunicación iniciando además un timer. Si este
paquete TCP es recibido correctamente por el receptor, este envía otro paquete TCP con
SYN=1 y ACK=1 indicando que ha recibido el anterior. A la recepción de este paquete
por el transmisor, este inicializa sus variables y se comienza con la transmisión de
datos. Si alguno de los paquetes de establecimiento de conexión se pierde por el
camino, el timer del transmisor da time out y se comienza de nuevo.
3.3 Parámetros del TCP y sus valores iniciales
A continuación se describen los parámetros incluidos en esta versión del TCP y los
valores iniciales o por defecto que estos adoptan según [1].











SEG_SIZE: Tamaño máximo de segmento configurable por el usuario desde la
interfaz gráfica. El TCP implementado solo envía paquetes de tamaño
SEG_SIZE. El valor por defecto es de 1500 bytes.
rwnd_ini: Ventana inicial anunciada por el receptor en unidades de SEG_SIZE.
Este valor también es configurable por el usuario y en esta versión del TCP, la
ventana de recepción actual rwnd siempre es igual a este valor inicial, vale decir,
la aplicación del lado receptor es infinitamente rápida. Su valor por defecto es de
100 x SEG_SIZE.
ssthresh_ini : Umbral de congestión inicial. Este valor se especifica en kbytes y
es el valor de cwnd a partir del cual se pasa al estado de CONGESTION
AVOIDANCE. Su valor inicial es de 64 kbytes.
rwnd : Ventana anunciada por el receptor. En esta versión del TCP
rwnd=rwnd_ini durante el transcurso de la simulación. Su valor inicial se
establece por lo anunciado por el receptor en la etapa de establecimiento de la
conexión.
cwnd : Ventana de congestionamiento. Valor inicial cwnd=1.
ssthresh : Umbral de congestionamiento. Valor inicial: ssthresh=ssthresh_ini.
snd_wnd : Ventana disponible para enviar nuevos segmentos, calculada como
snd_wnd=min{cwnd,rwnd}.
MaxRexmitTimes : Numero máximo permitido de time outs. Luego de
MaxRexmitTimes time outs se aborta la conexión. Su valor por defecto es
MaxRexmitTimes=12.
RTT : Tiempo estimado de ida y vuelta de un segmento. Su valor inicial es de
0.0 segundos.
RTO : Tiempo de expiración del timer de retransmisiones. Su valor es calculado
dinámicamente en base a los valores medidos para RTT y el algoritmo de Karn y
Jacobson. Su valor inicial es de 3.0 segundos.
MaxRTO : máximo tiempo de asignación posible para RTO. Su valor por
defecto es de 64.0 segundos.
3.4 Estimación del RTT (M) y cálculo del RTT y RTO
A continuación se muestra el algoritmo de estimación del tiempo de ida y vuelta de un
segmento, M, y el cálculo de los valores de RTT y RTO usados en la presente versión
del TCP, mediante el uso un pseudo código:
Para la estimación del RTT, es decir, el valor de M:



Con el envió de un segmento
o Si ya esta corriendo la medida del rtt para un segmento, no reinicie la
medida
o Si no se esta midiendo el rtt de ningún segmento, reinicie la medida del
rtt.
Con el envió de una retransmisión
o Si esta corriendo la medida del rtt de algún segmento, cancélela.
o Si no esta corriendo la medida del rtt para ningún segmento, no reinicie
la medida.
Con el arribo de un ack
o Establezca el valor de M a la diferencia entre el tiempo de envió del
paquete y el tiempo de llegada del ack.
Dado un valor para M, el RTT y RTO se calculan mediante el algoritmo de Jacobson,
como sigue
D=ALFA*D+(1-ALFA)|RTT-M|;
RTT=ALFA*RTT+(1-ALFA)*M;
RTO=RTT+4*D;
Donde ALFA es un valor constante fijado en 7/8.
3.5 Gestión de la ventana de envío y procesamiento de acks
Esta sección intenta dar una idea de cómo procede el TCP con la llegada de un ack al
transmisor.
Con la llegada de un ack, el algoritmo primero actualiza todas la variables y luego envía
la ventana disponible snd_wnd. La ventana disponible snd_wnd se calcula como el
mínimo entre la ventana de congestionamiento y la ventana de recepción, esto es,
snd _ wnd  mincwnd, rwnd
El valor de rwnd se dijo que permanece constante en todo el proceso de simulación, sin
embargo, la actualización de cwnd depende del estado del TCP. A continuación se
describen los cuatro estados del TCP, para las versiones de Reno y Vegas
implementadas en el simulador.
3.5.1 Slow Start

TCP Reno
Con la recepción de un nuevo ACK:

si cwnd =< ssthresh
1. cwnd ++
2. envíe la ventana disponible.
 en cambio si cnwd > ssthresh, pase a congestión Avoidance para
procesamiento del ACK
Con la recepción de un ACK duplicado:


si el número de acks consecutivos duplicados es menor que 3, no haga nada
en cambio si el número de acks consecutivos es igual a 3, pase al estado de
FastRetransmit de Fast Retransmission/Recovery

TCP Vegas
Con la recepción de un nuevo ACK:

si cnwd =< ssthresh
1. cwnd ++ una vez por medio
2. envíe la ventana disponible.
 en cambio si cnwd > ssthresh, pase a congestión Avoidance para
procesamiento del ACK
Con la recepción de un ACK duplicado:


si el número de acks consecutivos duplicados es menor que 3, no haga nada
en cambio si el número de acks consecutivos es igual a 3, pase al estado de
FastRetransmit de Fast Retransmission/Recovery
Como se observa, slow start en Vegas incrementa la ventana de congestionamiento mas
lentamente que Reno al incrementar cwnd una vez por medio en vez de hacerlo con el
arribo de cada ack.
3.5.2 Congestion Avoidance

TCP Reno
Con la recepción de un nuevo ACK:
1. cwnd += 1/cwnd
2. envíe la ventana disponible
Con la recepción de un ACK duplicado:


si el número de acks consecutivos duplicados es menor que 3, no haga nada
en cambio si el número de acks consecutivos es igual a 3, pase al estado de
FastRetransmit de Fast Retransmission/Recovery

TCP Vegas
El algoritmo de TCP Vegas será descrito en detalle en el capítulo siguiente. Aquí solo
expondremos los pasos del algoritmo en la etapa de congestion avoidance.
Con la recepción de un nuevo ACK:
1.
2.
3.
4.
5.
Si el RTT medido es menor a base_rtt establezca base_rtt=RTT.
Calcule diff=cwnd-cwnd*(base_rtt/RTT)
Si diff<alfa incremente cwnd en una unidad
En cambio si diff>beta reduzca cwnd en una unidad
envíe la ventana disponible
Con la recepción de un ACK duplicado:


si el número de acks consecutivos duplicados es menor que 3, no haga nada
en cambio si el número de acks consecutivos es igual a 3, pase al estado de
FastRetransmit de Fast Retransmission/Recovery.
3.5.3 Fast Retransmit / Fast Recovery
El protocolo de ventana corrediza del TCP permite la recepción de paquetes fuera de
secuencia en el eventual caso de la pérdida de uno de ellos. Con la recepción de un
paquete fuera de orden, el TCP reconoce el último paquete que le llegó bien. En el lado
transmisor, al recibir tres acks duplicados (4 acks consecutivos iguales ) se pasa el
control al estado de Fast Retransmit, donde se actualizan algunas variables y se
retransmite el segmento perdido de inmediato. Luego de esto, se pasa a la fase de Fast
Recovery hasta que se reciba un nuevo reconocimiento, momento en el cual se pasa el
control a congestion Avoidance. El algoritmo es como sigue:
Fast Retransmit:
1. ssthtresh = max (snd_wnd/2,2)
2. retransmita el segmento perdido
3. candy = setters +3
Con la recepción de un ACK duplicado:


cwnd ++
envíe la ventana disponible
Con la recepción de un nuevo ACK:
1. Establezca cwnd = ssthresh
2. Pase el control a congestión Avoidance para procesamiento del ACK
3.6 Gestión de la ventana de recepción y generación de acks
Muchas versiones del TCP retardan los acks a la espera ya sea de nuevos datos desde la
aplicación para enviar junto con los acks (piggybacking), o de mas datos del transmisor
para enviar acks que resuman la secuencia completa de paquetes. En esta versión del
TCP no ocurren ninguna de esta dos funciones, y el TCP envía un ack no bien recibe un
paquete desde la entidad transmisora. Además, una entidad TCP en el caso del presente
simulador, solo puede ser transmisor o receptor pero no ambos a la vez. Los hosts que
posean generadores de tráfico serán las entidades TCP transmisoras y abrirán la
conexión con el receptor. Si el receptor también contiene generadores de tráfico, este
abrirá una nueva conexión aunque el destino de los paquetes sea el host que le esta
enviando datos también.
Como ya se mencionó, se supone que la aplicación del lado receptor mantiene el buffer
del mismo en el estado que este indicó al establecer la conexión, es decir, la variable
rwnd, que indica el tamaño de la ventana anunciada por el receptor, se mantendrá en el
valor establecido en la etapa de establecimiento de la conexión.
3.7 La interfaz gráfica con el usuario
Terminada la descripción del TCP implementado en el simulador, pasamos a describir
la interfaz con la cual interactuará el usuario para crear un agente TCP en el simulador
EasySim. La figura 3.1 muestra la ventana que aparece en la interfaz gráfica del
simulador una vez que el usuario selecciona el panel de Agentes en la configuración de
un host. En el ejemplo, el usuario seleccionó un agente TCP Vegas para el host. Los
parámetros configurables por el usuario para el TCP son los que aparecen en la figura,
donde se indican además los valores por defecto asignados por el sistema.
Figura 3.1 Selección de un agente de transporte
3.8 Los threads del simulador
El simulador EasySim esta escrito en lenguaje Java. Muchas de la clases definidas en el
sistema heredan de la clase thread del API de Java haciendo que la ejecución de las
mismas compartan tiempo de CPU. Sin la ayuda de estos threads, sería imposible lograr
el comportamiento correcto de ciertas clases del sistema. Los threads permiten que un
único proceso sea llevado a cabo mediante varios hilos de ejecución ejecutándose
paralelamente, simulando la presencia de varios procesadores en el sistema. Lo que se
hace en realidad es compartir tiempo de CPU entre los diferentes threads del proceso.
Por citar un ejemplo, los generadores de tráfico del sistema necesitan estar
continuamente generando paquetes y no pueden esperar la ejecución de otra tareas por
parte del procesador para seguir adelante. Todos los generadores del sistema heredan de
una clase abstracta Generador que a su vez hereda de Thread convirtiéndola en un hilo
de ejecución en el sistema y logrando el comportamiento requerido.
La inclusión de threads en el sistema hace que el procesador reparta su tiempo entre
todos ellos. Cuanto mas threads hallan sido creados mas lentamente evolucionará el
simulador. De cara a lo anterior, se incluyó la opción “El agente siempre tiene datos
para enviar” para los agentes TCP, como se observa en la figura 3.1. Lo que le estamos
diciendo al sistema al seleccionar esta opción es que apague todos los generadores de
tráfico y suponga que el buffer de transmisión siempre tiene datos para enviar. Lo único
que debe hacer el TCP ahora es formar paquetes de tamaño seg_size y enviarlos a la
cola de salida del host. De esta forma estamos reduciendo el número de threads en el
sistema logrando mayor velocidad de simulación. Por supuesto, si el usuario requiere
que halla una aplicación entregando paquetes al TCP, no tiene mas que seleccionar el
modelo de tráfico de la misma y desactivar esta opción.
4 Los agentes de transporte TCP Reno y TCP Vegas
4.1 Mecanismo de control de congestión
Con el objetivo de lograr un uso eficiente de la red, TCP controla el flujo entregado a la
misma mediante realimentación. Para controlar el flujo entregado, TCP necesita estimar
el ancho de banda disponible usando alguna forma de estimación del ancho de banda.
La gran diferencia entre Reno y Vegas es la forma en que se estima este ancho de banda
disponible.
4.1.1 TCP Reno
TCP Reno utiliza la pérdida de paquetes para estimar el ancho de banda disponible.
Mientras no halla pérdida de paquetes, TCP Reno continúa incrementando su ventana
de congestionamiento en cada round trip time. Cuando experimenta pérdida de
paquetes, este reduce su ventana a la mitad de su valor actual. Este mecanismo es
conocido como additive increase and multiplicatiuve decrease. Este mecanismo resulta
útil para estimar el ancho de banda, pero como veremos luego, esto causa una oscilación
periódica en el tamaño de la cola debido a la constante actualización de la ventana. Esta
oscilación en el tamaño de la ventana causa oscilación en el round trip delay de los
paquetes. Esta oscilación, a su vez, resulta en un gran jitter y un uso ineficiente del
ancho de banda disponible debido a las muchas retransmisiones del mismo paquete
cuando ocurren los drops en la colas.
La velocidad con que cada conexión actualiza su ventana depende del round trip delay
de la conexión.. Por lo tanto, las conexiones con retardo mas cortos actualizarán sus
ventanas mas rápido que aquellas con retardos mas largos, y por lo tanto obtendrán la
mayor parte del ancho de banda disponible. TCP Reno es injusto con las conexiones con
round trip delays grandes.
4.1.2 TCP Vegas
TCP Vegas adopta una forma mas sofisticada de estimación del ancho de banda. Usa la
diferencia entre el flujo esperado y el actual para estimar el ancho de banda disponible
en la red.. La idea es que cuando la red no esta congestionada, el flujo actual estará
cerca del flujo esperado. De otra forma, el flujo actual será mas pequeño que el flujo
esperado. TCP Vegas usa la diferencia en los flujos, estima el nivel de congestión de la
red, y actualiza su ventana de acuerdo a lo anterior. Note que esta diferencia en los
flujos puede ser fácilmente trasladada a la diferencia del tamaño de la ventana y el
número de paquetes reconocidos durante un round trip time, usando la ecuación
Diff  Expected ActualBaseRTT (4.1)
donde Expected es el flujo esperado, Actual es el flujo actual, y BaseRTT es el mínimo
round trip time. Los detalles del algoritmo son como sigue:
CWND
, donde
BaseRTT
CWND es el tamaño actual de la ventana y BaseRTT es el mínimo round trip
time.
2. Segundo, la fuente estima el flujo actual usando el actual round trip time de
CWND
acuerdo a Actual 
, donde RTT es el actual round trip time de cada
RTT
paquete.
3. La fuente, usando los flujos actual y esperado, calcula el tamaño esperado de la
cola a partir de la ecuación (4.1).
4. Basado en Diff, la fuente calcula su tamaño de ventana como sigue
1. Primero, la fuente calcula el flujo esperado Expected 
CWND  1, si Diff  

CWND  CWND  1, si Diff  
CWND , en otrocaso

(4.2)
Figura 4.1. Control de ventana de TCP Vegas
La figura 4.1 ilustra el comportamiento de TCP Vegas. Considere un red simple con una
única conexión y un solo enlace de capacidad C. Sea BaseRTT el mínimo round trip
window
delay. El throughput de esta conexión es
cuando window  C  BaseRTT .
BaseRTT
En la figura, w corresponde al tamaño de la ventana cuando window  C  BaseRTT .
Cuando window  w , la cola comienza a crecer y Expected Actual  0 . TCP Vegas
incrementa el tamaño de la ventana en uno durante el siguiente round trip time si
window  w   y la decrementa en uno si window w   . De otra manera deja la
ventana incambiada. En la figura, Diff es el tamaño de la cola del enlace estimado por
el usuario (la conexión). TCP Vegas intenta mantener la cola del enlace con al menos 
paquetes pero no mas de  .
Note que el mecanismo utilizado por TCP Vegas es radicalmente diferente al usado por
TCP Reno. TCP Reno siempre actualiza su tamaño de ventana para garantizar una
completa utilización del ancho de banda disponible, incurriendo en una constante
pérdida de paquetes, mientras que TCP Vegas no causa ninguna oscilación en el tamaño
de la ventana, con la cual converge a un punto de equilibrio.
4.1.3 Simulación con EasySim. Caso de colas Drop Tail
En esta sección, verificaremos mediante simulación, los resultados de las secciones
anteriores. En concreto, contrastaremos el comportamiento de la cola del enlace crítico
de la figura 4.2 cuando las conexiones son TCP Reno y cuando las mismas son TCP
Vegas. Usaremos en esta instancia, colas del tipo Drop Tail, es decir, aquellas en donde
se producen descarte de paquetes solo cuando las misma alcanza el estado de overflow.
Figura 4.2. Topología de red usada para la simulación.
Las cuatro conexiones TCP de la figura, comparten un único enlace L5. De esta forma,
la cola de dicho enlace creará el cuello de botella de la red.
Los valores de los parámetros seleccionados para la red de la figura 4.2 fueron los
siguientes:






Enlaces L1 a L4: 10 Mbps y 20 mseg de retardo de propagación
Enlace L5: 5 Mbps y 80 mseg de retardo de propagación
Tamaño de la cola de los enlaces L1 a L4: infinita
Tamaño de la cola del enlace L5: 100 paquetes, Drop Tail.
Tamaño de segmento TCP: 1500 bytes
Tiempo de simulación: 50 segundos
La figura 4.3 muestra el buffer en función del tiempo para el caso de TCP Reno.
Observamos de dicha figura las oscilaciones producidas en la cola debido a la constante
actualización de la ventana del TCP Reno. Al llegar el buffer a 100 paquetes, comienza
a descartarlos, haciendo que las conexiones TCP reduzcan su ventana de
congestionamiento drásticamente3. Al hacerlo todas a la vez, se producen las
oscilaciones observadas. Esto se conoce como sincronización global, y el efecto es
mitigado por TCP Vegas como se observa en la figura 4.4. También se puede mitigar el
efecto de las oscilaciones si se introduce el mecanismo de control de congestión RED en
la cola del cuello de botella.
1
3
3
La reducción de la ventana depende de si la perdida del paquete es detectada por un time out o por
la llegada de un triple ack duplicado. En el primer caso, la ventana de congestionamiento se reduce a
un segmento, mientras que en caso de triple acks, esta se reduce a la mitad de la ventana de
congestionamiento actual mas tres segmentos.
Figura 4.3. Buffer vs tiempo para la cola del enlace crítico cuando las conexiones son TCP Reno.
Como se mencionó en la sección 4.1.2, TCP Vegas intentará mantener la cola del enlace
crítico entre  y  paquetes. Estos parámetros son seleccionables por el usuario en
EasySim, como lo muestra la figura 3.1. Para la topología de la red de la figura 4.1 y
para el caso de conexiones TCP Vegas, se seleccionaron   5 y   6 . Cada conexión
TCP Vegas entonces, intentará mantener la cola del enlace L5 entre dichos valores.
Como resultado, la cola del enlace será forzada a mantenerse entre 20 y 24 paquetes ( la
suma de cada conexión). Este resultado se aclara en al sección que sigue. La figura 4.4
muestra como al usar conexiones TCP Vegas, la cola del enlace se amortigua
rápidamente a un valor entre 20 y 21 paquetes verificando así los resultados teóricos. De
esta forma se eliminan las oscilaciones, mejorando la performance de cada conexión,
utilizando el ancho de banda disponible mas eficientemente.
Figura 4.4. Buffer vs tiempo para la cola del enlace crítico cuando las conexiones son TCP Vegas.
4.1.3.1 El retardo de propagación elegido
Con los valores seleccionados para los enlaces, se tiene un round trip delay de 200
mseg, 20  80  2 para cada conexión TCP. Tanto en TCP Vegas como en Reno, una
pérdida de paquete es encontrada ya sea por un time out o por la llegada de un triple ack
duplicado. En el primero de los casos, el TCP reduce su ventana de congestionamiento a
un segmento, y en el segundo a la mitad de la ventana actual mas tres segmentos. Para
que la pérdida de un paquete sea detectada por un triple ack, es necesario que haya una
cantidad suficiente de paquetes en tránsito para esa conexión, de manera que el receptor
TCP reciba una secuencia de acks consecutivos luego de la pérdida de un paquete y
reconozca de esa forma el último correcto de la secuencia. Si la red no alberga la
cantidad suficiente de paquetes, el transmisor deberá esperar un time out para
retransmitir el paquete perdido degradando la ventana de congestionamiento a un
segmento cada vez que se pierda un paquete.
Con la finalidad de detectar la mayoría de las perdidas de paquetes por triple acks, se
eligió un retardo de propagación de ida y vuelta de 200 mseg, de manera que
cantidadde paquetesen transito 

velocidaddel enlacecritico(paq/seg)
round tripdelay
5e 6
 200e 3  83.33 paquetes
1500 8
En promedio, cada conexión tendrá en todo momento 20.83 (83.33/4) paquetes en
tránsito, de manera de poder detectar la pérdida de un paquete por la llegada un triple
ack duplicado, y de esa forma, no degradar demasiado la conexión.
4.2 Imparcialidad de TCP Vegas
Como mencionamos antes, TCP Reno beneficia a las conexiones con cortos round trip
delays. En esta sección demostraremos que TCP Vegas es imparcial con las conexiones
con retardos cortos y largos, analizando un simple modelo de fluidos. Asumiremos que
los paquetes son infinitamente divisibles, es decir, usaremos un modelo de fluidos, y el
retardo de propagación será determinístico.
Considere el modelo de la figura 4.5. Hay dos usuarios con diferentes round trip delays,
que comparten un mismo cuello de botella. El usuario i tiene un round trip delay d i y
ejecuta un control de flujo basado en ventana. Sea qi (t ) el tamaño de la cola del usuario
i en el tiempo t. Sea ahora rtt i (t )  wq (t )  di el retardo ida y vuelta de la conexión i en
el tiempo t, donde wq (t ) es el retardo en la cola del cuello de botella. Asumimos que la
cola es FIFO, y que tiene buffer infinito. Suponga que ei (t ) denota la velocidad con que
el usuario i recibe los acks.
Figura 4.5. Red con dos usuarios
Los usuarios actualizan sus ventanas una vez durante cada round trip time. Ya que el
tamaño de la ventana es igual a la suma de la cantidad de fluido en tránsito mas lo que
hay en la cola:
wi (t )  qi (t ) 
t  di
 e (s)ds
i
(4.3)
t
Note que el segundo termino de la ecuación (4.3) es la cantidad de fluido en tránsito en
el tiempo t. Cada fuente estima la cantidad de paquetes en la cola usando la diferencia
entre los flujos esperado y actual.. Por lo tanto, la cantidad estimada de fluido en la cola
en el tiempo t para el usuario i es
t
t
 w (t )

1
d  w (t )  di
Diffi   i 
e
(
s
)
ds
ei ( s)ds (4.4)
i
i
i


 di

rtt
(
t
)
rtt
(
t
)
i
i
t  rtt i ( t )
t  rtt i ( t )


Al cabo de un tiempo t o , la cantidad anterior convergerá a un valor tal que:
t
d
  wi (t )  i
ei ( s )ds   (4.5)
rtti (t ) t  rtti (t )
Ahora suponga que la ventana satisface la ecuación (4.5). Si sustituimos (4.3) en (4.5)
tenemos que
  qi (t ) 
t  di
 ei (s)ds 
t
t
di
ei ( s )ds   (4.6)
rtti (t ) t  rtti ( t )
Una vez que las fuentes satisfacen (4.5) ya no cambian mas sus ventanas. Suponga que
el sistema es cuasi estático y ei (t ) es relativamente constante. Entonces el segundo y
tercer termino de (4.6) se cancelan dando
  qi (t )   (4.7)
Note que bajo las hipótesis de sistema cuasi estático, el tamaño de la cola de cada
conexión no depende del retardo de propagación d i , eliminando el favoritismo hacia las
conexiones con retardos de propagación mas cortos del TCP Reno. Ya que la cola es
FIFO, el throughput de cada conexión es directamente proporcional al tamaño de la cola
del cuello de botella. Cada conexión entonces obtiene el mismo throughput
independientemente del su retardo de propagación.
Las conexiones con retardo de propagación mas largos deberán tener una ventana
mayor, a los efectos de mantener mas fluido en tránsito, manteniendo la misma cantidad
de paquetes en la cola que la conexión con retardo mas corto, obteniendo así el mismo
throughput.
4.2.1 Resultados de simulación
En esta sección intentaremos verificar mediante simulación con EasySim, los resultados
de la sección anterior. La red a analizar será la de la figura 4.6. En ella, el host H1 envía
paquetes al H3, y el H2 envía hacia H4. El retardo de propagación ida y vuelta para H1
vale 100 mseg, y para H2 lo hacemos variar desde 160 mseg hasta 300 mseg variando el
retardo del enlace L5.
Figura 4.6. Dos conexiones TCP con diferentes retardos de propagación
A la luz de la sección anterior, mediremos el throughput de cada conexión a través de la
cantidad de acks recibidos por cada una de ellas en la ventana de tiempo de simulación.
Tabla 4.1. Conexiones Reno
Tabla 4.2. Conexiones Vegas
Los valores seleccionados para los parámetros fueron:







Links L1, L2, L4 y L5: 10 Mbps
Link L3: 1.5 Mbps
Retardo de propagación de la conexión 1 (H1 y H3): 100 mseg
Retardo de propagación de la conexión 2 (H2 y H4): 160, 200, 230, 260 y 300
mseg.
Tamaño de las colas: Lo suficientemente grande para no ocurrir desbordes.
Tamaño de segmento: 1500 bytes
Para TCP Vegas:   2 y   3
La tabla 4.1 muestra la relación de throughputs para ambas conexiones en la ultima
columna cuando las conexiones son TCP Reno. Los acks1 son los recibidos por la
conexión con retardo mas corto (H1 y H3). Observamos que esta relación crece
linealmente conforme aumentamos el retardo de propagación de la otra conexión (H2 y
H4), confirmando el favoritismo hacia las conexiones con retardos cortos del TCP
Reno.
La tabla 4.2 corresponde a los resultados de la simulación de la misma red, pero esta vez
con conexiones TCP Vegas en los hosts. Se observa que la relación de throughputs es
mucho mas pareja para ambas conexiones, sin importar el retardo de propagación de las
mismas, como lo habíamos anticipado.
4.3 Incompatibilidad entre Vegas y Reno
En las secciones anteriores hemos demostrado que TCP Vegas generalmente permite
mejorar la performance de una conexión, utilizando mejor el ancho de banda disponible
en la red. Sin embargo, cuando una conexión Vegas comparte un enlace con una
conexión Reno, esta ultima resulta quedarse con la mayor parte del ancho de banda
disponible, debido al mecanismo de control de congestión conservativo de TCP Vegas.
TCP Reno continúa incrementando su ventana mientras no ocurran perdidas de
paquetes. Los paquetes se pierden principalmente por overflows en las colas. Este
mecanismo de estimación del ancho de banda resulta en una oscilación periódica del
tamaño de la ventana y llenado del buffer, como vimos en la sección 4.1.1 y
confirmamos mediante simulación en la sección 4.1.3. Por lo tanto, mientras TCP
Vegas intenta mantener el tamaño de la cola en unos pocos paquetes, TCP Reno
mantiene muchos mas paquetes en la cola, en promedio, quedándose con la mayor parte
el ancho de banda disponible.
Sea qv (t ) y q r (t ) la cantidad de paquetes en la cola del enlace crítico en el tiempo t, de
las conexiones Vegas y Reno respectivamente, y sea B el tamaño del buffer. Si
asumimos que qv (t )  k   , q r (t ) toma valores entre 0, B  k . Asumamos que q r (t )
se distribuye uniformemente en ese intervalo. La cantidad promedio entonces de
Bk
paquetes de Reno en la cola es q r 
. La relación entre el throughput de Reno y el
2
Bk
de Vegas es entonces,
. Cuando B es relativamente grande, que es usualmente el
2k
caso, entonces es obvio que TCP Reno consigue la mayor parte del ancho de banda
disponible. Estos resultados serán verificados mediante simulación con EasySim en la
sección que sigue.
El mecanismo de control de congestión de TCP Reno es agresivo en el sentido que deja
poco espacio en el buffer para las otras conexiones, mientras que TCP Vegas es mas
conservativo manteniendo pocos paquetes en el buffer. Cuando una conexión TCP Reno
comparte un enlace con TCP Vegas, Reno utiliza mas espacio de buffer que Vegas, y
esta ultima reconoce esto como una señal de congestión bajando el tamaño de su
ventana de congestionamiento. Esta es una razón por la cual TCP Vegas no ha sido
ampliamente desarrollada, además de otras propiedades indeseables que posee.
4.3.1 Simulación con EasySim
El objetivo de esta sección será verificar los resultados de la sección anterior mediante
simulación con EasySim. Otra vez, mediremos el throughput de cada conexión a través
de la cantidad de acks recibidos durante el transcurso de la simulación. La topología a
simular será la de la figura 4.6. El retardo de propagación para ambas conexiones se fijó
en 260 mseg. , los valores para Vegas,   1 y   3 , y los demás valores idénticos a la
simulación anterior. Además, ahora el tamaño del buffer del cuello de botella se fue
cambiando desde 10 a 50 paquetes.
Tabal 4.3 Resultados de la simulación
La tabla 4.3 verifica los resultados de la sección anterior. Cuanto mayor sea el tamaño
del buffer del cuello de botella, mayor será la disparidad entre los throughputs de las
conexiones Reno y Vegas, obteniendo esta última la parte mas pequeña del ancho de
banda disponible de la red. Cuanto mas grande sea el buffer, mas espacio tendrá Reno
para colocar sus paquetes aumentando su ventana de congestionamiento en cada RTT.
Por otro lado, al crecer la cantidad de paquetes en la cola, crece también el retardo que
los paquetes experimentan en la misma, wq , lo que hace crecer el RTT, con lo cual hace
que TCP Vegas decremente su ventana de congestionamiento.
La última columna de la tabla indica el intervalo en el que debe caer la relación de
throughputs, según la estimación anterior para la cantidad promedio de paquetes de
Reno en la cola. En todos los casos, se verifican los resultados de la sección anterior. El
tiempo de simulación usado fue de 100 seg.