Resumen

  • El RFC 2140, publicado como Informational en abril de 1997, propuso conservar parte de las observaciones del bloque de control TCP para conexiones entre la misma pareja de hosts. No era una norma de Internet ni una demostración de mejora medida.
  • Reutilizar MSS y RTT de una conexión cerrada era el caso temporal; usar datos mientras varias conexiones seguían abiertas era el caso de conjunto. En este último, copiar la ventana de congestión a cada flujo agrandaría la carga agregada.
  • El documento trató la caché como una posible fuente de daño: pidió validar sus valores, limitar la influencia de estados alterados y dejar fuera datos de seguridad como los números de secuencia.

La segunda petición conoce a la primera

Imaginemos una petición breve que termina tras medir un tiempo de ida y vuelta. Poco después sale otra hacia el mismo host. La primera ya no conserva su conexión, pero el extremo podría conservar una estimación de RTT o un valor MSS anunciado por su par. RFC 2140 planteó en 1997 que tratar toda esa experiencia como propiedad exclusiva de un socket obligaba a los intercambios cortos a aprender repetidamente desde el principio.

No proponía trasladar entero el bloque de control TCP. Las referencias a búferes, la cola de retransmisión, los puertos y el estado de la conversación pertenecen a una conexión concreta. El tamaño máximo de segmento y las estimaciones de ida y vuelta se parecen más a observaciones entre dos máquinas. La ventana de congestión ocupa una tercera categoría: aunque las conexiones puedan compartir un cuello de botella, sus ventanas representan carga en conjunto. El mismo número no puede otorgarse gratuitamente a cada recién llegado.

Ese reparto de propiedad era una apuesta para mejorar el tramo inicial de conexiones cortas y simultáneas, muy relevantes para la Web de aquella época. El memorando decía que no quería alterar el comportamiento a largo plazo de una conexión ya establecida. Su condición Informational y su lenguaje de propuesta importan: describía una posibilidad técnica, no un despliegue universal ni un resultado experimental que cuantificara la ventaja.

La hora a la que se escribe la caché

El uso temporal empieza después del cierre. El texto señala las extensiones T/TCP de SunOS 4.1.3 y su portación a FreeBSD como ejemplos que guardaban MSS y parámetros de RTT. En ellos, la opción MSS podía actualizar la caché al recibirse; RTT y su variación se combinaban al cerrar la conexión. Reutilizar snd_cwnd estaba discutido, no implementado en aquel ejemplo. Además, el promedio entre conexiones no equivalía al cálculo del RTT dentro de una sola; el propio RFC advertía que la estimación resultante podía no ser adecuada.

El uso de conjunto rompe ese calendario. Si cinco conexiones comienzan antes de que cierre ninguna, una caché escrita solo al final no sirve a las otras cuatro. El documento estudió actualizaciones más tempranas para que las mediciones circularan mientras los flujos seguían activos. MSS y RTT pueden copiarse como observaciones; la ventana requiere administrar la suma. Incluso la ventana inicial de un segmento que el documento atribuye a las implementaciones de entonces aumentaba el total al abrir una conexión nueva. Copiar una ventana anterior más grande aumentaría todavía más el potencial de envío.

Como alternativa, RFC 2140 imaginó dividir una ventana agregada entre N+1 conexiones y reducir la parte de las N ya existentes. No aseguró que partes iguales fueran la justicia correcta. Declaró que esa suposición podía fallar y que hacía falta examinarla. La diferencia entre esas opciones es una diferencia de coste para terceros que compiten por la misma ruta, no solo una opción de velocidad para la aplicación que abre sockets.

El error también se hereda

Una observación vieja puede dejar de describir el camino. Una observación maliciosamente pequeña puede ralentizar conexiones que no participaron en su producción. El apartado de seguridad consideraba incluso una ventana cero como forma de perjudicar a las siguientes. Por eso pedía comprobar los valores compartidos frente a mínimos por defecto al inicializar, contener los cambios sobre estado compartido durante las conexiones activas y apartar los bloques modificados directamente por una aplicación o recibidos sin autenticación, salvo permiso explícito.

Los números de secuencia debían quedar fuera: no son una optimización de rendimiento transferible.

La pareja de hosts no prueba que todos los paquetes hayan recorrido siempre el mismo camino. Tampoco una caché demuestra ancho de banda libre. RFC 9040 sustituyó al RFC 2140 en 2021 y refinó la descripción; sus detalles posteriores no deben presentarse como hechos de 1997. Lo que permanece de la primera propuesta es la necesidad de fechar y atribuir cada medición antes de permitir que otra conexión actúe sobre ella.

Fuentes y límites

Estas fuentes no aportan una prueba actual de implementación, un ensayo de rendimiento, ni una identidad garantizada del camino entre dos conexiones.