Notificación de congestión explícita (ECN)

La notificación de congestión explícita o ECN (Explicit Congestion Notification) es una extensión del Protocolo de Internet y del Protocolo de control de transmisión y se define en RFC 3168 (2001). ECN permite la notificación de extremo a extremo de la congestión de la red sin descartar paquetes. ECN es una función opcional que se puede usar entre dos terminales habilitados para ECN cuando la infraestructura de red subyacente también lo admite.

Convencionalmente, las redes TCP/IP señalan la congestión descartando paquetes. Cuando ECN se negocia con éxito, un enrutador compatible con ECN puede establecer una marca en el encabezado IP en lugar de descartar un paquete para indicar una congestión inminente. El receptor del paquete hace eco de la indicación de congestión al remitente, que reduce su tasa de transmisión como si detectara un paquete descartado.

En lugar de responder correctamente o ignorar los bits, algunos equipos de red obsoletos o defectuosos históricamente han perdido o dañado paquetes que tienen bits ECN configurados. A partir de 2015, las mediciones sugirieron que la fracción de servidores web en la Internet pública para los que la configuración de ECN evita las conexiones de red se había reducido a menos del 1%.

El soporte pasivo ha existido en Ubuntu Linux desde 12.04 y en Windows Server desde 2012. El soporte pasivo en los sitios web más populares aumentó del 8,5 % en 2012 a más del 70 % en mayo de 2017. La adopción en Internet ahora requiere que los clientes soliciten activamente ECN. En junio de 2015, Apple anunció que ECN estará habilitado de forma predeterminada en sus productos admitidos y futuros, para ayudar a impulsar la adopción de la señalización ECN en toda la industria.

Operación

ECN requiere soporte específico tanto en la capa de Internet como en la capa de transporte por las siguientes razones:

• En TCP/IP, los enrutadores operan dentro de la capa de Internet, mientras que la tasa de transmisión es manejada por los puntos finales en la capa de transporte.
• La congestión puede ser manejada solo por el transmisor, pero dado que se sabe que ocurrió solo después de que se envió un paquete, debe haber un eco de la indicación de congestión del receptor al transmisor.

Sin ECN, el eco de indicación de congestión se logra indirectamente mediante la detección de paquetes perdidos. Con ECN, la congestión se indica configurando el campo ECN dentro de un paquete IP en CE y el receptor la devuelve al transmisor configurando los bits adecuados en el encabezado del protocolo de transporte. Por ejemplo, cuando se usa TCP, la indicación de congestión se repite configurando el bit ECE.

Funcionamiento de ECN con IP

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

• 00– Transporte sin capacidad ECN, sin ECT
• 10– Transporte con capacidad ECN, ECT(0)
• 01– Transporte con capacidad ECN, ECT(1)
• 11– Congestión Encontrada, 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 administración activa de colas (AQM) (por ejemplo, una cola que usa detección temprana aleatoria (RED)) que está experimentando congestión y el enrutador correspondiente es compatible con ECN, puede cambiar el punto de código en CElugar de descartar el paquete. Este acto se conoce como "marcado" y su propósito es informar al punto final receptor de la congestión inminente. En el punto final de recepción, esta indicación de congestión es manejada por el protocolo de la capa superior (protocolo de la capa de transporte) y debe devolverse al nodo transmisor para indicarle que reduzca su velocidad de transmisión.

Debido a que la indicación CE solo puede ser manejada de manera efectiva por un protocolo de capa superior que la admita, ECN solo se usa 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 de transmisión..

Funcionamiento de ECN con TCP

TCP admite ECN utilizando dos indicadores en el encabezado TCP. El primero, ECN-Echo (ECE) se utiliza para devolver la indicación de congestión (es decir, señalar al remitente que reduzca la velocidad de transmisión). El segundo, ventana de congestión reducida (CWR), para reconocer que se recibió el eco de indicación de congestión. El uso de ECN en una conexión TCP es opcional; para que se utilice ECN, debe negociarse en el establecimiento de la conexión mediante la inclusión de opciones adecuadas en los segmentos SYN y SYN-ACK.

Cuando se ha negociado ECN en una conexión TCP, el remitente indica que los paquetes IP que transportan segmentos TCP de esa conexión transportan tráfico desde un transporte con capacidad ECN marcándolos con un punto de código ECT. Esto permite que los enrutadores intermedios que admiten ECN marquen esos paquetes IP con el punto de código CE en lugar de eliminarlos para señalar una congestión inminente.

Al recibir un paquete IP con el punto de código Congestión experimentada, el receptor TCP repite esta indicación de congestión utilizando el indicador ECE en el encabezado TCP. Cuando un punto final recibe un segmento TCP con el bit ECE, reduce su ventana de congestión como si fuera una caída de paquete. Luego reconoce la indicación de congestión enviando un segmento con el bit CWR establecido.

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

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

Paquetes de control ECN y TCP

Dado que el Protocolo de control de transmisión (TCP) no realiza control de congestión en los paquetes de control (segmentos ACK, SYN, FIN puros), los paquetes de control generalmente no se marcan como compatibles con ECN.

Una propuesta de 2009 sugiere marcar los paquetes SYN-ACK como compatibles con ECN. Se ha demostrado que esta mejora, conocida como ECN+, proporciona mejoras drásticas en el rendimiento de las conexiones TCP de corta duración.

Funcionamiento de ECN con otros protocolos de transporte

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

Es posible usar ECN con protocolos superpuestos 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 usaban ECN. Los protocolos basados ​​en UDP más recientes, como QUIC, utilizan ECN para el control de la congestión.

Efectos sobre el rendimiento

Dado que ECN solo es efectivo en combinación con una política de Active Queue Management (AQM), los beneficios de ECN dependen del AQM preciso que se utilice. Sin embargo, algunas observaciones parecen mantenerse en diferentes AQM.

Como era de esperar, ECN reduce la cantidad de paquetes descartados por una conexión TCP, lo que, al evitar una retransmisión, reduce la latencia y especialmente la fluctuación. Este efecto es más drástico cuando la conexión TCP tiene un solo segmento pendiente, cuando puede evitar un tiempo de espera de RTO; este suele ser el caso de las conexiones interactivas, como los inicios de sesión remotos y los protocolos transaccionales, como las solicitudes HTTP, la fase conversacional de SMTP o las solicitudes SQL.

Los efectos de ECN en el rendimiento masivo son menos claros porque las implementaciones modernas de TCP son bastante buenas para reenviar segmentos descartados de manera oportuna cuando la ventana del remitente es grande.

Se ha descubierto que el uso de ECN es perjudicial para el rendimiento en redes altamente congestionadas cuando se usan algoritmos AQM que nunca descartan paquetes. Las implementaciones modernas de AQM evitan este escollo descartando en lugar de marcar los paquetes con una carga muy alta.

Implementaciones

Muchas implementaciones modernas del conjunto de protocolos TCP/IP tienen cierto soporte para ECN; sin embargo, generalmente se envían con ECN deshabilitado.

Soporte ECN en TCP por hosts

Microsoft Windows

Las versiones de Windows desde Windows Server 2008 y Windows Vista admiten ECN para TCP. Desde Windows Server 2012, está habilitado de forma predeterminada en las versiones de Windows Server, porque se utiliza el Protocolo de control de transmisión del centro de datos (DCTCP). En versiones anteriores de Windows y versiones que no son de servidor, está deshabilitado de forma predeterminada.

La compatibilidad con ECN se puede habilitar mediante un comando de shell como netsh interface tcp set global ecncapability=enabled.

BSD

En FreeBSD, ECN para TCP se puede configurar mediante net.inet.tcp.ecn.enable sysctl. Por defecto, está habilitado solo para las conexiones entrantes que lo soliciten. También puede habilitarse para todas las conexiones o deshabilitarse por completo.

NetBSD 4.0 implementa soporte ECN para TCP; se puede activar a través de la interfaz sysctl configurando 1 como valor para el parámetro sysctl net.inet.tcp.ecn.enable.

Asimismo, el sysctl net.inet.tcp.ecn se puede utilizar en OpenBSD.

Linux

Desde la versión 2.4.20 del kernel de Linux, lanzada en noviembre de 2002, Linux admite tres modos de trabajo de ECN para TCP, configurados a través de la interfaz sysctl configurando el parámetro /proc/sys/net/ipv4/tcp_ecn en uno de los siguientes valores:

• 0: deshabilitar ECN y no iniciarlo ni aceptarlo
• 1: habilite ECN cuando lo soliciten las conexiones entrantes, y también solicite ECN en los intentos de conexión salientes
• 2: (predeterminado) habilite ECN cuando lo soliciten las conexiones entrantes, pero no solicite ECN en las conexiones salientes

A partir de la versión 4.1 del kernel de Linux, lanzada en junio de 2015, el mecanismo tcp_ecn_fallback, como se especifica en la sección 6.1.1.1 de RFC 3168, está habilitado de forma predeterminada cuando ECN está habilitado (el valor de 1). El mecanismo de respaldo intenta la conectividad ECN en la configuración inicial de las conexiones salientes, con un elegante respaldo para transmisiones sin capacidad ECN, lo que mitiga los problemas con hosts o firewalls que no toleran ECN.

Mac OS X

Mac OS X 10.5 y 10.6 implementan soporte ECN para TCP. Se controla mediante las variables booleanas sysctl net.inet.tcp.ecn_negotiate_in y net.inet.tcp.ecn_initiate_out. La primera variable habilita ECN en conexiones entrantes que ya tienen indicadores ECN configurados; el segundo intenta iniciar conexiones salientes con ECN habilitado. Ambas variables tienen un valor predeterminado de 0, pero se pueden establecer en 1 para habilitar el comportamiento respectivo.

En junio de 2015, Apple Inc. anunció que OS X 10.11 tendría ECN activado de forma predeterminada, pero el sistema operativo se envió sin ese comportamiento predeterminado. En macOS Sierra, ECN está habilitado para la mitad de las sesiones TCP.

IOS

En junio de 2015, Apple Inc. anunció que iOS 9, su próxima versión de iOS, sería compatible con ECN y lo tendría activado de forma predeterminada. La negociación TCP ECN está habilitada en el 5 % de las conexiones seleccionadas aleatoriamente a través de Wi-Fi/Ethernet en iOS 9 y el 50 % de las conexiones seleccionadas aleatoriamente a través de Wi-Fi/Ethernet y algunos operadores celulares en iOS 10 y el 100 % para iOS 11

Solaris

El kernel de Solaris admite tres estados de ECN para TCP:

• nunca – sin ECN
• activo – usar ECN
• Pasivo: solo anuncie el soporte de ECN cuando se le solicite.

A partir de Solaris 11.4, el comportamiento predeterminado es activo. El uso de ECN se puede modificar mediante ipadm set-prop -p ecn=active tcp.

Soporte ECN en IP por enrutadores

Dado que el marcado ECN en los enrutadores depende de alguna forma de administración activa de colas, los enrutadores deben configurarse con una disciplina de cola adecuada para realizar el marcado ECN.

Los enrutadores 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 de 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, usando la disciplina sfb, usando la disciplina CoDel Fair Queuing (fq_codel) o la disciplina de cola CAKE.

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, en particular RED y Blue. FreeBSD 11 incluía la implementación de disciplinas de colas CoDel, PIE, FQ-CoDel y FQ-PIE en el marco ipfw/dummynet con capacidad de marcado ECN.

Centro de datos TCP

El Protocolo de control de transmisión del centro de datos (Data Center TCP o DCTCP) utiliza ECN para mejorar el algoritmo de control de congestión del Protocolo de control de transmisión. 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, utilizando ECN, puede medir el alcance de la congestión.

DCTCP modifica el receptor TCP para transmitir siempre la marca ECN exacta de los paquetes entrantes a costa de ignorar una función que está destinada a preservar la confiabilidad de la señalización. Esto hace que un remitente DCTCP sea vulnerable a la pérdida de ACK del receptor, que no tiene ningún mecanismo para detectar o afrontar. A partir de julio de 2014, los algoritmos que brindan una retroalimentación del receptor equivalente o mejor en un enfoque más confiable son un tema de investigación activo.