Resumen

  • cm_request avisaba de que una aplicación deseaba enviar, pero no entregaba ningún búfer al Congestion Manager; cmapp_send autorizaba hasta una cantidad acotada, normalmente un PMTU, durante un tiempo limitado.
  • El permiso no demostraba que hubiera un paquete en cola ni que llegara al destino. La aplicación elegía o reformaba el contenido, notificaba los bytes realmente emitidos con cm_notify y aportaba por separado el feedback del receptor mediante cm_update.

Compartir la congestión sin apropiarse de los datos

Una máquina conectada a Internet podía mantener muchos flujos hacia un mismo destino y, sin embargo, hacer que cada aplicación descubriera el camino desde cero. Los navegadores abrían transferencias paralelas; el audio y el vídeo ajustaban sus tasas; una conexión nueva ignoraba medidas que otra acababa de obtener. Todos competían en el mismo cuello de botella, pero sus bucles de control actuaban como si no se conocieran.

RFC 2140 había descrito cómo compartir parte del estado TCP entre conexiones de una pareja de hosts. RFC 3124, publicada como Standards Track en junio de 2001, propuso un servicio más amplio en el sistema terminal. El Congestion Manager agrupaba flujos en macroflows, compartía algoritmos y estado de congestión y ofrecía una interfaz a aplicaciones que no tenían por qué ser TCP.

El objetivo no era absorber todo el tráfico en una única cola. Era separar dos preguntas: ¿cuándo hay una oportunidad compatible con el estado de congestión?, y ¿qué información merece ocuparla ahora? La primera podía coordinarse en el host; la segunda seguía perteneciendo a la aplicación.

Pedir turno no significaba depositar un paquete

Una llamada a cm_request expresaba demanda. No llevaba un puntero a un búfer que el CM tuviera que conservar. Por eso el controlador no sabía qué fotograma, datagrama o mensaje acabaría usando la oportunidad. Tampoco prometía enviarlo más adelante.

Al abrirse espacio en la ventana de congestión, el CM ejecutaba cmapp_send. El callback fijaba un máximo de bytes, por lo general el path MTU. Solo entonces la aplicación componía o elegía los datos. Un codificador podía descartar una imagen atrasada, bajar la calidad o volver a empaquetar el contenido. Esa decisión tardía evitaba que una cola genérica convirtiera material viejo en una obligación de envío.

El reparto era deliberado. El CM veía solicitudes rivales y una estimación común del camino. La aplicación entendía la caducidad y el valor de su contenido. Un permiso solo unía ambos planos durante un instante; no convertía al controlador en propietario del payload.

Por la misma razón, el callback no servía como prueba de emisión. Todavía faltaban la selección del contenido, su paso por IP y la aceptación en una interfaz. Un programa podía no usarlo o podía recibirlo cuando ya había caducado.

El crédito vencía y debía cuadrarse

RFC 3124 limitaba la vida del permiso al máximo entre un RTT y un umbral de implementación. Pasado ese plazo, la aplicación no debía transmitir bajo aquel callback. El estado de congestión no era una cuenta bancaria de crédito perpetuo.

Después de actuar, el programa llamaba a cm_notify con nsent, la cantidad realmente presentada a la salida IP. Si no enviaba, debía notificar cero para devolver la oportunidad. Así, el controlador podía diferenciar el espacio concedido del espacio consumido y reasignar lo que había quedado libre.

El protocolo no suponía cooperación perfecta. Una aplicación podía cerrarse antes del cero o perder una notificación. El CM tenía que recuperarse sin paralizar las demás solicitudes. Pero tolerar una notificación ausente no autorizaba a registrar ficticiamente todos los callbacks como envíos.

Además, nsent no era una confirmación remota. Contaba datos emitidos por el host. cm_update incorporaba observaciones del receptor y distinguía entre recepción, pérdida, congestión explícita y falta de feedback. El diseño mantenía separados el permiso del scheduler, el acto local y la evidencia posterior del camino.

Macroflow: una decisión útil, no una identidad demostrada

Un macroflow permitía que varios flujos compartieran control y planificación. La aplicación podía influir en su composición porque conocía relaciones que el sistema quizá no veía. Sin embargo, agrupar no probaba que todos los paquetes recorrieran el mismo cuello de botella. Las rutas podían divergir o cambiar, y una máquina con varias interfaces podía romper la suposición.

Por eso la clave del macroflow era evidencia de una decisión local, no un certificado del camino. Para evaluar sus efectos harían falta marcas temporales, tabla de rutas, interfaz elegida y mediciones asociadas. De lo contrario, un buen modelo inicial podría sobrevivir en los registros después de dejar de ser cierto.

RFC 2581, RFC 2861 y la posterior RFC 5681 describen aspectos del comportamiento TCP; RFC 9040 volvió sobre el uso de métricas compartidas. La aportación específica de RFC 3124 fue otra: abrió a las aplicaciones un protocolo de solicitud, concesión y notificación, además de una consulta síncrona, alrededor de un scheduler común.

La buena conducta dependía de cooperación

El documento definía como bien comportada a la aplicación que enviaba solo con consentimiento del CM y declaraba todo lo enviado. Era una obligación del participante, no una barrera técnica contra el resto del host.

RFC 3124 aclaró que el Congestion Manager no imponía la conducta a todas las aplicaciones y no protegía la red frente a una máquina comprometida. El policing local o en routers quedaba fuera de alcance. Un proceso podía ignorar la API; el módulo no se convertía por existir en un árbitro inviolable.

Esa limitación marca cómo debe leerse una prueba de despliegue. Encontrar el CM instalado no demuestra que una aplicación concreta lo usara. Ver llamadas de una aplicación tampoco descarta tráfico paralelo que lo eludiera. Y una ejecución correcta del protocolo no demuestra que los paquetes compartieran realmente el camino modelado.

La adopción era opcional. Quien elegía usar la interfaz debía cumplirla, pero el rango normativo del RFC no aporta por sí solo cifras de implantación ni resultados operativos.

El valor negativo protegía lo desconocido

No todas las aplicaciones querían ceder su scheduling. La interfaz síncrona les permitía consultar mediante cm_query estimaciones de tasa, RTT y congestión y mantener su propio bucle. Cuando una estimación no era válida, la respuesta podía ser negativa. La ausencia de medida no se disfrazaba de capacidad cero.

Es un detalle pequeño con consecuencias amplias: un plano de control fiable necesita representar su ignorancia. RFC 2914 y RFC 8085 ayudan a situar las obligaciones de congestión; RFC 2481 documenta el contexto experimental de ECN y RFC 1191 el PMTU. Esas fuentes explican las dependencias intelectuales. No constituyen recibos de adopción del Congestion Manager.

La historia completa exigía varios recibos

Una auditoría necesitaría guardar la solicitud, la identidad del flujo y del macroflow, el estado del scheduler, la hora, tamaño y caducidad del callback, los datos finalmente seleccionados, cm_notify, la salida IP, la ruta y cada cm_update. La experiencia del usuario requeriría medidas adicionales.

Cada registro responde a una pregunta. La solicitud demuestra intención declarada. El callback demuestra permiso temporal. La notificación positiva demuestra un informe de emisión local. El feedback ofrece evidencia sobre el receptor o la congestión. Ninguna pieza contiene por sí sola todo el proceso.

La importancia histórica de RFC 3124 reside en esa modestia estructurada. Intentó centralizar el conocimiento escaso sobre congestión sin centralizar el significado de los datos. Una concesión coordinaba el momento; nunca fue el paquete ni su destino.

Fuentes

  1. https://www.rfc-editor.org/rfc/rfc3124.txt
  2. https://www.rfc-editor.org/info/rfc3124
  3. https://datatracker.ietf.org/doc/rfc3124/
  4. https://www.rfc-editor.org/rfc/rfc2140.txt
  5. https://www.rfc-editor.org/rfc/rfc2914.txt
  6. https://www.rfc-editor.org/rfc/rfc2581.txt
  7. https://www.rfc-editor.org/rfc/rfc2861.txt
  8. https://www.rfc-editor.org/rfc/rfc2481.txt
  9. https://www.rfc-editor.org/rfc/rfc1191.txt
  10. https://www.rfc-editor.org/rfc/rfc5681.txt
  11. https://www.rfc-editor.org/rfc/rfc8085.txt
  12. https://www.rfc-editor.org/rfc/rfc9040.txt