6. Поддержка со стороны транспортного протокола
ECN требует поддержки со стороны транспортного протокола в дополнение к функциональности, обеспечиваемой полем ECN в заголовке пакета IP. Транспортный протокол может требовать согласования между конечными точками при организации соединения для проверки поддержки ECN, чтобы отправитель мог устанавливать код ECT в передаваемых пакетах. Во-вторых, транспортный протокол должен быть способен соответствующим образом реагировать на получение пакетов CE. Эта реакция может выражаться в форме информирования получателем отправителя данных о полученном пакете CE packet (e.g., TCP), отказа получателя от участия в многоуровневой multicast-группе (например, RLM [MJV96]) или в ином виде, обеспечивающем, в конечном итоге, снижение скорости поступления потока данных через перегруженное соединение. Пакеты CE показывают скорее долговременное, чем краткосрочное насыщение (см. параграф 5.1) и, следовательно, реакция на получение пакетов CE должна соответствовать продолжительной перегрузке.
В этом документе рассматривается добавление поддержки ECN только для протокола TCP, а рассмотрение вопросов использования ECN в других транспортных протколах оставлены для будущих исследований. Для TCP добавление ECN требует поддержки трех функций: согласование между конечными точками в процессе организации соединения для проверки поддержки ECN на обеих сторонах; флаг ECN-Echo (ECE) в заголовке TCP, чтобы получатель мог информировать отправителя о получении пакета CE; флаг CWR (Congestion Window Reduced — окно насыщения уменьшено) в заголовке TCP, чтобы отправитель мог информировать получателя о снижении размера окна насыщения. Очевидно, что функциональность, требуемая от других протоколов (в частности, протоколов групповой адресации с гарантиями доставки и без таковых), будет отличаться и определится при стандартизации этих транспортных протоколов в IETF.
В этом документе используется термин «пакеты TCP» вместо «сегментов TCP», что не вполне корректно терминологически.