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). ECN permite la notificación de un extremo a otro de la congestión de la red sin perder paquetes. ECN es una característica opcional que se puede utilizar entre dos puntos finales 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 señalar una congestión inminente. El receptor del paquete transmite la indicación de congestión al remitente, lo que reduce su velocidad de transmisión como si detectara un paquete perdido.
En lugar de responder adecuadamente o ignorar los bits, algunos equipos de red obsoletos o defectuosos históricamente han caído o destrozado 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 la Internet pública 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 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 clientes soliciten activamente ECN. En junio de 2015, Apple anunció que ECN se habilitará de forma predeterminada en sus productos futuros y compatibles, 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, 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 (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 repite configurando el bit ECE.
ECN utiliza los dos bits menos significativos (el 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 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 administració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 debe enviarse de vuelta 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 transmisor. .
TCP admite ECN usando dos indicadores en el encabezado TCP. El primero, ECN-Echo (ECE) se utiliza para devolver la indicación de congestión (es decir, indicar 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 la indicación de congestión. El uso de ECN en una conexión TCP es opcional; para que se utilice ECN, se debe negociar en el establecimiento de la conexión incluyendo 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 a los enrutadores intermedios que admiten ECN marcar 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 de congestión experimentada , el receptor TCP devuelve 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 se tratara de una caída de paquetes. 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 , 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 puros, SYN, FIN), 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]
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 los detalles de la codificación en el cable difieren.
Es posible utilizar ECN con protocolos superpuestos a UDP . Sin embargo, UDP requiere que la aplicación realice el control de la 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 la congestión.
Dado que ECN solo es eficaz en combinación con una política de gestión activa de colas (AQM), los beneficios de ECN dependen del AQM preciso que se utilice. Sin embargo, algunas observaciones parecen ser válidas 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 único segmento pendiente, [9] cuando es capaz de evitar un tiempo de espera de RTO ; Este suele ser el caso de conexiones interactivas, como inicios de sesión remotos, y protocolos transaccionales, como solicitudes HTTP, la fase conversacional de SMTP o solicitudes SQL.
Los efectos de ECN en el rendimiento masivo son menos claros [10] porque las implementaciones TCP modernas son bastante buenas para reenviar segmentos eliminados 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 muy congestionadas cuando se utilizan algoritmos AQM que nunca descartan paquetes. [8] Las implementaciones modernas de AQM evitan este problema al descartar paquetes en lugar de marcarlos con una carga muy alta.
Muchas implementaciones modernas del conjunto de protocolos TCP/IP tienen cierto soporte para ECN; sin embargo, normalmente se envían con ECN desactivado.
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 (DTCCP). [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 usando el sysctl net.inet.tcp.ecn.enable . De forma predeterminada, está habilitado solo para conexiones entrantes que lo soliciten. 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 configurando 1 como valor para el sysctl net.inet.tcp.ecn.enableparámetro. [14]
Asimismo, el sysctl net.inet.tcp.ecn se puede utilizar en OpenBSD . [15]
Desde la versión 2.4.20 del kernel de Linux , lanzada en noviembre de 2002, [16] Linux admite tres modos de trabajo de ECN para TCP, según 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 , como se especifica en la sección 6.1.1.1 de RFC 3168, [18] está habilitado de forma predeterminada [19] 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 respaldo elegante para transmisiones sin capacidad ECN, mitigando 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 configurados; el segundo 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 envió 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, sería compatible con 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 de telefonía celular en iOS 10 [22] [23 ] y 100% para iOS 11 [24]
El kernel de Solaris admite tres estados de ECN para TCP: [25]
A partir de Solaris 11.4, el comportamiento predeterminado está 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 activa de colas , los enrutadores deben configurarse con una disciplina de cola adecuada para poder 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 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 [27] .
Las implementaciones BSD modernas, 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 incluyó la implementación de 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 del centro de datos ( TCP del centro 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, utilizando ECN, puede medir el alcance de la congestión. [30]
DCTCP modifica el receptor TCP para transmitir siempre la marca ECN exacta de los paquetes entrantes a costa de ignorar una función 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. [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 confiable son un tema de investigación activo. [31]
{{cite web}}: |last=tiene nombre genérico ( ayuda ){{cite web}}: |last=tiene nombre genérico ( ayuda )