Control de congestión en TCP

La idea básica en el control de congestión es no intentar insertar un nuevo paquete en la red si es que uno anterior no la ha abandonado (se ha entregado). TCP logra la premisa anterior cambiando el tamaño de su ventana.

Cuando se inicia una conexión, el emisor manda segmentos de 1K, luego de 2K, luego de 4K y asi sucesivamente esperando una confirmación en cada caso. Cuando la confirmación falla, digamos en 2K, la ventana de congestión se pone de ese tamaño. A este proceso se le llama «comienzo lento».

Cada emisor tiene dos ventanas: la de congestión y la que confirma el receptor. Si el receptor dice «envíame segmentos de 4K» pero el emisor ya descubrió que esos segmentos no son confirmados porque rebasan la capacidad de la subred, pone su «ventana confirmada» en 4K y la de congestión en 2K, y finalmente enviará segmentos del tamaño que resulte menor de las dos ventanas, lo cual será la «ventana efectiva».

El algoritmo completo contiene otra ventana llamada «holgura» y sirve para afinar el crecimiento exponencial del algoritmo de comienzo lento. La ventana de holgura tiene un tamaño inicial de 64 Kb. cada vez que hay un timeout en el comienzo lento, el valor de la holgura será puesta al valor de la ventana de congestión dividido por dos, y el comienzo lento vuelve a arrancar, excepto que el crecimiento exponencial se detiene cuando se alcanza la holgura. De ahí en adelante la ventana de congestión crece de uno en uno.

Por ejemplo, supongamos que una subred puede procesar hasta 12 Kb. Inicialmente la ventana de congestión es 1K, la de confirmación es 0 y la de holgura es 64 K. El emisor inicia el comienzo lento y envía un paquete de 1 K, y el receptor le dice «mándame 24K». El emisor pone la de congestión en 1K, la confirmada en 24K y la holgura en 64K y envía un paquete de 2K. El receptor dice «envíame 24K. El emisor pone la de congestión en 2K y envía un paquete de 4K y obtiene la misma respuesta del receptor.

El emisor pone la de congestión en 4K y envía un segmento de 8K, obtiene la misma respuesta y cambia la ventana de congestión a 8K y envía un segmento de 16K, pero como la subred solo soporta 12K, ocurre un timeout y tiene que poner su ventana de holgura a la mitad de la de congestión, es decir, a 4K y reinicia la de congestión a cero. Repite el comienzo lento hasta que su segmento enviado es de 4K, en ese momento su siguiente paquete no será de 8K, sino de 5K, luego de 6,7,8,9,10,11,12,13K donde habrá un timeout y se sabrá que el tamaño de ventana efectiva es de 12K.