Control de congestión en flujos TCP

En principio TCP tiene un amplio conjunto de mecanismos para el control de congestión [38] [91] [92].

Comencemos por decir que TCP usa el protocolo de ventana deslizante, mediante el cual el origen de la transmisión incluye números de secuencias en los paquetes y así estos son “echoed” mediante paquetes ACK transmitidos por el receptor. Si se usa una ventana en lugar de un paquete se pueden transmitir más de un paquete antes que un ACK sea recibido. Cada paquete TCP ACK incluye una ventana de recepción por medio de la cual le indica al origen cuántos octetos pueden ser aceptados en cualquier momento, además de mandarle el número de secuencia continuo más alto de los paquetes de datos recibidos. Entonces el origen envía la suficiente cantidad de paquetes para llenar la ventana de recepción, antes de recibir un ACK. A medida que legan los ACK’s, la ventana de recepción se desliza y así se envían más datos.

Además de una ventana de recepción, los emisores TCP incorporan una ventana de congestión dimensionada de acuerdo a una estimación de la capacidad de la red y de esta forma previene a los emisores de saturar la red. La ventana de congestión comienza con el envío de un paquete y se incrementa de acuerdo ya sea a un algoritmo de “slow-start” (comienzo lento) o a un algoritmo de “congestion avoidance” (evitación de la congestión) mientras que no haya pérdidas de paquetes.

En el modo “Slow-start”, la ventana de congestión se incrementa por el tamaño de un paquete con cada ACK recibido. Así el emisor alcanza en

forma gradual la velocidad completa que le permite la red, ilustrado de la siguiente manera:

Diagrama del modo “Slow-Start” de TCP

La fase de slow-start continúa hasta que se pierde un paquete, o hasta que se excede el umbral de slow-start.

En el modo de “congestion avoidance”, la ventana de congestión se incrementa por el tamaño de un paquete cada RTT, en lugar de incrementar un paquete por cada ACK recibido. El resultado es un crecimiento lineal de la ventana de congestión, un crecimiento aditivo en la velocidad de envío.

Las conexiones TCP incrementan su velocidad de envío de acuerdo a uno de los dos algoritmos descriptos recién, hasta que ocurre una pérdida de paquete. La pérdida de un paquete indica que se alcanzó la capacidad de la red y ha habido una congestión momentánea. El emisor puede detectar congestión de dos maneras: por un timeout o por medio de la recepción de un triple ACK duplicado. Cuando ocurre un timeout, el emisor establece el umbral de slow-start a la mitad del número de paquetes actuales o dos paquetes, depende de cuál valor es mayor. Entonces establece la ventana de congestión al tamaño de un paquete y entra en show-start. El proceso de slow-start continúa hasta que el umbral de slow-start sea excedido, que es cuando el emisor ingresa al modo de evitación de la congestión. Un timeout prolongado causará que el emisor desista y se desconecte.

La otra manera que el emisor puede detectar una congestión es por la presencia de paquetes ACK duplicados, lo que puede suceder porque un paquete se pierde o es reordenado como se detalla en la siguiente figura:

Generación de paquetes ACK duplicados

Los paquetes ACK, como ya se mencionó, contienen el número de secuencia continuo más alto recibido, y por lo tanto si un paquete de datos se pierde los siguientes paquetes ACK contendrán el número de secuencia antes de la pérdida hasta que el paquete perdido sea retransmitido. Si un paquete es reordenado también se generará un ACK duplicado, pero en este

caso la secuencia de ACK’s vuelve a su normalidad cuando finalmente arriba ekl paquete reordenado.

Si el emisor recibe tres paquetes ACK duplicados, asume que el paquete se perdió a causa de la congestión. Entonces el emisor establece su ventana de congestión y el umbral de slow-start a la mitad de los paquetes actuales o a dos paquetes, según sea el mayor valor. Luego retransmite el paquete perdido e ingresa en el modo de “congestion avoidance”.

La combinación de estos algoritmos da como resultado un throughput TCP con la siguiente característica:

Variación en la velocidad de un flujo TCP a lo largo del tiempo

La característica de esta curva de velocidad en el tiempo tiene como patrón un incremento aditivo (“additive-increase”) y un decremento multiplicativo (“multiplicative-decrease”), con una gran variación en el throughput en cortos períodos de tiempo.

La rápida variación del throughput es lo que hace que un sistema que usa TCP sea estable. La característica de “multiplicative-decrease” asegura una respuesta rápida ante la congestión, previniendo así el colapso. La

característica de “additive-increase” -que prueba el máximo throughput posible- asegura que la capacidad de la red esté utilizada a pleno.

Existen diferentes estudios acerca de la variación del throughput TCP y de los demás flujos TCP que compiten a la vez [93] [94] [95] [96]. Estos estudios demuestran que los flujos que compiten a la vez obtienen en promedio aproximadamente iguales “pedazos” de la capacidad, a pesar que el perfil del throughput muestre que sus “pedazos” compartidos de ancho de banda probablemente no sean equitativos.

En TCP hay una inequidad sistemática: dado que el algoritmo responde al feedback, las conexiones con menor tiempo de RTT responden con sus feedbacks más rápido y así trabajan mejor. De esta manera, las conexiones con RTT más largos reciben sistemáticamente en promedio un “pedazo” de la capacidad de la red menor.