¡Hola! ¿Podría alguien explicarme qué sucede en el tiempo de espera? Entonces el tamaño de la ventana cae por completo. Pensé que en el tiempo de espera ocurriría lo mismo que en 3 ACK duplicados; la mitad del ciclo y entrar en aumento aditivo. ¿Hay alguna diferencia en cómo se manejan estos indicadores de congestión?
Respuestas:
Lo que sucede en el tiempo de espera está bastante claro en el dibujo ... El tamaño de la ventana de congestión vuelve a su valor original de 1 y el inicio lento se ejecuta nuevamente.
Los detalles de cómo una pila TCP manejará los eventos de congestión dependen de la variante que esté utilizando. Este dibujo parece un ejemplo del algoritmo TCP Reno .
Al ver 3 ACK duplicados, TCP Reno concluye que hay congestión, pero la red sigue funcionando ya que algunos segmentos fueron reconocidos. En caso de un tiempo de espera, la situación es peor: la red parece no responder por completo. En realidad, el hecho de que se reciban acks duplicados antes de que caduque un temporizador de retransmisión significa que los segmentos aún se reciben por el otro lado, aunque algunos se hayan perdido (o reordenado).
Entonces, en el caso de los 3 acks duplicados, la ventana de congestión se reduce a la mitad y luego se aumenta linealmente. Esto se conoce como recuperación rápida , y su objetivo es evitar esperar tiempos de espera de retransmisión.
Cuando ocurre un tiempo de espera de retransmisión, la reacción es más drástica. TCP Reno comienza de nuevo con un inicio lento desde una ventana de congestión de tamaño 1 y un umbral de inicio lento de la mitad del valor de la ventana de congestión cuando se produce el tiempo de espera. Cuando se alcanza el umbral, el aumento vuelve a ser lineal (aumento aditivo).
TCP Tahoe no incluía una recuperación rápida, y reaccionaría de la misma manera en ambos casos, restableciendo la ventana de congestión a su valor inicial y ejecutando un inicio lento. La recuperación rápida de TCP Reno básicamente omite el inicio lento, configurando inmediatamente la ventana de congestión en el valor umbral e iniciando el aumento lineal.
Tenga en cuenta que existen muchas más variantes y que las implementaciones reales pueden ser más complejas. También observar estos algoritmos en el trabajo no es fácil porque otros mecanismos TCP pueden interferir.
No sé si lo que tenía en mente (usando la recuperación rápida en ambas situaciones) existe como un algoritmo de prevención de congestión conocido e implementado. Probablemente fue probado y descartado cuando se implementó Reno. Siéntase libre de investigar un poco en los artículos científicos en esta área.