Resumen

  • RFC 3742 reduce el crecimiento de la ventana TCP cuando cwnd supera max_ssthresh, porque el inicio lento exponencial puede sumar miles de segmentos en una RTT.
  • El erratum 236, verificado, corrigió el rango por RTT: alcanzar 83.000 paquetes requiere al menos 836 RTT en el ejemplo, no exactamente esa cantidad.

«Limitado» no quería decir «a velocidad fija». RFC 3742 era una propuesta experimental y opcional para conexiones con ventanas de miles de tamaños máximos de segmento. Hasta max_ssthresh, mantenía el aumento habitual de un MSS por cada ACK recibido. Por encima, calculaba K = int(cwnd / (0.5 * max_ssthresh)) y sumaba aproximadamente una K-ésima parte de un MSS por ACK. El nuevo umbral no sustituía a ssthresh: superar este último seguía poniendo fin al inicio lento.

La exposición de las cifras fue más tajante de lo que permitía el algoritmo. La sección 2 original decía que el aumento por RTT por encima de max_ssthresh no podía superar la mitad de ese umbral. Sin embargo, la regla por ACK, con un K que cambia por tramos, describía un intervalo. El erratum 236, verificado por el editor de RFC, corrigió el invariante: el aumento no supera max_ssthresh MSS por RTT y tampoco cae por debajo de la mitad. También reemplazó una fórmula única de tiempo por cotas inferior y superior. Con un umbral de 100 MSS y una ventana objetivo de 83.000 paquetes, los 836 RTT citados con frecuencia pasaron a ser un mínimo.

Es una corrección a la descripción del mecanismo, no un algoritmo nuevo. El texto publicado en 2004 permanece intacto; el erratum es una fuente separada que debe leerse junto con él. La corrección amplía la imagen del crecimiento y la duración posibles, pero no convierte ninguno de los extremos en un resultado universal medido.

El límite buscaba evitar una externalidad además del costo para el emisor. Un salto grande durante el inicio lento podía provocar muchas pérdidas juntas, expiraciones del temporizador de retransmisión y una vuelta a una ventana pequeña. La ráfaga también competía por las colas y el margen de pérdida de otros flujos. RFC 3742 dio un ejemplo con un umbral de 100 MSS y describió experimentos iniciales con un kernel Linux 2.4.16 Web100. Eso es evidencia histórica acotada: no prueba despliegue actual generalizado, beneficio para todo Internet ni una garantía sobre el tamaño de una cola.

Los documentos TCP posteriores emplean otras señales. RFC 9438 generalmente recomienda HyStart++ para el inicio lento de CUBIC y enumera Limited Slow-Start como alternativa experimental. RFC 9406, en cambio, usa el aumento del RTT como indicio para salir del inicio lento y añade una fase conservadora que comprueba si la salida fue prematura. Es una señal de control distinta del incremento dependiente de cwnd en RFC 3742; no son mecanismos intercambiables.

Para operadores, el erratum recuerda que una cifra destacada no siempre acota lo que parece. Un aumento de ventana por RTT no es un tope directo de bytes por segundo, una medición de cola ni una prueba de equidad en un camino compartido. Umbral, ACK, pacing, búfer, RTT y flujos concurrentes influyen en el resultado. La corrección vuelve visible la incertidumbre del propio RFC; no la elimina.

Fuentes