Resumen

  • ECN no elimina la pérdida. Permite que una cola activa sustituya, bajo condiciones definidas, una pérdida usada como señal por una marca explícita en un paquete cuyo transporte ha declarado que sabe responder.
  • El mecanismo es un circuito cerrado: el emisor declara capacidad, el router marca, el receptor devuelve la evidencia y el emisor reduce la carga.
  • Desde RFC 2481 y RFC 3168 hasta las reglas para túneles y L4S, la dificultad no fue encontrar dos bits, sino conservar un significado compartido entre sistemas administrados por actores distintos.

Antes de la marca, la cola tenía que causar daño

El control de congestión aprendió primero a interpretar una ausencia. Cuando una cola se llenaba y descartaba un paquete, el emisor infería presión y retrocedía. Ese mecanismo ayudó a evitar el colapso de congestión, pero hizo que la pérdida cumpliera dos funciones: perjudicar la transferencia y describir el estado que la perjudicó.

RFC 2309, publicada en abril de 1998, explica por qué el descarte al final de la cola es un testigo tardío. La cola puede mantenerse llena, sumar demora y eliminar varios paquetes de una ráfaga. Diversos flujos pueden reducirse al mismo tiempo y volver a crecer al mismo tiempo. El documento recomienda la gestión activa de colas para actuar antes del desbordamiento y mantener menor la cola media.

Descartar antes sigue siendo descartar. ECN añadió otra posibilidad: si el transporte declara que entiende una notificación explícita, la cola puede modificar un código del paquete en vez de eliminarlo. El paquete llega con una huella del cuello de botella que atravesó.

Ese es el cambio histórico: el daño dejó de ser la única forma de testimonio.

Cuatro valores y varias autoridades

RFC 3168, de septiembre de 2001 y en la vía de estándares, define cuatro valores en el campo ECN de dos bits: Not-ECT, ECT(0), ECT(1) y CE. ECT declara un transporte capaz de ECN; CE indica congestión experimentada.

Aunque el router realiza la edición visible, ECN no es una función aislada del router. El emisor establece primero que su transporte puede reaccionar y envía paquetes elegibles. Una cola activa puede aplicar CE donde habría usado un descarte como indicación de congestión. El receptor devuelve la información. El emisor reduce su ventana de congestión y confirma que ha procesado el aviso.

Cada parte controla algo que las demás no controlan. El router conoce su cola, pero no todo el estado de la aplicación. El receptor ve la marca, pero no fija directamente la carga del emisor. El emisor decide la tasa, pero no observa el cuello de botella. La señal cruza esas fronteras como una observación pequeña y verificable.

La pérdida no desaparece. Un paquete Not-ECT no promete una reacción a la marca. La congestión severa puede exigir descartes. Los fallos de ruta, la corrupción y las políticas de control continúan existiendo. La afirmación correcta es limitada: para tráfico elegible y bajo las reglas previstas, marcar puede sustituir un descarte cuya finalidad era anunciar congestión.

De propuesta a contrato incremental

RFC 2481 propuso ECN como experimento en enero de 1999. RFC 3168 la sustituyó dos años después y especificó la incorporación a IP y TCP. El paso no fue una simple reserva de bits. Definió negociación, eco, respuesta del emisor y convivencia con tráfico sin ECN.

El despliegue incremental está dentro del diseño. Un emisor no puede dar por hecho que todos los pares y todos los caminos preservan la señal. Un router no puede marcar cualquier paquete. La red debe conservar el descarte como mecanismo de protección. La compatibilidad hacia atrás es, por tanto, una condición para que un primer adoptante no transfiera un riesgo nuevo al resto.

La inferencia operativa es clara: contar funciones activadas no cuenta circuitos que funcionan. Un sistema operativo puede negociar ECN y atravesar un cuello de botella que nunca marca. Un router puede marcar y un túnel borrar CE. El camino puede preservar CE y el emisor responder mal. La unidad de éxito es el recorrido completo.

El nonce y la honestidad del receptor

Una señal explícita plantea una pregunta de incentivos: ¿podría el receptor ocultar marcas para evitar que su emisor se ralentice? RFC 3540, experimental y publicada en 2003, propuso un nonce ECN. El emisor alternaba el código ECT y usaba la respuesta acumulada para detectar la supresión de señales.

El nonce no se convirtió en el uso duradero de ECT(1), pero dejó visible el problema. Una marca pide a un actor que sacrifique tasa propia para proteger un recurso compartido. La red puede producir evidencia; no puede asumir obediencia.

RFC 8311, de enero de 2018, pasó RFC 3540 a histórica y relajó restricciones para experimentar con ECN. ECT(1) quedó disponible para otros usos experimentales. El campo no estaba vacío: hubo que cerrar su significado anterior antes de reutilizarlo.

Los túneles custodian la evidencia

En un túnel, el paquete interior queda envuelto por una cabecera exterior. Si la ruta exterior encuentra congestión, la salida tiene que reconciliar ambos estados. Si elimina la marca exterior, el paquete interior reaparece con un historial falsamente limpio. Si combina mal los estados, puede inventar una señal.

RFC 6040, publicada en 2010 en la vía de estándares, define cómo transportar ECN a través de la encapsulación y la desencapsulación. Sus reglas técnicas expresan una finalidad sencilla: no borrar ni fabricar el significado de la congestión al cruzar capas.

Es un hecho de procesamiento y, por inferencia, una regla de custodia. La entrada elige el estado exterior, la ruta puede marcarlo y la salida decide qué conserva el paquete interior. Por eso un VPN, un núcleo móvil o una superposición de centro de datos son límites de medición. Dos extremos compatibles no prueban que un túnel concreto preserve ECN.

Experimentar sin fingir certeza

RFC 4774, una práctica recomendada de 2006, regula semánticas alternativas del campo ECN. Un uso diferente necesita identificación, convivencia segura y límites para el despliegue parcial. RFC 8311 relajó reglas de RFC 3168 para permitir experimentos en los que una marca no tenga que equivaler siempre a una pérdida clásica. Permitir un experimento no garantiza su resultado en todos los caminos.

Esa diferencia es central en la arquitectura L4S de 2023. RFC 9330 describe el conjunto. RFC 9331, experimental, utiliza ECT(1) como identificador de L4S y CE como señal frecuente. RFC 9332, también experimental, especifica una gestión activa de dos colas acopladas.

L4S no es ECN clásico con un umbral reducido. Sus controles escalables deben reaccionar a marcas frecuentes sin tratar cada marca como una pérdida clásica. La red aísla el tratamiento de baja latencia de la demora acumulada por tráfico clásico y acopla la indicación de congestión para compartir capacidad. RFC 9330 lo presenta como separación de latencia, no como prioridad simple de ancho de banda.

La arquitectura requiere tres piezas: respuesta compatible en el emisor, tratamiento de cola en el cuello de botella e identificador. ECT(1) por sí solo no entrega la promesa. Copiar la marca sin copiar la respuesta rompe la convivencia.

Pruebas, inferencias e incógnitas

La secuencia de RFC prueba una evolución concreta: la gestión activa motivó una señal temprana; un experimento se volvió mecanismo de estándares; se ensayó la integridad del retorno; túneles y semánticas alternativas recibieron reglas; L4S reutilizó el campo dentro de una arquitectura mayor.

No prueba que la mayoría de los caminos públicos preserven ECN en 2026. No identifica qué equipos intermedios blanquean los bits. No demuestra que cada cuello de botella marque de forma útil ni que L4S vaya a ser universal. Son incógnitas de despliegue y medición.

El logro duradero es más preciso: la red puede revelar presión antes de destruir el paquete que la revela. Eso obliga a declarar quién crea la evidencia, quién la conserva y quién actúa.

El paquete sobrevive; la obligación de responder permanece.

Fuentes