Comportamiento de la ventana de control de la congestión

En la Fig 3.1.2 muestra el comportamiento del algoritmo de control de congestión de

TCP Tahoe, presenta un esquema de control de congestión usando Fast Recovery. Tahoe

comienza con ventana de 1xMSS y crece exponencialmente a 65535, en 72522 ocurre una caída de paquetes y empieza la fase de slow start reduciendo la ventana de congestión a la

1xMSS e incrementando nuevamente el tamaño de la ventana exponencialmente. La gráfica de múltiples pérdidas de paquetes es similar al de una sola pérdida por lo que una vez que Tahoe encuentra triple dack comienza con la fase de slow start, la ventana de congestión no

crece a menos que llegue un nuevo ack.

1

2 3

Fig 3.1.2 Gráfica de la ventana de congestión en TCP Tahoe con una pérdida de paquete.

CAPÍTULO 3. RESULTADOS Y DISCUSIÓN

22

TCP Reno usa los algoritmos de control de congestión fast recovery, fast retransmit, en la

Fig 3.1.3 se observa que después de que se pierde el paquete (punto 1) en aproximadamente

1.47 seg. Reno entra en la fase fast recovery en lugar de slow start, por lo tanto el tamaño

de la ventana se reduce a la mitad en lugar de 1 (punto 2), probando así que TCP Reno toma una acción menos agresiva y evita que se vacié el canal de comunicación y por lo tanto mejora la razón de transferencia.

1

2

Fig 3.1.3 Gráfica de la ventana de congestión en TCP Reno. Pérdida de una ráfaga conteniendo un solo segmento de un mismo flujo con TCP

Reno.

En la Fig 3.1.4 se muestra la ineficiencia que tiene Reno en el caso de pérdidas de ráfagas

conteniendo dos o más segmentos de un mismo flujo TCP.

Cuando se pierde una ráfaga que lleva dos o más segmentos de un mismo flujo, pueden darse dos escenarios posibles para la detección de la pérdida. Si la ventana de transmisión tiene un tamaño mayor o igual que el número de segmentos perdidos más tres, entonces el emisor acabará recibiendo tres asentimientos duplicados, detectando así la pérdida. Si la ventana de transmisión no alcanza dicho valor, entonces vencerá el temporizador de retransmisión.

CAPÍTULO 3. RESULTADOS Y DISCUSIÓN

23 En el caso de TCP Reno, tras producirse la pérdida (punto1), el emisor va a retransmitir el segmento, y va a reducir la ventana de congestión a la mitad más tres segmentos (punto 2). A medida que van llegando nuevos asentimientos duplicados, la ventana de congestión se va incrementando en un segmento (punto 3). Sin embargo, no puede enviar nuevos segmentos, ya que la ventana de transmisión es superior a la ventana de congestión, ya que tiene almacenados todos los segmentos que se han enviado después de la pérdida. A continuación, llega el asentimiento del primer segmento perdido, que ha sido generado tras la recepción del segmento retransmitido, y la ventana de congestión se reduce (punto 4). La ventana de transmisión en este punto, con el número de segmentos que hay en tránsito, no permite el envío de ningún segmento, por lo tanto el emisor permanece inactivo hasta que vence el temporizador de retransmisor asociado al segundo segmento perdido (punto 5), momento en el que se retransmite el segmento y se vuelve a show start.

1

3

4 2

5

Fig 3.1.4 Gráfica de la ventana de congestión en TCP Reno con dos pérdidas

de paquetes conteniendo dos segmentos de un mismo flujo con TCP Reno. Evolución del tamaño de la ventana de congestión.

En el caso de Sack (Fig 3.1.5), tras la pérdida de paquete (punto 1), cuando llegan los tres

asentimientos duplicados (punto 2), se reduce la ventana a la mitad del número de segmentos en tránsito y se retransmite. A continuación van llegando más asentimientos duplicados (punto 3). Un RTT más tarde del envío del segmento retransmitido, llega el

CAPÍTULO 3. RESULTADOS Y DISCUSIÓN

24 asentimiento que confirma su recepción, con lo que se continúa creciendo con congestion avoidance (punto 4).

TCP Sack usa ACKs selectivos y retransmisiones selectivas lo cual mejora el desempeño ya que los timeouts ocurren después que en las otras versiones de TCP.

1

2

3 4

Fig 3.1.5 Gráfica de la ventana de congestión en TCP Sack. Pérdida de ráfagas conteniendo un solo segmento de un mismo flujo con TCP Sack.

En el caso de Sack (Fig 3.1.6), tras la pérdida de la ráfaga que lleva dos segmentos del

flujo considerado (punto 1), cuando ocurre la detección de los tres asentimientos

duplicados, se reduce la ventana a la mitad del número de segmentos en tránsito (punto 2). A medida que llegan los asentimientos duplicados con información de asentimientos selectivos, la variable pipe se va actualizando pero la ventana de congestión permanece constante (punto 3). Con la información de los asentimientos selectivos, retransmiten los segmentos perdidos. Cuando llega el asentimiento que confirma la recepción de todos los seguidos, se continúa con la fase de congestion avoidance (punto 4).

CAPÍTULO 3. RESULTADOS Y DISCUSIÓN

25 De esta figura se observa que el comportamiento de Sack es el mismo que con una pérdida, esto se debe a que Sack puede tolerar y retransmitir selectivamente hasta 3 o 4 bloques de paquetes que se han perdido, por lo tanto para esta ejecución de la simulación Sack ajustó hasta 3 bloques de datos para el caso de múltiples perdidas, resultando un comportamiento similar al de la pérdida de un paquete.

1

2

4

3

Fig 3.1.6 Gráfica de la ventana de congestión en TCP Sack. Pérdida de dos

ráfaga conteniendo dos segmentos de un mismo flujo con TCP Sack.

3.3.2 Comportamiento del retardo, la razón de transferencia y la respuesta de