Resumen

  • En octubre de 1986, el rendimiento útil entre Lawrence Berkeley Laboratory y UC Berkeley cayó de 32 Kbps a 40 bps: la red seguía ocupada, pero sus paquetes realizaban cada vez menos trabajo nuevo.
  • Jacobson, Karels y otros colaboradores repararon el TCP de 4BSD mediante conservación de paquetes, reloj de ACK, slow start, mejores temporizadores, retroceso exponencial y una ventana de congestión.
  • RFC 1122 convirtió luego slow start y congestion avoidance en obligaciones. La operación descentralizada necesitó una regla mínima contra quienes trasladaban al conjunto el coste de su agresividad.

Cuatrocientos metros y casi ningún dato útil

El episodio más famoso de la congestión temprana ocurrió entre vecinos. En octubre de 1986, una ruta de dos saltos IMP entre Lawrence Berkeley Laboratory y la Universidad de California en Berkeley, separados por unas 400 yardas, pasó de entregar 32 kilobits por segundo a apenas 40 bits por segundo. Van Jacobson y Michael J. Karels describieron una caída cercana a tres órdenes de magnitud.

No era simplemente una cola larga. La línea transportaba paquetes, pero una proporción creciente eran copias de datos que ya estaban en tránsito. Un temporizador demasiado rígido interpretaba el retraso como pérdida. La retransmisión llenaba aún más las colas, elevaba el retraso y provocaba nuevas retransmisiones. Cuanto más intentaban recuperarse los emisores, menos información nueva conseguía cruzar.

John Nagle ya había llamado “congestion collapse” a ese estado en RFC 896, publicado en 1984. Su texto explicaba por qué una interred de datagramas que conectaba enlaces desiguales podía quedar atrapada en una condición estable y ruinosa. Pero era una propuesta para abrir debate, no la especificación definitiva de un remedio. La crisis de 1986 permitió estudiar el fallo en un TCP real.

Dos ventanas para dos límites diferentes

El TCP original disponía de una ventana anunciada por el receptor. Su misión era impedir que el emisor desbordara el búfer del destino. Sin embargo, un receptor con espacio no sabe cuánta capacidad tienen las pasarelas y los enlaces intermedios. Confundir ambos límites permitía que una máquina de Ethernet lanzara una ventana completa contra una ruta de 56 Kbps.

La solución añadió una ventana de congestión en el emisor. La cantidad enviada quedó limitada por la menor entre esa ventana y la anunciada por el receptor. Cuando una pérdida señalaba congestión, la ventana se reducía de forma multiplicativa. Cuando llegaban ACK nuevos, aumentaba de manera aditiva. El emisor aprendía el camino sin poseerlo.

El principio que daba coherencia a la reparación era la conservación de paquetes. En equilibrio, no se introduce un paquete nuevo hasta que otro ha salido. Los reconocimientos actúan como reloj: no pueden volver más deprisa de lo que los datos atravesaron el cuello de botella. Al seguir su cadencia, el origen hereda una medida aproximada de la capacidad disponible.

Una conexión recién iniciada todavía no tiene ese reloj. Slow start comienza con una ventana pequeña y la abre con cada ACK. El nombre puede engañar: el crecimiento es exponencial por rondas, pero evita la ráfaga inicial ciega. Otros cambios estimaban también la variación del tiempo de ida y vuelta, y el retroceso exponencial separaba cada vez más las retransmisiones repetidas. Así se eliminaban copias enviadas por un reloj equivocado.

Una reparación colectiva, no una biografía heroica

El artículo de 1988 enumera siete algoritmos incorporados a TCP 4BSD. Además de slow start y el ajuste dinámico de la ventana, incluye estimación de la variación del RTT, política de ACK, fast retransmit y la contribución de Phil Karn. Jacobson y Karels atribuyen a John Nagle el nombre slow start y reconocen la influencia de Raj Jain. El resultado fue una cadena de ingeniería compartida.

Sus pruebas mostraron la diferencia entre movimiento y utilidad. Sin control, cuatro conversaciones generaron 4.000 retransmisiones dentro de 11.000 paquetes y perdieron buena parte del rendimiento de un enlace de 25 KB/s. Con evitación de congestión, hubo 89 retransmisiones entre 8.281 paquetes, cerca del uno por ciento, y el ancho de banda quedó explicado por datos útiles.

El orden institucional también importa. Primero se modificó 4BSD TCP, se midieron trazas y se difundieron implementaciones. En octubre de 1989, RFC 1122 declaró inadecuado el cálculo de timeout de RFC 793 y estableció que TCP debía implementar la combinación de slow start y congestion avoidance. El retroceso exponencial de sucesivos RTO también pasó a ser obligatorio. La norma siguió al código que había demostrado corregir un fallo común.

El derecho a innovar no incluía el derecho a colapsar

Una obligación técnica sigue siendo una obligación. El episodio no demuestra que toda coordinación de Internet sea puramente voluntaria. Demuestra algo más preciso: una regla compartida puede ser legítima cuando coincide con una externalidad verificable y se limita a ella.

Un emisor que ignora la congestión ocupa colas comunes y causa pérdidas a flujos que sí reducen su velocidad. Puede parecer más rápido durante un instante, porque otros pagan. RFC 2914 advirtió más tarde del incentivo a vender TCP más agresivos o abrir muchas conexiones paralelas. Si cada actor responde igual, la ventaja desaparece y regresa el colapso.

La contención común protegió una gran diversidad alrededor. Nadie impuso un sistema operativo, una aplicación, una ruta o una empresa. Nuevos algoritmos siguieron siendo posibles si respondían de manera compatible a la congestión. La capa compartida fue firme justo donde la conducta local podía destruir el medio de todos.

Lo que el borde no podía decidir

Jacobson y Karels separaron estabilidad de reparto justo. Los endpoints podían impedir que la carga excediera continuamente la capacidad, pero no veían todos los flujos que convergían en una pasarela. La asignación equitativa exigía información y mecanismos en los routers. El texto llamó a esa tarea el siguiente gran paso.

Después llegaron gestión activa de colas, ECN y controladores adaptados a redes distintas. La pérdida no siempre equivale a congestión. Esta evolución no invalida 1988; confirma su prudencia. El arreglo trató una causa concreta, cambió la superficie mínima y dejó abiertas las cuestiones que no podía resolver.

Fuentes y límites de la evidencia

La base es Congestion Avoidance and Control, junto al índice del LBNL Network Research Group. La secuencia normativa está en RFC 896, RFC 1072, RFC 1122, RFC 2001, RFC 2914 y RFC 5681. El archivo de correo de LBNL conserva el contexto contemporáneo.

La cifra de 32 Kbps a 40 bps corresponde a una ruta observada, no a todo Internet a la vez. Tampoco permite atribuir el arreglo a una sola persona ni afirmar que la investigación sobre congestión terminó allí.