RFC: 3168
Оригинал: The Addition of Explicit Congestion Notification (ECN) to IP
Предыдущие версии: RFC 2481
Категория: Предложенный стандарт
Дата публикации:
Авторы: , ,
Перевод: Николай Малых

RFC 3168, Страница 53 из 56

21. Зачем использовать два бита в заголовке IP?

Необходимость индикации ECT в заголовке IP понятна, но остается вопрос о возможности использования для кодов ECT (транспорт с поддержкой ECN) и CE (обнаружено насыщение) одного бита в заголовке. Такое однобитовое представление предложено в работе [Floyd94]. Одно значение «ECT, но без CE» будет представлять поддерживающий ECN транспорт, а другое — «CE или без ECT» будет представлять факт насыщения или транспорт без поддержки ECN.

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

Другое различие между однобитовыми и двухбитовыми реализациями заключается в том, что в однобитовом случае получатель не может различить пакеты CE и non-ECT в одном потоке. Таким образом, в однобитовой реализации поддерживающий ECN дает получателю неоднозначную индикацию поддержки ECN. У отправителя остается возможность показать поддержку ECN в заголовке транспортного уровня. Другим вариантом является функциональное ограничение для однобитовых реализаций, в соответствии с которым отправитель трактует все переданные им пакеты как поддерживающие или не поддерживающие ECN. Для транспортных протоколов с групповой адресацией такая неоднозначная индикация будет представляться получателю подключением к действующему multicast-сеансу.

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

Другим преимуществом двухбитового варианта является повышенная отказоустойчивость. Наиболее критический момент, описанный в разделе 8, заключается в том, что по умолчанию следует указывать не поддерживающий ECN транспорт. В двухбитовом варианте для реализации этого требования достаточно просто устанавливать по умолчанию код not-ECT. В однобитовом варианте для выполнения этого требования следует устанавливать код «CE или ECT». Этот вариант менее понятен и, возможно, более открыт для некорректных реализаций на конечных узлах или маршрутизаторах.

Хотя в целом обнобитовая реализация вполне допустима, она имеет ряд существенных недостатков по сравнению с двухбитовым вариантом. Во-первых, функциональность однобитового варианта существенно ограничена в плане трактовки пакетов с кодом CE на втором перегруженном маршрутизаторе. Во-вторых, однобитовый вариант требует передачи дополнительной информации в заголовке транспортного уровня пакетов из поддерживающего ECN потока (функциональность двухбитового варианта просто переносится на транспортный уровень) или понимания со стороны отправителей поддерживающих ECN потоков того, что получатели должны быть способны а-приори определить какие пакеты поддерживают ECN, а какие не поддерживают. В-третьих, однобитовая реализация потенциально более открыта для ошибок со стороны некорректных реализаций, которые могут по умолчанию устанавливать неверное значение бита ECN. Мы полагаем, что перечисленные ограничения обеспечивают достаточные основания использования дополнительного бита в заголовке IP для кодов ECT.

Страница 53 из 56

2007 - 2022 © Русские переводы RFC, IETF, ISOC.