Все упомянутые выше реализации протокола TCP ориентированы исключительно на своеобразное обеспечение качества обслуживания - гарантированную доставку данных без каких-либо ограничений параметров задежки и вероятности потери пакета. В [Floyd94] было предложено использовать новый механизм «явное уведомление о перегрузке» ECN (Explicit Congestion Notification) для осуществления эффективного управления нагрузкой для соединений TCP чувствительных к задержкам и даже к потере одного пакета, при этом не используя сброс пакета как индикацию перегрузки. Другими словами, при использовании ECN передатчик должен быть проинформирован о перегрузке, или состоянии близком к ней, заранее и явным образом, а не по факту уже произошедшего события, т.е. потери пакета.

Очевидно, что точной информацией о перегрузке обладает только перегруженный маршрутизатор, через который проходит соединение TCP. Поэтому, реализация ECN требует определенных дополнений на сетевом (IP) уровне - рассмотрим заголовок пакета IP. ECN использует два бита поля «тип услуги» (Type of Service, далее - TOS) для следующих целей (рис. 1.24):

• бит ЕСТ (ECN-capable transport): источник устанавливает значение бита в единицу и тем самым информирует приемник о том, что с его стороны используется протокол TCP с поддержкой ECN;

• бит СЕ (congestion experienced): маршрутизатор устанавливает значение бита в единицу и тем самым информирует приемник о перегрузке. Далее пакет с установленным битом СЕ в единицу будем называть СЕ-пакет.

Поддержка ECN в протоколе TCP также требует реализации трех дополнительных функций [RFC3168]:

• во время установления соединения необходимо, чтобы источник и приемник согласовали использование ECN;

• использование нового флага в заголовке сегмента TCP для обеспечения возможности ресивера информировать передатчик о получении СЕ-пакета, этот флаг называется ECN-Echo, и для него назначается девятый бит в поле reserved заголовка сегмента TCP (самый ближний к флагу URG);

• использование нового флага в заголовке сегмента TCP для обеспечения возможности передатчика информировать ресивер о снижении размера окна перегрузки, этот флаг называется «уменьшение размера окна перегрузки» CWR (congestion window reduced), и для него назначается восьмой бит в поле reserved заголовка сегмента TCP.

Функционирование соединения TCP с возможностью использования ECN происходит следующим образом. Во время установления соединения TCP передатчик и ресивер должны договориться об использовании ECN для этого соединения. Результатом согласования является изменение значения бита ЕСТ (сетевой уровень) во всех последующих пакетах рассматриваемого соединения. Таким образом, через сетевой уровень транзитных маршрутизаторов будет проходить пакет с установленным битом ЕСТ, в результате чего каждый маршрутизатор будет проинформирован о том, что источник и приемник используют реализацию протокола TCP с ECN. Поэтому путем установки значения бита СЕ в единицу любой маршрутизатор может проинформировать приемник о перегрузке.

Предположим далее, что одним из транзитных маршрутизаторов был установлен бит СЕ в единицу, т.е. состояние данного маршрутизатора может быть расценено как состояние перегрузки или близкого к ней. Сетевой уровень приемника получает СЕ-пакет и информирует об этом транспортный уровень, т.е. ресивер протокола TCP. В свою очередь, ресивер должен послать сегмент подтверждения передатчику и проинформировать о перегрузке на сети. Для этого используется флаг ECN-Echo в заголовке сегмента подтверждения АСК.

Теоретически сегмент подтверждения может быть потерян при передаче и информация о перегрузке не будет получена передатчиком. Для решения этой проблемы используется достаточно простая методика - ресивер устанавливает флаг ECN-Echo в единицу (индикация перегрузки) во всех последующих сегментах подтверждения вплоть до получения от передатчика сегмента с установленным битом CWR, таким образом передатчик информирует ресивер о том, что информация о перегрузке получена. Рассмотрим сторону передатчика. Пусть в передатчик поступает сегмент подтверждения с установленным в единицу битом ECN-Echo. Это означает, что на сети обнаружена перегрузка. Передатчик TCP с ECN обрабатывает ситуацию точно так же, как если бы произошла потеря сегмента в соединении TCP без ECN - снижаются значения параметров cwr.d и ssthresh, и только в одном последующем сегменте данных флаг CWR устанавливается в единицу.

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

Для избежания подобных неоднозначностей предполагается, что передатчик может изменять параметры функционирования по причине обнаруженной перегрузки максимум один раз за время передачи данных окна перегрузки (т.е. время RTT), причем передатчик не должен снижать значение параметра ssthresh, если это было произведено в предыдущий RTT. Но отметим, что передатчик должен осуществлять необходимые действия по борьбе с перегрузкой, если сегмент данных был потерян или в ресивер поступил СЕ-пакет.

На сегодня ECN является механизмом, который многие компании реализуют в своих продуктах. Заинтересованный читатель имеет возможность самостоятельно провести эксперименты с ECN на базе симулятора ns2 [ns2] или с помощью одной из самых корректных реализаций в Linux 2.4 (на базе ядра).

Далее в разделе 2.6.2.6 главы 2 будут рассмотрены принципы совместного функционирования механизма ECN и алгоритмов активного управления очередями. Этот момент является очень важным с точки зрения обеспечения качества обслуживания, поэтому автор рекомендует уделить вопросу должное внимание.

⇐Другие реализации протокола tcp | Управление трафиком и качество обслужевания в сети | Новые протоколы верхних уровней - протокол rtp - необходимость реализации дополнительного протокола⇒