La Notificación Explícita de Congestión ( ECN ) es una extensión del Protocolo de Internet y del Protocolo de Control de Transmisión y se define en RFC 3168 (2001). La ECN permite la notificación de extremo a extremo de la congestión de la red sin perder paquetes. La ECN es una función opcional que se puede utilizar entre dos puntos finales habilitados para ECN cuando la infraestructura de red subyacente también lo admite.
Tradicionalmente, las redes TCP/IP indican la congestión descartando paquetes. Cuando se negocia con éxito el ECN, un enrutador que lo admita puede colocar una marca en el encabezado IP en lugar de descartar un paquete para señalar una congestión inminente. El receptor del paquete repite la indicación de congestión al remitente, que reduce su velocidad de transmisión como si detectara un paquete descartado.
En lugar de responder adecuadamente o ignorar los bits, algunos equipos de red obsoletos o defectuosos históricamente han descartado o deformado paquetes que tienen bits ECN configurados. [1] [2] [3] A partir de 2015 [update], las mediciones sugirieron que la fracción de servidores web en Internet público para los cuales la configuración de ECN impide las conexiones de red se había reducido a menos del 1%. [4]
El soporte pasivo existe en Ubuntu Linux desde la versión 12.04 y en Windows Server desde 2012. [5] El soporte pasivo en los sitios web más populares ha aumentado del 8,5 % en 2012 a más del 70 % en mayo de 2017. [5] La adopción en Internet ahora requiere que los clientes soliciten activamente ECN. En junio de 2015, Apple anunció que ECN se habilitará de forma predeterminada en sus productos compatibles y futuros, para ayudar a impulsar la adopción de la señalización ECN en toda la industria. [6]
ECN requiere soporte específico tanto en la capa de Internet como en la capa de transporte por las siguientes razones:
Sin ECN, la 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 (Congestión experimentada) y el receptor la devuelve al transmisor configurando los bits adecuados en el encabezado del protocolo de transporte. Por ejemplo, cuando se utiliza TCP, la indicación de congestión se devuelve configurando el bit ECE.
ECN utiliza los dos bits menos significativos (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 ECT01– Transporte con capacidad ECN(1), ECT(1)10– Transporte con capacidad ECN(0), ECT(0)11– Congestión experimentada, CE.Cuando ambos puntos finales 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 . Este acto se conoce como "marcado" y su propósito es informar al punto final receptor de una congestión inminente . En el punto final receptor, esta indicación de congestión es manejada por el protocolo de capa superior ( protocolo de capa de transporte ) y necesita ser devuelta al nodo transmisor para indicarle que reduzca su velocidad de transmisión.
Debido a que la indicación CE solo puede manejarse de manera efectiva mediante 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 de transmisión.
TCP admite ECN mediante el uso de dos indicadores en el encabezado 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), se utiliza para confirmar que se recibió la indicación de congestión. El uso de ECN en una conexión TCP es opcional; para que se utilice ECN, debe negociarse al establecer 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 descartarlos para señalar una congestión inminente.
Al recibir un paquete IP con el punto de código Congestion Experienced , el receptor TCP devuelve esta indicación de congestión mediante 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 se tratara de un paquete descartado. Luego, reconoce la indicación de congestión enviando un segmento con el bit CWR activado.
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 , utilice el predicado de filtro (tcp[13] & 0xc0 != 0).
Dado que el Protocolo de control de transmisión (TCP) no realiza control de congestión en los paquetes de control (segmentos ACK, SYN y FIN puros), los paquetes de control generalmente no se marcan como compatibles con ECN.
Una propuesta de 2009 [7] sugiere marcar los paquetes SYN-ACK como compatibles con ECN. Se ha demostrado que esta mejora, conocida como ECN+, proporciona mejoras espectaculares en el rendimiento de las conexiones TCP de corta duración. [8]
El 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 TCP, aunque los detalles de la codificación en la red difieren.
Es posible utilizar 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 utilizaban ECN. Los protocolos basados en UDP más recientes, como QUIC, utilizan ECN para el control de congestión.
Dado que la ECN solo es eficaz en combinación con una política de gestión de colas activa (AQM), los beneficios de la ECN dependen de la AQM específica que se utilice. Sin embargo, algunas observaciones parecen ser válidas para 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, el jitter. Este efecto es más drástico cuando la conexión TCP tiene un solo segmento pendiente, [9] cuando es capaz de evitar un tiempo de espera 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 sobre el rendimiento masivo son menos claros [10] porque las implementaciones TCP modernas son bastante buenas para reenviar segmentos perdidos 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 utilizan algoritmos AQM que nunca descartan paquetes. [8] Las implementaciones modernas de AQM evitan este problema descartando en lugar de marcar los paquetes en cargas muy altas.
Muchas implementaciones modernas del conjunto de protocolos TCP/IP tienen cierto soporte para ECN; sin embargo, generalmente se entregan con ECN deshabilitado.
Las versiones de Windows desde Windows Server 2008 y Windows Vista admiten ECN para TCP. [11] 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). [12] 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.
En FreeBSD , ECN para TCP se puede configurar mediante el sysctl net.inet.tcp.ecn.enable . De manera predeterminada, está habilitado solo para las conexiones entrantes que lo solicitan. También se puede habilitar para todas las conexiones o deshabilitarlo por completo. [13]
NetBSD 4.0 implementa soporte ECN para TCP; se puede activar a través de la interfaz sysctl estableciendo 1 como valor para el sysctl net.inet.tcp.ecn.enableparámetro. [14]
De la misma manera, el sysctl net.inet.tcp.ecn se puede utilizar en OpenBSD . [15]
Desde la versión 2.4.20 del kernel de Linux , publicada en noviembre de 2002, [16] Linux admite tres modos de funcionamiento del ECN para TCP, tal como se configura a través de la interfaz sysctl estableciendo el parámetro /proc/sys/net/ipv4/tcp_ecn en uno de los siguientes valores: [17]
A partir de la versión 4.1 del kernel de Linux, lanzada en junio de 2015, el mecanismo tcp_ecn_fallback [18] : §6.1.1.1 está habilitado de manera predeterminada [19] cuando ECN está habilitado (el valor 1). El mecanismo de respaldo intenta la conectividad ECN en la configuración inicial de las conexiones salientes, con un respaldo elegante para transmisiones sin capacidad ECN, mitigando los problemas con hosts o firewalls intolerantes a ECN.
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 . [20] La primera variable habilita ECN en conexiones entrantes que ya tienen indicadores ECN establecidos; la segunda intenta iniciar conexiones salientes con ECN habilitado. Ambas variables tienen el valor predeterminado 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, [6] pero el sistema operativo se entregó sin ese comportamiento predeterminado. En macOS Sierra, ECN está habilitado para la mitad de las sesiones TCP. [21]
En junio de 2015, Apple Inc. anunció que iOS 9 , su próxima versión de iOS, soportaría ECN y lo tendría activado de forma predeterminada. [6] 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 en el 50% de las conexiones seleccionadas aleatoriamente a través de Wi-Fi/Ethernet y algunos operadores celulares en iOS 10 [22] [23] y en el 100% para iOS 11 [24]
El kernel Solaris admite tres estados de ECN para TCP: [25]
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 . [26]
Dado que el marcado ECN en los enrutadores depende de alguna forma de gestión de cola activa , los enrutadores deben configurarse con una disciplina de cola adecuada para poder realizar el marcado ECN.
Los enrutadores Cisco IOS realizan 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 se configuran con una de las disciplinas de cola RED o GRED con un parámetro ecn explícito , mediante la disciplina sfb , mediante 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 , en particular RED y Blue . FreeBSD 11 incluía la implementación de las disciplinas de colas CoDel , PIE, FQ-CoDel y FQ-PIE en el marco ipfw /dummynet con capacidad de marcado ECN. [28]
El Protocolo de Control de Transmisión de Centros de Datos ( Data Center Transmission Control Protocol 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, utilizando 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 que tiene como objetivo preservar la fiabilidad de la señalización. Esto hace que un emisor DCTCP sea vulnerable a la pérdida de ACK del receptor, que no tiene ningún mecanismo para detectar o afrontar. [31] A partir de julio de 2014 [update], los algoritmos que proporcionan una retroalimentación del receptor equivalente o mejor en un enfoque más fiable son un tema de investigación activo. [31]
{{cite web}}: |last=tiene nombre genérico ( ayuda ){{cite web}}: |last=tiene nombre genérico ( ayuda )