Resumen

  • El RFC 1016 propuso SQuID, un retraso entre datagramas que el módulo IP de origen guardaría por destino reciente. El valor normal D era cero; solo los destinos con retraso positivo necesitaban una entrada activa.
  • En sus parámetros de ejemplo, un aviso imponía al menos 75 ms, otro evento sumaba 20 ms, los avisos de un intervalo de dos segundos se agrupaban y D bajaba 1 ms tras cada segundo pertinente con datos pendientes. Las observaciones procedían de una simulación escrita en C.

Una línea rápida podía entregar paquetes a una pasarela mucho antes de que una línea lenta pudiera sacarlos. El RFC 1016 daba una cuenta que se siente en la muñeca: si un megabyte esperaba turno para salir por 56 kb/s, el último datagrama tardaría más de dos minutos en despegar. Cuando faltaba sitio en la cola, la pasarela podía descartar tráfico y enviar ICMP Source Quench al origen. El mensaje pedía reducir la velocidad hacia el destino afectado. La cifra del freno quedaba sin escribir.

W. Prue y Jon Postel llamaron SQuID a su respuesta, Source Quench Introduced Delay. La ubicaron en el módulo IP del host emisor. Allí D representaba el tiempo de espera entre datagramas dirigidos al mismo destino. D empezaba en cero; el host mantenía una lista solo para los destinos que acumularan un valor positivo. Un paquete para otro destino podía salir mientras uno esperado aguardaba. La pasarela señalaba dónde dolía, y el emisor ajustaba precisamente esa corriente.

El primer evento de aviso llevaba D como mínimo a 75 milisegundos. Eventos posteriores podían añadir 20 milisegundos cada uno. Varios avisos recibidos durante dos segundos contaban como uno solo: una pasarela que enviara una ráfaga de Source Quench no podía obligar al host a multiplicar sin límite su espera. La recuperación iba al paso contrario. Después de un segundo válido con datos por enviar, D se reducía 1 milisegundo, sin cruzar por debajo de cero. Si un destino quedaba inactivo, el cronómetro no perdonaba de forma automática el retraso por el simple paso del tiempo.

El ritmo cuenta más que la apariencia de esos números. Setenta y cinco milisegundos caben en un parpadeo; repetidos antes de cada nuevo datagrama, deshacen la estampida que una red local rápida podía lanzar contra un enlace lento. El aviso tenía una traducción local, revisable y específica por destino. El propio RFC presentó la idea como una propuesta para discutirla, con parámetros de trabajo que se podían variar.

La otra mitad del mecanismo vivía en la pasarela. Prue y Postel propusieron avisar antes de que el atasco obligara a tirar datos. En su esquema ilustrativo, una cola al 70 % enviaba Source Quench mientras todavía dejaba pasar el datagrama que provocaba el aviso. Al 95 % empezaba a descartar datos. Los avisos continuaban hasta que la cola bajaba del 50 %. Esta secuencia daba al emisor una oportunidad de actuar mientras quedaba espacio, y mantenía una señal hasta que la presión cedía de verdad.

Para estudiar el encuentro entre pasarela, IP y TCP, los autores construyeron un modelo de Internet en C. Una conexión local de 10 Mb/s alimentaba una línea amplia de 56 kb/s y después otra red local de 10 Mb/s. El modelo usaba datagramas de 512 bytes, colas y rutas fijas; no simulaba fragmentación ni TTL. Los autores variaron el tamaño de ventanas, los avisos y los retrasos. Todos los algoritmos oscilaron. Una subida pequeña de D seguida de una bajada rápida hacía pasar demasiado tiempo por encima de la capacidad del enlace, con pérdidas como resultado. Aumentar con decisión y recuperar despacio ofrecía mejores señales en esa prueba.

La escena de una ventana TCP de veinte datagramas explica el apuro. En el caso descrito por el RFC, la ráfaga llegaba a la pasarela en 81 ms. El siguiente tramo tardaba unos 73 ms por datagrama; apenas uno avanzaba mientras el resto se acumulaba. Con la cola elegida, se perdían el decimoséptimo, el decimoctavo, el decimonoveno y el vigésimo. La ventana del emisor decía «puedo enviar veinte». La cola respondía con una aritmética bastante menos hospitalaria. SQuID intentaba repartir las salidas antes de que esa diferencia se convirtiera en pérdidas.

El RFC observó además que muchas implementaciones TCP ni siquiera recibían un evento Source Quench bien definido desde IP e ICMP. Situar la respuesta en IP permitía dosificar los datagramas de esa fuente aunque TCP no oyera el aviso. También abría preguntas sobre la interacción entre las dos capas, que la simulación trataba de explorar. La evidencia del texto es una prueba de modelo con límites expresos y un diseño que podía instalarse por partes. Una medición en redes en servicio sería la prueba siguiente.

El gesto interesante de 1987 fue convertir una queja en una decisión ejecutable. La pasarela conocía su presión; el host podía espaciar los paquetes futuros hacia ese destino. Si el último paquete de la fila esperaba dos minutos, una pausa de milisegundos en el origen dejaba de parecer una manía de relojero. El mensaje decía «despacio». El cronómetro contestaba cuánto.