Явное уведомление о перегрузке

Явное уведомление о перегрузке ( ECN ) — это расширение протокола Интернета и протокола управления передачей , определенное в RFC  3168 (2001). ECN позволяет осуществлять сквозное уведомление о перегрузке сети без потери пакетов. ECN — это дополнительная функция, которая может использоваться между двумя конечными точками с поддержкой ECN, когда базовая сетевая инфраструктура также поддерживает ее.

Традиционно сети TCP/IP сигнализируют о перегрузке, отбрасывая пакеты. Когда ECN успешно согласован, маршрутизатор, поддерживающий ECN, может установить метку в заголовке IP вместо того, чтобы отбрасывать пакет, чтобы сигнализировать о надвигающейся перегрузке. Получатель пакета передает отправителю эхо-указание о перегрузке, что снижает скорость передачи, как если бы он обнаружил отброшенный пакет.

Вместо того чтобы правильно реагировать или игнорировать биты, некоторое устаревшее или неисправное сетевое оборудование исторически отбрасывало или искажало пакеты с установленными битами ECN. ^{[1] [2] [3]} По состоянию на 2015 год ^[update]измерения показали, что доля веб-серверов в общедоступном Интернете, для которых настройка ECN предотвращает сетевые подключения, сократилась до менее чем 1%. ^[4]

Пассивная поддержка существует в Ubuntu Linux с 12.04 и в Windows Server с 2012 года. ^[5] Пассивная поддержка на самых популярных веб-сайтах увеличилась с 8,5% в 2012 году до более 70% в мае 2017 года. ^[5] Внедрение в Интернете теперь требует от клиентов активного запроса ECN. В июне 2015 года Apple объявила, что ECN будет включен по умолчанию в ее поддерживаемых и будущих продуктах, чтобы способствовать внедрению сигнализации ECN по всей отрасли. ^[6]

ECN требует особой поддержки как на уровне Интернета, так и на транспортном уровне по следующим причинам:

• В TCP/IP маршрутизаторы работают на уровне Интернета, а скорость передачи данных регулируется конечными точками на транспортном уровне.
• Перегрузка может быть обработана только передатчиком, но поскольку известно, что она произошла только после отправки пакета, то должен быть эхо-сигнал о перегрузке от приемника к передатчику.

Без ECN эхо-индикация перегрузки достигается косвенно путем обнаружения потерянных пакетов. С ECN перегрузка указывается путем установки поля ECN в IP-пакете на CE (Congestion Experienced) и возвращается приемником обратно передатчику путем установки соответствующих битов в заголовке транспортного протокола. Например, при использовании TCP индикация перегрузки возвращается путем установки бита ECE.

ECN использует два наименее значимых (крайних правых) бита поля «Класс трафика» в заголовке IPv4 или IPv6 для кодирования четырех различных кодовых точек:

• 00– Не поддерживает транспорт ECN, не поддерживает ECT
• 01– Транспорт с поддержкой ECN(1), ECT(1)
• 10– ECN-совместимый транспорт(0), ECT(0)
• 11– Возникли заторы, CE.

Когда обе конечные точки поддерживают ECN, они маркируют свои пакеты с помощью ECT(0) или ECT(1). Маршрутизаторы рассматривают кодовые точки ECT(0) и ECT(1) как эквивалентные. Если пакет проходит через очередь активного управления очередями (AQM) (например, очередь, которая использует случайное раннее обнаружение (RED)), которая испытывает перегрузку, и соответствующий маршрутизатор поддерживает ECN, он может изменить кодовую точку на CEвместо того, чтобы отбросить пакет . Это действие называется «маркировкой», и его цель — информировать принимающую конечную точку о надвигающейся перегрузке . На принимающей конечной точке эта индикация перегрузки обрабатывается протоколом верхнего уровня ( протоколом транспортного уровня ) и должна быть отражена обратно на передающий узел, чтобы сигнализировать ему о необходимости снизить скорость передачи.

Поскольку индикация CE может эффективно обрабатываться только протоколом верхнего уровня, который ее поддерживает, ECN используется только в сочетании с протоколами верхнего уровня, такими как TCP , которые поддерживают управление перегрузкой и имеют метод для передачи индикации CE на передающую конечную точку.

TCP поддерживает ECN с помощью двух флагов в заголовке TCP. Первый, ECN-Echo (ECE), используется для эхо-отклика индикации перегрузки (т. е. сигнала отправителю о необходимости снизить скорость передачи). Второй, Congestion Window Reduced (CWR), для подтверждения получения эхо-отклика индикации перегрузки. Использование ECN в соединении TCP необязательно; для использования ECN его необходимо согласовать при установлении соединения путем включения соответствующих опций в сегменты SYN и SYN-ACK.

Когда ECN согласован на TCP-соединении, отправитель указывает, что IP-пакеты, которые несут TCP-сегменты этого соединения, несут трафик из ECN Capable Transport, помечая их кодовой точкой ECT. Это позволяет промежуточным маршрутизаторам, которые поддерживают ECN, помечать эти IP-пакеты кодовой точкой CE вместо того, чтобы отбрасывать их, чтобы сигнализировать о надвигающейся перегрузке.

Получив IP-пакет с кодовой точкой Congestion Experienced , приемник TCP возвращает обратно это указание на перегрузку, используя флаг ECE в заголовке TCP. Когда конечная точка получает сегмент TCP с битом ECE, она уменьшает свое окно перегрузки, как при отбрасывании пакета. Затем она подтверждает указание на перегрузку, отправляя сегмент с установленным битом CWR.

Узел продолжает передавать сегменты TCP с установленным битом ECE до тех пор, пока не получит сегмент с установленным битом CWR.

Чтобы увидеть затронутые пакеты с помощью tcpdump , используйте предикат фильтра (tcp[13] & 0xc0 != 0).

Поскольку протокол управления передачей (TCP) не выполняет управление перегрузкой в ​​контрольных пакетах (чистые сегменты ACK, SYN, FIN), контрольные пакеты обычно не помечаются как поддерживающие ECN.

Предложение 2009 года ^[7] предлагает маркировать пакеты SYN-ACK как ECN-capable. Это улучшение, известное как ECN+, показало, что обеспечивает значительное повышение производительности краткосрочных TCP-соединений. ^[8]

ECN также определен для других протоколов транспортного уровня, которые выполняют управление перегрузкой, в частности DCCP и Stream Control Transmission Protocol (SCTP). Общий принцип аналогичен TCP, хотя детали кодирования на проводе отличаются.

Возможно использовать ECN с протоколами, расположенными выше UDP . Однако UDP требует, чтобы контроль перегрузки выполнялся приложением, а ранние протоколы на основе UDP, такие как DNS, не использовали ECN. Более поздние протоколы на основе UDP, такие как QUIC, используют ECN для контроля перегрузки.

Поскольку ECN эффективен только в сочетании с политикой активного управления очередями (AQM), преимущества ECN зависят от точного используемого AQM. Однако несколько наблюдений, по-видимому, справедливы для различных AQM.

Как и ожидалось, ECN уменьшает количество пакетов, отброшенных TCP-соединением, что, избегая повторной передачи, снижает задержку и особенно джиттер. Этот эффект наиболее выражен, когда TCP-соединение имеет один невыполненный сегмент, ^[9] когда оно способно избежать тайм-аута RTO ; это часто имеет место для интерактивных соединений, таких как удаленные входы в систему, и транзакционных протоколов, таких как HTTP-запросы, разговорная фаза SMTP или SQL-запросы.

Влияние ECN на пропускную способность пакетной передачи менее очевидно ^{[10], поскольку современные реализации TCP достаточно хороши для повторной отправки потерянных сегментов в установленные сроки, когда} окно отправителя велико.

Было обнаружено, что использование ECN отрицательно сказывается на производительности в сильно перегруженных сетях при использовании алгоритмов AQM, которые никогда не отбрасывают пакеты. ^[8] Современные реализации AQM избегают этой ловушки, отбрасывая, а не маркируя пакеты при очень высокой нагрузке.

Многие современные реализации набора протоколов TCP/IP имеют некоторую поддержку ECN; однако они обычно поставляются с отключенным ECN.

Версии Windows, начиная с Windows Server 2008 и Windows Vista, поддерживают ECN для TCP. ^[11] Начиная с Windows Server 2012, он включен по умолчанию в версиях Windows Server, поскольку используется протокол управления передачей данных в центре обработки данных (DCTCP). ^[12] В предыдущих версиях Windows и несерверных версиях он отключен по умолчанию.

Поддержку ECN можно включить с помощью команды оболочки, например netsh interface tcp set global ecncapability=enabled.

На FreeBSD ECN для TCP можно настроить с помощью net.inet.tcp.ecn.enable sysctl . По умолчанию он включен только для входящих подключений, которые его запрашивают. Его также можно включить для всех подключений или полностью отключить. ^[13]

NetBSD  4.0 реализует поддержку ECN для TCP; ее можно активировать через интерфейс sysctl , установив 1 в качестве значения параметра sysctl net.inet.tcp.ecn.enable. ^[14]

Аналогично, sysctl net.inet.tcp.ecn может использоваться в OpenBSD . ^[15]

Начиная с версии 2.4.20 ядра Linux , выпущенной в ноябре 2002 года, ^[16] Linux поддерживает три режима работы ECN для TCP, которые настраиваются через интерфейс sysctl путем установки параметра /proc/sys/net/ipv4/tcp_ecn в одно из следующих значений: ^[17]

• 0  – отключить ECN и не инициировать и не принимать его
• 1  – включить ECN при запросе входящих соединений, а также запрашивать ECN при попытках исходящего соединения
• 2  – (по умолчанию) включить ECN при запросе входящими соединениями, но не запрашивать ECN при исходящих соединениях

Начиная с версии 4.1 ядра Linux, выпущенной в июне 2015 года, механизм tcp_ecn_fallback ^{[18] : §6.1.1.1} включен по умолчанию ^[19] при включении ECN (значение 1). Механизм отката пытается подключиться к ECN при начальной настройке исходящих соединений с изящным откатом для передач без возможности ECN, смягчая проблемы с хостами или брандмауэрами, не поддерживающими ECN.

Mac OS X 10.5 и 10.6 реализуют поддержку ECN для TCP. Она управляется с помощью логических переменных sysctl net.inet.tcp.ecn_negotiate_in и net.inet.tcp.ecn_initiate_out . ^[20] Первая переменная включает ECN для входящих соединений, у которых уже установлены флаги ECN; вторая пытается инициировать исходящие соединения с включенным ECN. Обе переменные по умолчанию равны 0 , но могут быть установлены на 1 для включения соответствующего поведения.

В июне 2015 года Apple Inc. объявила, что в OS X 10.11 ECN будет включен по умолчанию, ^[6] но ОС поставляется без этого поведения по умолчанию. В macOS Sierra ECN включен для половины сеансов TCP. ^[21]

В июне 2015 года Apple Inc. объявила, что iOS 9 , следующая версия iOS, будет поддерживать ECN и включит его по умолчанию. ^[6] Согласование TCP ECN включено для 5% случайно выбранных подключений по Wi-Fi / Ethernet в iOS 9 и 50% случайно выбранных подключений по Wi-Fi / Ethernet и нескольким операторам сотовой связи в iOS 10 ^{[22] [23]} и 100% для iOS 11 ^[24]

Ядро Solaris поддерживает три состояния ECN для TCP: ^[25]

• никогда  – нет ECN
• активный  – использовать ECN
• пассивный  — рекламируйте поддержку ECN только по запросу.

Начиная с Solaris 11.4, поведение по умолчанию - active . Использование ECN можно изменить с помощью ipadm set-prop -p ecn=active tcp . ^[26]

Поскольку маркировка ECN в маршрутизаторах зависит от некоторой формы активного управления очередями , маршрутизаторы должны быть настроены с подходящей дисциплиной очереди для выполнения маркировки ECN.

Маршрутизаторы Cisco IOS выполняют маркировку ECN, если они настроены с использованием дисциплины очередности WRED , начиная с версии 12.2(8)T.

Маршрутизаторы Linux выполняют маркировку ECN, если настроены с одной из дисциплин очередей RED или GRED с явным параметром ecn , с использованием дисциплины sfb , с использованием дисциплины CoDel Fair Queuing (fq_codel) или дисциплины очередей CAKE ^{[27] .}

Современные реализации BSD, такие как FreeBSD , NetBSD и OpenBSD , поддерживают маркировку ECN в реализации очередей ALTQ для ряда дисциплин очередей , в частности RED и Blue . FreeBSD 11 включала реализацию дисциплин очередей CoDel , PIE, FQ-CoDel и FQ-PIE в фреймворке ipfw /dummynet с возможностью маркировки ECN. ^[28]

Data Center Transmission Control Protocol ( Data Center TCP или DCTCP ) использует ECN для улучшения алгоритма управления перегрузкой Transmission Control Protocol . ^[29] Он используется в сетях центров обработки данных . В то время как стандартный алгоритм управления перегрузкой TCP способен только обнаружить наличие перегрузки, DCTCP, используя ECN, способен оценить степень перегрузки. ^[30]

DCTCP изменяет TCP-приемник, чтобы всегда передавать точную маркировку ECN входящих пакетов за счет игнорирования функции, которая должна сохранять надежность сигнализации. Это делает DCTCP-отправителя уязвимым к потере ACK от приемника, которую он не имеет механизма для обнаружения или решения. ^[31] По состоянию на июль 2014 года ^[update]алгоритмы, которые обеспечивают эквивалентную или лучшую обратную связь приемника в более надежном подходе, являются активной темой исследований. ^[31]

• Обратная ECN (BECN)
• Предотвращение перегрузки сети
• Тип обслуживания (ToS)
• L4S , который использует биты ECN

• Веб-страница ECN Салли Флойд
• RFC 4774 (BCP 124), Определение альтернативной семантики для поля явного уведомления о перегрузке (ECN) , С. Флойд, (ноябрь 2006 г.)
• Поддержка ядра Linux для определения алгоритма управления перегрузкой для каждого маршрута/пункта назначения (объединено в ядре Linux 4.0)