TCP per se (es decir, el protocolo original especificado por RFC 793, STD 7) no responde estas preguntas; son el dominio de cualquier esquema de control de congestión que se use para gobernar las transmisiones de TCP (además del control de flujo controlado por el receptor del TCP “estándar”).
Los requisitos oficiales para un esquema de control de congestión TCP se dan en RFC 5681, aunque, tenga en cuenta que los esquemas de control de congestión reales (por ejemplo, el valor predeterminado de Linux de Cubic modificado) realmente no siguen este RFC.
Sin embargo, si cree en el RFC, está en lo correcto. Esto es lo que dice:
- Cómo traducir datos TCP / UDP a inglés simple
- ¿Cuál es el significado de 127.0.0.1 y 10.10.10.1 direcciones IP?
- ¿Cómo funcionan de manera diferente el algoritmo de Bellman-Ford y el algoritmo de Dijkstra en los protocolos de enrutamiento?
- ¿Cuáles son las funciones de 7 capas del modelo de referencia OSI?
- ¿Cuánto cobrarías por un día cero dentro de la suite TCP / IP?
Cuando un emisor TCP detecta la pérdida de segmento utilizando el temporizador de retransmisión y el segmento dado aún no se ha reenviado mediante el temporizador de retransmisión, el valor de ssthresh DEBE establecerse en un valor no mayor que el indicado en la ecuación (4):
ssthresh = max (FlightSize / 2, 2 * SMSS) (4)
donde, como se discutió anteriormente, FlightSize es la cantidad de datos pendientes en la red. […] Además, tras un tiempo de espera (como se especifica en [RFC2988]) cwnd DEBE establecerse en no más que la ventana de pérdida, LW, que equivale a 1 segmento de tamaño completo (independientemente del valor de IW). Por lo tanto, después de retransmitir el segmento descartado, el emisor TCP utiliza el algoritmo de inicio lento para aumentar la ventana de 1 segmento de tamaño completo al nuevo valor de ssthresh, en cuyo punto la evitación de la congestión nuevamente se hace cargo.
