Resumen

  • ECT(1), junto con CE cuando corresponde, identifica tráfico L4S. No es el registro de la cola atravesada ni una muestra de latencia.
  • RFC 9332 permite que un operador envíe tráfico con identidad L4S a la cola Classic sin borrar el identificador, y que admita tráfico seleccionado no-L4S en la cola L sin cambiar su identidad ECN.
  • Koen De Schepper, Bob Briscoe —editor del documento— y Greg White especificaron además los testigos operativos: tráfico, marcas, descartes, demora media, percentil 99 y episodios de sobrecarga por cola.

El panel sabía leer un bit, no una trayectoria

La captura era correcta. El campo ECN del paquete contenía ECT(1). El error empezó después, cuando una herramienta de operaciones convirtió ese dato en tres afirmaciones invisibles: que todos los nodos lo habían puesto en la cola L, que el AQM le había dado el tratamiento previsto y que la aplicación había recibido una respuesta rápida.

Ninguna de esas tres conclusiones cabe dentro del identificador. ECT(1) ofrece a un nodo compatible una señal común para reconocer L4S. No enumera las reglas de clasificación, las colas visitadas, las revisiones del software, los cuellos de botella ni los tiempos de espera. El encabezado anuncia una condición del emisor; no lleva un diario de viaje.

RFC 9332, publicada en enero de 2023 como Experimental, describe un AQM DualQ acoplado. Hay una cola L para el tratamiento L4S y una cola C para el tráfico Classic, un AQM para cada una y una señal de congestión que las relaciona. El planificador da prioridad a L, pero debe limitarla para no dejar sin servicio a C. El objetivo de latencia de cola muy baja es parte del diseño. No convierte el identificador en un certificado de resultado.

Una excepción local que no borra la señal global

RFC 9331 define ECT(1), y CE en las circunstancias pertinentes, como identificador L4S. Un emisor que lo usa debería cumplir los requisitos del control de congestión escalable. Un nodo L4S normalmente envía esos paquetes a L.

La palabra «normalmente» importa. RFC 9332 reserva al operador la capacidad de apartar ciertos paquetes de L por política. El mismo texto exige que esa decisión no cambie el identificador de extremo a extremo. Otro operador, más adelante, debe poder leer lo que declaró el emisor y decidir por sí mismo.

Así aparece un estado perfectamente válido: ECT(1) visto; regla Y del nodo X; destino C; identificador intacto. El paquete conserva su identidad y recibe un tratamiento local distinto. Pretender que una de esas verdades anule a la otra destruye información.

También existe el caso inverso. Una red puede usar direcciones, DSCP o protocolos como DNS para admitir tráfico adicional en L, siempre que no perjudique el servicio. El nodo no debe cambiar Not-ECT o ECT(0) a ECT(1) sólo porque concedió ese trato local. Estar en L no crea identidad L4S; llevar identidad L4S no garantiza estar en L en todos los saltos.

El acoplamiento administra competencia

DualQ no consiste simplemente en pintar dos carriles. Los controles Classic suelen necesitar cierta acumulación para utilizar el enlace, mientras que los controles Scalable responden a señales ECN frecuentes con cambios de tasa menores. Si se mezclan sin protección, un flujo Scalable puede imponerse con mucha más agresividad que uno compatible con Reno.

El diseño separa las demoras de cola y acopla las señales. En la explicación de la RFC, el AQM Classic genera una probabilidad base. Su cuadrado guía la marca o el descarte Classic, mientras una versión escalada alimenta la señal acoplada de L. La cola L usa la mayor entre su señal nativa, relacionada con su demora inmediata, y la presión procedente de C.

Por eso CE no es una lectura de reloj. Puede resultar de la dinámica propia de L, del acoplamiento con C o de una condición de sobrecarga. Su función es provocar una respuesta del extremo. La demora de ese paquete es otra observación.

Las combinaciones inesperadas hacen todavía más necesario el recibo de ejecución. Para ECT(1) clasificado en C, el AQM Classic debería aplicar la probabilidad acoplada. Para ECT(0) en L, el tratamiento debe respetar tanto el control Classic como el objetivo de demora de L. Con Not-ECT, la existencia de protección frente a flujos no reactivos cambia la rama aplicable. Un contador de ECT(1) no dice cuál ocurrió.

No hay un solo reloj de latencia

El recibo de la cola tampoco equivale a la experiencia completa. La definición de demora en RFC 9332 excluye la serialización del paquete situado en cabeza y el acceso al medio. No incluye propagación, otras colas, recuperación del transporte, planificación del servidor ni trabajo de aplicación.

Un paquete puede esperar muy poco en un DualQ y aun así completar tarde la solicitud. Otro paquete Classic puede encontrar C vacía y pasar deprisa sin convertirse en L4S. Conviene separar demora de esa cola, RTT y tiempo de respuesta de la aplicación.

Las estadísticas necesitan bordes. La implementación experimental debería permitir obtener media y percentil 99 por cola e intervalo; puede conservar un máximo para diagnóstico. Una media baja oculta una cola dañina para pocos paquetes. Un máximo sin ventana deja un incidente antiguo encendido para siempre. Sin intervalo, denominador y lugar de medición, el número no se puede auditar.

La ubicación también limita la promesa. Un DualQ en el acceso puede eliminar un cuello importante, pero no controla un planificador Wi-Fi, un túnel, otro operador o el servidor. «Ruta L4S» es una afirmación distribuida y necesita evidencia de varios actores.

Cuando marcar al cien por cien ya no alcanza

Bajo carga ordinaria y sensible a congestión, el acoplamiento busca preservar una cola L somera sin matar el tráfico Classic. La prioridad tiene que ser condicional: una L permanentemente ocupada podría retrasar incluso una consulta DNS o una ventana inicial en C.

La sobrecarga persistente abre otro régimen. Al llegar al 100 % de marcas ECN, el sistema ya no puede aumentar la señal marcando más. RFC 9332 exige que una implementación que detecta sobrecarga introduzca descarte de tipo Classic para ambos tipos de tráfico ECN hasta que el episodio termine. También recomienda informar inicio y duración con histéresis para evitar una tormenta de avisos.

La identidad ECT(1) puede permanecer igual antes, durante y después. El riesgo de descarte y la demora no. El estado operativo necesita un reloj para la sobrecarga, no un distintivo L4S atemporal.

El límite preciso de una obra colectiva

Los autores de RFC 9332 son Koen De Schepper, Bob Briscoe y Greg White; Briscoe figura además como editor. Los agradecimientos y contribuciones muestran una comunidad aún mayor. El texto no autoriza el relato de un inventor solitario ni permite atribuirle las decisiones de una red concreta.

El perfil oficial de IETF Datatracker consultado para este trabajo documenta la trayectoria de Briscoe en ECN, controles de congestión y transportes. Su sitio personal aporta una biografía pública y la imagen de referencia. Son pruebas de identidad y de autoría técnica, no de adopción comercial ni de rendimiento actual.

Lo valioso es la frontera: un identificador pequeño mantiene significado interoperable, cada red conserva su discreción local y la implementación debe exponer estadísticas para todo lo que el bit no puede afirmar. La especificación inicial mínima de Heng Lu describe esa economía. La primacía del código ejecutado añade la regla probatoria: el documento prueba el mecanismo previsto; la rama que corrió sólo aparece en la ejecución.

El problema de agencia surge cuando la métrica más barata domina el relato. Un fabricante puede enseñar con facilidad cuántos ECT(1) vio. Exportar reglas de clasificación, contadores por cola y demora de cola larga cuesta más al operador. El cliente soporta la degradación. Si una compra acepta «L4S habilitado» como sinónimo de servicio, el actor con la evidencia más débil adquiere la autoridad más amplia.

Seis recibos, cada uno con su dueño

El emisor conserva transporte, implementación y versión del control de congestión, decisión de usar ECT(1), límite de flujo y tiempo. El punto de observación conserva campo ECN, encapsulación, interfaz, dirección, sello temporal e integridad de captura.

El clasificador registra equipo, software, revisión de política, regla coincidente, identificadores auxiliares y resultado L o C. La cola identifica la instancia AQM, entrada y salida, selección del planificador y rama usada para combinaciones inesperadas.

El recibo de congestión une presión nativa y acoplada con marcas CE, descartes ECN y no-ECN, entrada y salida de sobrecarga y los conteos de paquetes llegados, presentados al AQM y transmitidos. Esos tres conteos distinguen el descarte por límite del descarte proactivo.

Por último, el recibo de rendimiento guarda utilización, media, percentil 99, máximo opcional, intervalo y definición del histograma por cola. RTT y respuesta de aplicación conservan relojes propios. Juntos no debilitan ECT(1): impiden pedirle que testifique sobre hechos que nunca observó.

Fuentes