Resumen
- RFC 1106 describió un NAK consultivo y una ventana TCP de recepción de 30 bits. Afirmó que ambos se habían implementado y mostrado en funcionamiento con recursos de la NASA, pero los mantuvo como protocolo experimental, no como estándar de Internet.
- RFC 1110 señaló una condición decisiva: ampliar la ventana sin ampliar los 32 bits de secuencia permitía reutilizar un número tras cuatro viajes de ida y vuelta. Un duplicado antiguo podía regresar dentro de un ciclo nuevo.
- El NAK observaba un hueco, no su explicación. No distinguía datos tardíos de datos perdidos ni ruido de congestión, y tampoco demostraba retransmisión, recuperación o entrega.
El alcance estaba escrito en la misma declaración de éxito
La RFC 1106, publicada por R. Fox en junio de 1989, no escondía su doble condición. Las extensiones habían sido implementadas y habían funcionado usando recursos de la NASA. A la vez, el texto las llamaba experimentales, no las proponía como estándar de Internet y las ofrecía como punto de partida para investigar.
Una lectura cuidadosa conserva las dos proposiciones. El ensayo era evidencia de una implementación, de dos extremos capaces de negociar y de un comportamiento medido en cierto entorno. No era un inventario de todos los estados que podía producir una red de redes.
El propio resumen dejaba abiertos dos límites: congestión frente a ruido y aplicabilidad al conjunto de Internet frente a un entorno satelital aislado. Borrar esos límites para conservar solo «funcionó» habría alterado el resultado original.
La ficha actual del RFC Editor registra estado Historic y flujo Legacy; el IETF Datatracker mantiene el expediente. Esa clasificación posterior describe autoridad y adopción actuales. No convierte en ficticia la implementación acotada.
Un hueco en la secuencia no venía acompañado de diagnóstico
El NAK buscaba reaccionar antes que el temporizador normal. Si un segmento llegaba más adelante de lo esperado, el receptor señalaba los datos necesarios para mover el borde izquierdo de la ventana. En una ruta satelital, ahorrar una espera podía evitar que el tubo quedara vacío.
Pero el receptor no sabía si el dato faltante llegaría tarde o no llegaría nunca. RFC 1106 lo decía de forma expresa. Pedir una retransmisión podía reparar una pérdida o fabricar un duplicado de un paquete que aún seguía en tránsito.
Además, el aviso era consultivo e inseguro. No se retransmitía. El emisor podía ignorarlo o actuar de inmediato; si desaparecía, TCP debía recuperarse por sus mecanismos ordinarios. El evento «NAK enviado» no autorizaba a escribir «pérdida confirmada», y menos aún «recuperación completada».
El mismo hueco tampoco separaba ruido, descarte por cola, retraso y reordenamiento. El punto que observaba la ausencia no veía por ello todos los equipos ni adquiría autoridad para atribuir una causa.
La ventana ofrecía memoria en un extremo
La segunda opción atacaba el límite de 64 KiB de la ventana de 16 bits. En una ruta con gran producto ancho de banda-retardo, esa cantidad impedía mantener suficientes datos sin confirmar. RFC 1106 propuso conservar los bits inferiores en la cabecera y llevar los superiores en opciones hasta formar una ventana de 30 bits.
Los dos extremos tenían que aceptarla durante SYN y SYN-ACK; después, cada paquete debía incluir la parte superior. La negociación probaba un acuerdo de interpretación. No probaba que el espacio de secuencia, la vida de los paquetes y el reordenamiento de cualquier ruta fueran compatibles con ese acuerdo.
Tampoco era una reserva de red. La ventana anunciaba cuánto podía aceptar el receptor de acuerdo con sus buffers. El documento advertía que una cifra arbitraria podía agotar memoria, bloquear otros procesos o derribar la máquina. La restricción a ciertos programas que se estudiaba con recursos de la NASA era control local de memoria, no ancho de banda concedido de extremo a extremo.
La aritmética redujo 65.536 vueltas a cuatro
En agosto, RFC 1110 cambió la escena. A. McKenzie recordó que Internet podía perder, desordenar y duplicar paquetes. Los 32 bits de secuencia se reutilizaban; su seguridad efectiva dependía de que la ventana fuera pequeña respecto del espacio y de que los paquetes antiguos caducaran antes de volver a ser admisibles.
Con 16 bits de ventana, un número tardaba 65.536 viajes de ida y vuelta en reaparecer según el modelo de RFC 1110. Con 30 bits y el mismo espacio de secuencia, podía reaparecer tras cuatro. El NAK podía crear una copia después de uno. Un paquete retenido unas cinco vueltas podía regresar cuando su número volvía a caber en la ventana y sustituir datos nuevos por antiguos.
El argumento no negaba que el sistema hubiera funcionado en el ensayo. RFC 1110 admitía una hipótesis compatible: una red satelital aislada y sin memoria, capaz de entregar en orden o perder, pero no de conservar y devolver fuera de orden. La propuesta fallaba al cambiar de universo operativo, no al reescribir la observación pasada.
El archivo separó defecto, adopción y mecanismos posteriores
RFC 4614 describió más tarde RFC 1106 como defectuosa para uso general, RFC 1110 como su deprecación y las opciones como no adoptadas por la comunidad amplia. Su nota sobre NAK en SCPS-TP era una excepción delimitada, no adopción de todo el diseño.
RFC 6247 movió formalmente ambos documentos a Historic en 2011 entre extensiones sin uso extendido. La frase no significa que jamás hubiera código. Permite distinguir implementación, difusión y estatus.
La RFC 7323 resolvió problemas relacionados por piezas: Window Scale es una oferta negociada en SYN; SACK describe mejor qué segmentos llegaron; los timestamps y PAWS protegen frente a duplicados antiguos tras el ciclo de secuencia. No hay base para presentar esta arquitectura como descendiente directo de RFC 1106. Sí hay base para afirmar que ventana, evidencia de pérdida y vigencia de datos requieren controles distintos.
El resultado debía viajar con su manifiesto
Una prueba conservable registra versión, topología, modelo de error, límites de buffers, ventanas, ritmo de consumo del espacio de secuencia, tiempo máximo de residencia, reordenamiento, duplicación, tráfico y puntos de observación. También registra qué estados no existieron.
Sin ese manifiesto, «funcionó» se convierte en garantía fuera del laboratorio. En el extremo opuesto, «Historic» puede borrar una experiencia real. La historia responsable guarda la medición de RFC 1106 y el contraejemplo de RFC 1110 como capas distintas de un mismo expediente.
Fuentes
- RFC 1106 — TCP Big Window and NAK Options
- Ficha del RFC Editor para RFC 1106
- IETF Datatracker — RFC 1106
- RFC 1110 — A Problem with the TCP Big Window Option
- Ficha del RFC Editor para RFC 1110
- RFC 4614 — hoja de ruta de documentos TCP
- RFC 6247 — extensiones TCP no desplegadas a Historic
- RFC 7323 — TCP Extensions for High Performance
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
