Asignación Nº 06

1. Desarrollar los siguientes algoritmos de control de la congestión en TCP

(descripción ó características, diagramas que muestren la operación de cada
algoritmo, etc.):

a. Arranque lento (Slow start).

Descripción: Es un algoritmo de control de congestión del protocolo TCP. Que sirve

para el cálculo de la ventana de congestión aplicado al principio de la conexión, y
hasta que se alcanza el umbral de congestión. Consiste en lo siguiente:
La ventana de congestión se inicia con el valor de un segmento de tamaño máximo
(MSS). Cada vez que se recibe un ACK, la ventana de congestión se incrementa en
tantos bytes como hayan sido reconocidos en el ACK recibido. En la práctica, esto
supone que el tamaño de la ventana de congestión se doble por cada RTT, lo que
da lugar a un crecimiento exponencial de la ventana.
Cuando un ACK no llega al transmisor: Se toma como una señal de congestión en la
red y se reinicia la ventana de congestión a un MSS.

Funcionamiento: El algoritmo slow-start entra en funcionamiento en la fase más

temprana del establecimiento de una conexión TCP. Una vez que se setean los
buffers de transmisión en los dos extremos, el algoritmo hace uso de dos variables
cwnd (ventana de congestión), un límite a los segmentos que se envían en cada RTT
antes de recibir los ACK correspondientes, y ssthresh (slow start umbral), punto a
partir del cual dejará de auto limitarse la ventana de envío.

Cuando se inicia una conexión TCP, el valor de la ventana de congestión se inicializa

con un valor pequeño igual a 1 MSS que da como resultado una velocidad de
transferencia inicial aproximadamente igual a MSS/RTT Por ejemplo si MSS=500
bytes y RTT=200 ms, la velocidad de transmisión inicial será aproximadamente de
20 kbps. Puesto que el ancho de banda disponible para el emisor TCP puede ser
mucho más grande que el valor de MSS/RTT, el emisor TCP le gustaría poder
determinar rápidamente la cantidad de ancho disponible. Por tanto, en el estado
de arranque lento, el valor de la ventana de congestión se establece en 1 MSS y se
incrementa cada vez que se produce el primer reconocimiento de un segmento
transmitido. De la figura1, TCP envía el primer segmento a la red y espera el
correspondiente paquete ACK. Cuando llega dicho paquete de reconocimiento, el
emisor TCP incrementa el tamaño de la ventana de congestión en 1 MSS y transmite
dos segmentos de tamaño máximo. Estos segmentos son entonces reconocidos y el
emisor incrementa el tamaño de la ventana de congestión en 1 MSS por cada uno
de los segmentos reconocidos, generando una ventana de congestión de 4 MSS,
etc. Este proceso hace que la velocidad de transmisión se duplique en cada periodo
RTT. Por tanto, la velocidad de transferencia inicial de TCP es baja, pero crece
exponencialmente durante esa fase de arranque lento.
Pero, ¿Cuándo debe finalizar este crecimiento exponencial? El algoritmo del
arranque lento proporciona varias respuestas a esta cuestión. En primer lugar, si se
produce un suceso de pérdida de paquete (es, decir si hay congestión) señalado por
un fin de temporización, el emisor TCP establece el valor de la ventana de
congestión en 1 e inicia de nuevo un proceso de arranque lento. También define el
valor del segunda variable de estado que establece el umbral de arranque lento y
 que denominaremos umbral en ventanacongestion/2, la mitad del valor del tamaño
de la ventana de congestión cuando se ha detectado que existe congestión. La
segunda forma en la que la fase de arranque lento puede terminar esta
directamente ligada al valor del umbral. Dado que el umbral es igual a la mitad del
valor que la ventanacongestion tenía cuando se detectó congestión por última vez.
Puede resultar algo imprudente continuar duplicando el valor de la
ventanacongestion cuando se alcanza o sobrepasa el valor del umbral. La fase de
arranque lento termina y las transmisiones TCP pasan al modo de evitación de la
congestión. Como veremos, TCP incrementa con más cautela el valor de la
ventanacongestion cuando está en el modo en el modo evitación de la congestión.
La última forma en la que puede terminar la fase de arranque lento es si se detecta
tres paquetes ACK duplicados, en cuyo caso TCP realiza un retrasmisión rápida y
entra al estado de recuperación rápida.

l
Figura 1: Fase de Arranque Lento TCP.

b. Evitación de la congestión (Congestion avoidance).

Descripcion: 'Congestion avoidance' es el otro algoritmo que el emisor TCP
utiliza para controlar la cantidad de datos que están siendo inyectados en la
red. La suposición del algoritmo de que una pérdida de paquete es causada
por daño es muy pequeña (muy inferior al 1%). De esta manera, la pérdida
de paquete indica que hay congestión en algún punto de la conexión entre
emisor y receptor.
'Congestion avoidance' y 'slow start' son algoritmos independientes con
diferentes objetivos, pero cuando aparece congestión, TCP debe reducir el
ratio de paquetes transmitidos a la red e invocar 'slow start' para normalizar
la situación de nuevo. En práctica, ambos son implementados juntos.

Funcionamiento: Al entrar en el estado de evitación de la congestión, el

valor de la ventanacongetion es aproximadamente igual la mitad de su valor
en el momento en que se detectó congestión por última vez (podemos estar,
por tanto, la borde de la congestión). En consecuencia, en lugar de duplicar
el valor de la ventanacongestion para cada RTT, TCP adopta un método más
conservador e incrementa el valor de la ventanacongetion solamente en un
MSS cada RTT. Esto puede llevarse acabo de varias maneras. Un método
habitual consiste en que un emisor TCP aumenta el valor de
ventanacongestion en MSS bytes (MSS/ventanacongestion) cuando llega un
nuevo paquete de reconocimiento. Por ejemplo, si MSS es igual a 1460 bytes
y ventanacongestion es igual a 14600 bytes, entonces se enviara 10
segmentos en un RTT. Cada ACK que llega (suponiendo un ACK por
segmento) incrementa el tamaño de la ventana de congestión en 1/10 MSS
y, por tanto, el valor del tamaña de la ventana de congestión habrá
aumentado en un MSS después de los ACK correspondientes a los 10
segmentos que hayan recibido.
Pero, ¿en qué momento debería detenerse el crecimiento lineal (1 MSS por
RTT) en el modo de evitación de la congestión? El algoritmo de evitación de
la congestión de TCP se comporta del mismo modo que cuando tiene lugar
un fin de temporización. Como en el caso del modo de arranque lento, el
valor de ventancongestion se fija en 1 MSS y el valor de umbral se actualiza
haciéndose igual a la mitad del valor de ventanacongestion cuando se
produce un suceso de pérdida de paquete. Sin embargo, recuerde que
también puede detectarse una pérdida de paquete a causa de la llegada de
tres ACK duplicados. En este caso, la red continúa segmentos de emisor al
receptor (como se señala ña recepción d paquetes ACK duplicados). Por
tanto, el comportamiento de TCP ante este tipo de pérdida debería ser
menos drástico que ante una pérdida de paquete indicada por un fin de
temporización: TCP divide entre dos el valor de la ventanacongestion
(añadiendo 3 MSS como forma de tener en cuenta los tres ACK duplicados
que se han recibido) y configura el valor de umbral para que sea igual a la
mitad del valor que ventanacongestion tenía cuando se recibieron los 3 ACK
duplicados. A continuación, se encuentra en el estado de recuperación
rápida.
c. Retransmisión rápida (Fast retransmit).
Descripción: Este algoritmo de retransmisión rápida fue propuesto en 1990
por Van Jacobson como mejora de TCP. Su objetivo es acelerar la
retransmisión de segmentos de datos perdidos si se dan ciertas
circunstancias. Como sabemos, en el protocolo TCP podría darse la
posibilidad de que se produzcan pérdidas frecuentes y, por tanto, que el
receptor reciba un determinado segmento que no esperaba recibir en ese
orden, generando ante ello un ACK que es enviado al emisor para que éste
pueda percibir que el segmento en cuestión no ha llegado a su destino
correspondiente. Este hecho puede ser debido a dos motivos principales:
a) que el segmento se haya perdido.
 b) que se haya producido una reordenación de los segmentos en la red
por algún determinado motivo y el segmento en cuestión esté aún
pendiente de llegar y lo haga desordenadamente.

Ante esto, se espera un tiempo antes de volver a enviar todos los paquetes
de la ventana, porque es probable que se haya perdido un sólo paquete. Esto
evita muchos casos en que se duplicarían envíos innecesariamente y sólo se
retransmiten los paquetes que realmente no han llegado.

Funcionamiento: Si el motivo es el primero de los anteriormente

comentados, el emisor únicamente debería retransmitir ese segmento de
nuevo pero, si se produce el segundo caso, será cuestión de tiempo el hecho
de que el segmento llegue a su destino correspondiente, por lo que el emisor
no deberá proceder a la retransmisión a no ser que se cumpla el timeout
correspondiente.

La interpretación de TCP es que si el emisor recibe más de dos peticiones de

retransmisión del mismo segmento por parte del receptor, entonces
entiende que el segmento en cuestión no ha sufrido reordenación sino que
se ha perdido, ya que en caso de reordenación no se llegaría al par de
peticiones de retransmisión.

Entonces, podemos decir que si el emisor recibe tres ACK por parte del
receptor a modo de retransmisión de un segmento, el emisor entenderá que
se ha producido pérdida de datos (y no reordenación por tanto) y no ha de
esperar a que se cumpla el tiempo de timeout para volver a transmitir el
segmento en cuestión, sino que lo hace en ese determinado instante. Por
tanto, si el emisor recibe los ACK duplicados se retransmite el segmento
perdido sin esperar a que venza su temporizador, justificando el nombre del
algoritmo. Este comportamiento puede observarse en la siguiente figura que
muestra el algoritmo Fast Retransmit en acción.
d. Recuperación rápida (Fast recovery).
Descripción: Es un algoritmo implementado en las comunicaciones
mediante del protocolo TCP. Cuando el receptor recibe un segmento con un
número de secuencia que no corresponde, intuye que un segmento se ha
perdido. Por cada nuevo segmento que llega, vuelve a mandar el ACK
correspondiente al último segmento que recibió correctamente. Este
algoritmo de recuperación rápida entra en funcionamiento, principalmente,
en situaciones en las cuales la congestión de la red es más o menos
moderada y muy puntual y pudieran producirse a ráfagas sucesivas, con
tendencia a desaparecer de forma rápida. Ante este hecho, de desaparición
rápida de la congestión, puede que no compense bajar al mínimo el valor de
la ventana de congestión, cwnd, y entrar en acción el algoritmo ya visto de
Slow Start. En estas situaciones entra en funcionamiento el algoritmo que
nos ocupa.

Funcionamiento: La estrategia normal de recuperación de congestiones

hemos visto que son los algoritmos Slow Start y Congestion Avoidance, que
hemos visto que plantea una forma de evitar la congestión o dejar que se
recupere la red demasiado conservadora, porque hace descender al mínimo
el valor de la ventana de congestión y por tanto el rendimiento de la red. Van
Jacobson propone mejorar el throughput si se aplica Slow Start sólo cuando
se retransmite por timeout y no por 3 ACK duplicados.

El algoritmo entiende que cuando llega el tercer ACK duplicado de un mismo

segmento (por lo cual el emisor entiende que el paquete se ha perdido), se
establece el ssthresh a la mitad del valor de la ventana de transmisión CWND
tal y como hemos venido observando anteriormente, es decir:

ssthresh = máx ( current_window/2, 2 )

Sin embargo, no entra en escena el algoritmo Slow Start, sino que se

retransmite el segmento perdido como en Congestion Avoidance y se
establece la ventana de congestión como:
 cwnd = ssthresh + 3 * (tamaño del segmento)

Este 3 entra en escena puesto a que si han llegado 3 ACK del segmento en
cuestión es porque los segmentos consecutivos a éste han llegado a su
destino, siendo entonces el motivo de alarma que el receptor hace notar al
emisor sobre la pérdida del paquete.

Igualmente, podría darse el caso de que siguiesen llegando ACK relacionados

a la retransmisión de este segmento; es decir, mientras que realizamos la
operación de retransmisión podría haber segmentos en la red pendientes de
llegar a su destino y, ante esto, se incrementa la ventana de congestión por
cada uno de estos ACK, quedando cwnd como cwnd = cwnd + 1 paquete.
Esto ocurre hasta que el emisor recibe el ACK correspondiente al segmento
perdido en cuestión y retransmitido posteriormente, igualando justo en este
momento el tamaño de la ventana de congestión cwnd al tamaño del
ssthresh comentado anteriormente.

Con todo esto, podemos observar que se ha retransmitido el segmento

perdido mientras que seguíamos en Congestion Avoidance, sin tener que
entrar en Slow Start como se venía haciendo hasta ahora. Como hemos
mencionado anteriormente el ssthresh se reduce a la mitad del tamaño de
la ventana cwnd en el momento en que el emisor es consciente de la pérdida
del segmento.
La siguiente figura representa este comportamiento.
2. Graficar la FSM (Máquina de Estado Finito) de la operación en conjunto de estos
algoritmos para TCP Reno.
Suposiciones:
- rWnd >> cWnd.
- cada segmento es del mismo tamaño y acarrea MSS bytes.
- se ignora la política del ACK-retardado.
3. Resolver los ejercicios siguientes:

Ejercicios

1. Suponga que el Cliente A inicia una sesión Telnet con el Servidor S. En casi al
mismo tiempo, el Cliente B también inicia una sesión Telnet con el Servidor S.
Proveer posibles números de puerto fuente y de destino para:

Puerto fuente Puerto de destino

Los segmentos de AS 467 23
Los segmentos de BS 513 23
Los segmentos de SA 23 467
Los segmentos de SB 23 513

Nota: Asuma inicialmente que ambos clientes son hosts diferentes para el login
remoto. Considere también entornos como el SO UNIX, el login remoto.

¿Si A y B están en el mismo host, es posible que el # puerto fuente en los

segmentos de A a S sea el mismo que de B a S?
a. Si
b. No
c. No se sabe

2. Asuma que un flujo TCP usa WiFi con alta tasa de pérdidas. Asuma que algunos
paquetes son perdidos a pesar de retransmisiones WiFi. Entonces, cuando un
paquete es perdido en el enlace WiFi:
a. El emisor TCP conoce que la pérdida es una pérdida debido a errores del canal
y no a la congestión, por lo tanto no reduce la ventana.
b. El emisor TCP piensa que la pérdida es una pérdida por congestión y reduce su
ventana.
c. La pérdida depende si ECN es usada.
d. No se sabe.

3. TCP: Control de la Congestión: El personal de administración de red a su cargo, ha

obtenido el siguiente gráfico del flujo de TCP, Ud. concluye que el gráfico
corresponde a TCP Reno (i.e. TCP con Retransmisión Rápida y Recuperación
Rápida).
Asumir que el flujo TCP ha estado operando por algún tiempo, lo que significa que
el número RTT's mostrado son con respecto a cuándo su personal comenzó a
observar el flujo TCP.

3.1 Identificar los periodos de tiempo (en Número de RTT's) cuando Slow Start
de TCP está en operación.

Intervalos [1,6] U [22,25].

3.2 Identificar los periodos de tiempo (en Número de RTT's) cuando Evitación de
la Congestión está en operación.

Intervalos [6,14] U [15,21].

3.3 Después del 14o RTT, ¿el segmento perdido es detectados por un triple ACK
duplicado ó por un Timeout?

Ocurre un triple ACK duplicado.

3.4 ¿Cuál es el valor inicial de ssThresh, antes del 1er intervalo de Evitación de la
Congestión?

ssThresh = 32

3.5 ¿Cuál es el valor de ssThresh en el 19º RTT?

ssThresh = 20
3.6 ¿Cuál es el valor de ssThresh en el 24º RTT?

ssThresh = 12

3.7 Suponga que justo antes de completar el 26º RTT, 3 ACK's duplicados fueron
recibidos. ¿Cuáles son los valores de ssThresh y cWnd después del 3er ACK
duplicado?
Nota: El escenario es capcioso, tendrá que completar la ronda 26.

ssThresh = 12
cWind = 8