TL; DR: “Inicio lento” lo compara con el comportamiento de control anterior, que era “transmitir a toda velocidad, inmediatamente”.
Tuve el placer de asistir a una clase de extensión de UCB impartida por Mike Karels en 1989, donde golpeó este tema con cierta autoridad y pasión. No tenía idea de lo importante que era tener una clase con él en ese momento. Era nuevo en la industria y pensé que solo estaba tomando una clase básica de TCP. En cambio, estaba escuchando a un cocreador del primer algoritmo para evitar la congestión TCP que haría posible la Internet moderna.
El trabajo fundamental que presenta el inicio lento es este artículo de SIGCOMM de 1988. Esa es la mejor manera de entender por qué las cosas son como son.
- Cómo DDoS un servidor, direcciones IP
- ¿Cuál es la responsabilidad de una dirección IP, MAC y de puerto?
- Cómo reparar la dirección IP que comienza con un problema 169.254.xx
- ¿Con qué frecuencia se viola la garantía de pedido de TCP en la práctica para implementaciones comunes de TCP?
- ¿Cuál es la dirección IP de la computadora que inició la sesión HTTP?
El inicio lento descrito en el documento es solo lento en relación con el estado de la técnica anterior, que simplemente intentaba transmitir de inmediato todos los paquetes de forma consecutiva a velocidad de cable sin tener en cuenta el nivel de congestión en la red. Tal comportamiento inundó la red con paquetes que tendrían que retransmitirse, lo que induciría una congestión inútil y un colapso potencialmente congestivo.
Enviar paquetes inmediatamente a la velocidad del cable es una gran idea si no hay congestión, por lo que un aumento exponencial en la velocidad de transmisión es exactamente lo que se debe hacer, especialmente si retrocede inmediatamente al perderse un ACK. El objetivo es consumir todo el ancho de banda disponible si nadie más lo está utilizando, pero no bloquear injustamente a otros usuarios.
Como nota al margen, el comportamiento de retroceso agresivo frente a la pérdida de paquetes causa una gran degradación del rendimiento en las llamadas redes de “cubos con fugas” (como las inalámbricas) donde la pérdida de paquetes es un efecto secundario natural del medio y no un buen indicador de congestión . Algoritmos de control de congestión TCP más modernos intentan estimar los cambios en el retraso de ida y vuelta para servir como proxy para la detección de congestión.
