Resumen

  • AccECN convierte al receptor en un reflector mecánico de indicaciones ECN y deja fuera de alcance la respuesta de control de congestión.
  • El contador ACE de tres bits sobrevive donde una opción TCP puede desaparecer; los contadores de bytes de 24 bits son más ricos, pero dependen del espacio y del camino.
  • La operación segura exige documentar cómo se reconstruyó el historial y qué decidió el emisor, sin presentar una marca CE como medición directa de una cola.

La cifra que llega al emisor

El ECN clásico de TCP podía decir que hubo congestión, pero no cuántos paquetes de una ventana de ida y vuelta habían sido marcados. Ese límite es insuficiente para respuestas proporcionales como DCTCP o para entornos escalables como L4S. RFC 9768, publicado en abril de 2026 como Standards Track, actualiza la negociación y el canal de retorno de RFC 3168.

La actualización no prescribe un algoritmo de control de congestión. Su unidad arquitectónica es menor y más reusable: el receptor cuenta los codepoints que recibe y devuelve estado; el emisor compara ese estado con lo que transmitió y elige la respuesta local. Por eso el RFC habla de un reflector mecánico genérico.

Este reparto permite que un nuevo algoritmo aparezca en el emisor sin convertir al receptor en intérprete de cada política futura. También delimita la atribución: el receptor no “ordenó bajar el ritmo” por el mero hecho de devolver un aumento del contador.

ACE: esencial, pequeño y modular

AccECN reutiliza tres banderas TCP para el AccECN Counter. ACE transporta los tres bits bajos del contador de paquetes CE del receptor. El estado se repite, de modo que perder un ACK no destruye necesariamente toda la noticia. Sin embargo, ocho estados implican vueltas frecuentes.

Si el último valor observado fue seis y el siguiente es uno, el incremento modular mínimo es tres. Una pausa larga de ACK podría ocultar once, diecinueve u otra cantidad congruente. El estándar obliga a generar retornos con suficiente frecuencia y recomienda límites más estrictos cuando hay datos pendientes, pero una red puede perder, filtrar o retrasar esos ACK.

ACE cuenta paquetes TCP aceptables marcados CE, incluidos controles y retransmisiones salvo el SYN. No mide bytes únicos de aplicación. Ese detalle explica por qué un contador de paquetes puede avanzar sin una cantidad equivalente de datos nuevos.

Tres libros de bytes

La opción AccECN añade contadores de 24 bits para bytes de carga útil recibidos como CE, ECT(0) y ECT(1). Excluye cabeceras, pero vuelve a contar carga retransmitida porque registra recepciones. Su gran módulo tolera interrupciones de feedback que serían ambiguas para ACE.

La precisión adicional tiene otra superficie de fallo. Las opciones TCP compiten por espacio. Si no caben la opción mínima y dos bloques SACK, SACK tiene prioridad. Un middlebox puede retirar opciones desconocidas. Un proxy divide la conexión. El offload puede reagrupar paquetes antes del punto de observación. La opción puede pasar al inicio y desaparecer después.

Por eso la opción complementa, pero no sustituye, a ACE. La primera aporta detalle condicional; el segundo ofrece continuidad más tosca. El emisor mantiene líneas base y reconcilia diferencias modulares entre ambos canales.

La negociación también cuenta

Las combinaciones AE, CWR y ECE en el three-way handshake anuncian AccECN y permiten volver a ECN clásico o a no usar ECN con pares antiguos. Determinados patrones reflejados o inválidos revelan un camino roto. La opción AccECN no se envía en el SYN inicial por falta de espacio; se prueba en el SYN/ACK y en el primer ACK.

Los contadores parten de valores no nulos para ayudar al procesamiento sin estado y delatar dispositivos que borran bits. Pero verificar una única cifra exacta bloquearía futuras extensiones. Incluso un primer ACE cero puede ser legítimo por reordenamiento. La prueba correcta busca transformaciones incompatibles, no castiga cada valor inesperado.

El mangling puede ser asimétrico. El emisor de datos sabe qué ECN puso en los paquetes y, por tanto, está mejor situado para validar el retorno. El receptor sólo debe reflejar mecánicamente los campos de segmentos aceptables. Las comprobaciones TCP, reforzadas por las reglas de challenge ACK, impiden que tráfico inválido avance libremente los contadores.

De la evidencia a la acción

Cuando ACE y los bytes no concuerdan, el emisor examina retransmisiones, unidades, ACK perdidos, wrap, disponibilidad de la opción y cambios del camino. Si el contador CE de bytes aumenta de una forma que el contador de paquetes no puede respaldar y no queda explicación válida, puede dejar de usar ECT en esa mitad de la conexión.

Eso es una decisión de seguridad local, no una sentencia sobre la causa. CE confirma que el paquete llegó con ese codepoint; no nombra la cola, el umbral, el operador ni el impacto en el usuario. El descenso posterior del caudal aún puede depender del algoritmo de congestión, la demanda de la aplicación, la pérdida, el pacing o el flow control.

El recibo operativo debe ser direccional: flags del handshake, ECN enviados y recibidos, secuencia ACE, deltas modulares, bases de los tres contadores de bytes, forma y presencia de la opción, huecos y reordenamiento de ACK, presión de SACK, retransmisiones, offload, proxy, validación, desactivación de ECT y algoritmo del emisor. La telemetría de cola y servicio se adjunta como evidencia distinta.

Las pruebas adversarias deben perder ACK individuales y ráfagas, forzar wrap, reordenar el primer ACK, retirar la opción a mitad de conexión, saturar el espacio con SACK, poner a cero bits del handshake y modificar ECN sólo en una dirección. El objetivo no es conservar siempre precisión total; es degradarse de manera explicable sin inventar certeza.

Fuentes