Resumen

  • RFC 6928 permite, pero no obliga, una ventana inicial con límite superior de diez segmentos; la fórmula depende del MSS y admite empezar por debajo.
  • La reducción de RTT se obtiene enviando más datos antes de recibir evidencia del camino, de modo que la telemetría y el regreso al comportamiento de RFC 3390 son parte del control.

El saludo de TCP confirma quién habla con quién, pero no revela cuánto espacio queda en la siguiente cola. Tampoco muestra el ancho de banda del acceso, la profundidad del búfer ni los flujos que competirán un instante después. La ventana inicial es la decisión que TCP toma en ese vacío: cuántos datos puede poner en marcha antes de aprender del retorno.

RFC 6928 elevó el límite superior anterior a min(10*MSS, max(2*MSS, 14600)). El valor de diez es un máximo facultativo. El cambio rige el primer RTT de datos durante o después del saludo de tres pasos; ni el SYN/ACK ni el ACK que cierra el saludo aumentan la ventana.

Por eso IW10 no es otra versión de TCP Fast Open. Fast Open intenta adelantar datos de aplicación al propio SYN. IW10 mantiene el orden normal del saludo y amplía el volumen de la primera ráfaga de datos. Uno cambia cuándo puede llegar la petición; el otro, cuánto riesgo de cola asume el emisor antes del primer feedback.

Menos rondas no significa capacidad conocida

Bajo las hipótesis simplificadas del RFC —ancho de banda infinito, ausencia de pérdidas y ACK diferidos normales— subir de tres a diez segmentos puede ahorrar hasta cuatro RTT en conjuntos mayores de 4 KB. Su ejemplo de 32 segmentos necesita dos rondas con IW10 en lugar de cinco. Una primera ventana mayor también puede producir suficientes ACK duplicados para que Fast Retransmit repare una pérdida sin esperar el temporizador inicial.

La demostración no describe cualquier red actual. Una ventana de recepción pequeña impide aprovechar los diez segmentos. Las pruebas citadas usaron MTU Ethernet de 1.500 bytes. Además, una aplicación que abre muchas conexiones simultáneas convierte diez segmentos por flujo en una ráfaga agregada mucho mayor.

El coste llega primero a la cola

En un enlace lento, un búfer pequeño o una cola congestionada, la primera ráfaga puede provocar descartes prematuros, un RTO o una salida anticipada de slow start. Mientras la adopción sea desigual, el flujo IW10 puede tomar más capacidad inicial que un flujo conforme a RFC 3390. En redes de acceso con colas largas, esa presión también puede retrasar DNS, voz, juegos y otros tráficos sensibles.

RFC 6928 no considera probable que un único aumento inicial produzca colapso: el retroceso normal de TCP continúa. Sin embargo, la conclusión deja de ser suficiente cuando muchas conexiones repiten la misma acción. La propiedad «una sola vez» existe por conexión, no necesariamente por página, origen o servicio.

La pérdida conserva la última palabra

El documento distingue la ventana inicial, la ventana de reinicio tras inactividad y la ventana de pérdida tras un timeout. La ventana de reinicio puede usar como máximo el menor valor entre la ventana inicial y la cwnd vigente. La ventana de pérdida sigue siendo un MSS, la respuesta mínima a una congestión severa. Si aparece pérdida en una ventana inicial o de reinicio después de enviar más de 4 KB, la implementación debería volver al reinicio de RFC 3390.

También obliga a respetar RFC 6298: cada ACK que reconoce datos nuevos reinicia el RTO actual. En un acceso lento, el tiempo de serialización de la ráfaga puede dominar el RTT; una gestión incorrecta del temporizador convertiría la aceleración en retransmisiones espurias.

Alcance de la evidencia

La única fuente es RFC 6928, documento Experimental de abril de 2013. Sustenta la fórmula, las comparaciones y las condiciones de despliegue. No demuestra qué sistemas actuales usan IW10, el resultado de una red concreta ni la seguridad de valores mayores de diez.