Notificación explícita de congestión

Nota: esto describe el funcionamiento de ECN antes de la definición de L4S en RFC 9330 , que reserva el uso del punto de código para el tráfico L4S. 01

ECN utiliza los dos bits menos significativos (los de más a la derecha) del campo Clase de tráfico en el encabezado IPv4 o IPv6 para codificar cuatro puntos de código diferentes:

• 00 – Transporte no compatible con ECN, no compatible con ECT
• 01 – Transporte con capacidad ECN(1), ECT(1)
• 10 – Transporte con capacidad ECN(0), ECT(0)
• 11 – Experimentó congestión, CE.

Cuando ambos extremos admiten ECN, marcan sus paquetes con ECT(0) o ECT(1). Los enrutadores tratan los puntos de código ECT(0) y ECT(1) como equivalentes. Si el paquete atraviesa una cola de gestión de cola activa (AQM) (por ejemplo, una cola que utiliza detección temprana aleatoria (RED)) que está experimentando congestión y el enrutador correspondiente admite ECN, puede cambiar el punto de código a CEen lugar de descartar el paquete . Esta acción se denomina marcado y su propósito es informar al extremo receptor de la inminente congestión . En el extremo receptor, esta indicación de congestión es manejada por el protocolo de capa superior ( protocolo de capa de transporte ) y debe ser devuelta al nodo transmisor para indicarle que reduzca su tasa de transmisión.

Dado que la indicación CE solo puede ser manejada eficazmente por un protocolo de capa superior que la admita, ECN solo se utiliza junto con protocolos de capa superior, como TCP , que admiten el control de congestión y tienen un método para hacer eco de la indicación CE al punto final transmisor.

TCP admite ECN mediante dos indicadores en la cabecera TCP. El primero, ECN-Echo (ECE), se utiliza para devolver la indicación de congestión (es decir, para indicar al remitente que reduzca la velocidad de transmisión). El segundo, Congestion Window Reduced (CWR), confirma la recepción de la indicación de congestión. El uso de ECN en una conexión TCP es opcional; para que se utilice, debe negociarse al establecer la conexión incluyendo las opciones adecuadas en los segmentos SYN y SYN-ACK.

Cuando se negocia ECN en una conexión TCP, el remitente indica que los paquetes IP que contienen segmentos TCP de dicha conexión transportan tráfico de un transporte compatible con ECN, marcándolos con un código ECT. Esto permite que los enrutadores intermedios compatibles con ECN marquen esos paquetes IP con el código CE en lugar de descartarlos, para así señalar una posible congestión.

Al recibir un paquete IP con el código de Congestión Experimentada ( CWR), el receptor TCP devuelve esta indicación de congestión mediante el indicador ECE en la cabecera TCP. Cuando un extremo recibe un segmento TCP con el bit ECE, reduce su ventana de congestión como si se tratara de un paquete descartado. A continuación, confirma la indicación de congestión enviando un segmento con el bit CWR activado.

Un nodo sigue transmitiendo segmentos TCP con el bit ECE activado hasta que recibe un segmento con el bit CWR activado.

Para ver los paquetes afectados con tcpdump , utilice el predicado de filtro .(tcp[13] & 0xc0 != 0)

ECN también se define para otros protocolos de la capa de transporte que realizan control de congestión, en particular DCCP y el Protocolo de Transmisión de Control de Flujo (SCTP). El principio general es similar al de TCP, aunque los detalles de la codificación en la red difieren.

Es posible utilizar ECN con protocolos que se superponen a UDP . Sin embargo, UDP requiere que la aplicación realice el control de congestión, y los primeros protocolos basados ​​en UDP, como DNS, no utilizaban ECN. Los protocolos basados ​​en UDP más recientes, como QUIC, sí utilizan ECN para el control de congestión.

Dado que el marcado ECN en los enrutadores depende de algún tipo de gestión activa de colas , los enrutadores deben configurarse con una disciplina de cola adecuada para poder realizar el marcado ECN.

Los routers Cisco IOS realizan el marcado ECN si están configurados con la disciplina de cola WRED desde la versión 12.2(8)T.

Los enrutadores Linux realizan el marcado ECN si están configurados con una de las disciplinas de cola RED o GRED con un parámetro ecn explícito, mediante el uso de la disciplina sfb , mediante el uso de la disciplina CoDel Fair Queuing (fq_codel) o la disciplina de cola CAKE ^{[ 27 ]} .

Las implementaciones modernas de BSD, como FreeBSD , NetBSD y OpenBSD , admiten el marcado ECN en la implementación de colas ALTQ para varias disciplinas de colas , especialmente RED y Blue . FreeBSD 11 incluyó la implementación de las disciplinas de colas CoDel , PIE, FQ-CoDel y FQ-PIE en un marco con capacidad de marcado ECN. ^{[ 28 ]}ipfwdummynet

El Protocolo de Control de Transmisión de Centros de Datos ( TCP de Centros de Datos o DCTCP ) utiliza ECN para mejorar el algoritmo de control de congestión del Protocolo de Control de Transmisión . ^{[ 29 ]} Se utiliza en redes de centros de datos . Mientras que el algoritmo de control de congestión TCP estándar solo puede detectar la presencia de congestión, DCTCP, mediante ECN, puede medir el grado de congestión. ^{[ 30 ]}

DCTCP modifica el receptor TCP para que siempre retransmita la marcación ECN exacta de los paquetes entrantes, a costa de ignorar una función destinada a preservar la fiabilidad de la señalización. Esto hace que un emisor DCTCP sea vulnerable a la pérdida de ACKs del receptor, para lo cual no tiene ningún mecanismo que pueda detectar o gestionar. ^{[ 31 ]} A partir de julio de 2014 Los algoritmos que proporcionan una retroalimentación al receptor equivalente o mejor en un enfoque más fiable son un tema de investigación activo. ^{[ 31 ]}