Протокол передачи команд и сообщений об ошибках (ICMP). Протоколы DCCP и TFRC

3.1. Протокол управления перегрузкой для дейтаграмм DCCP

Введение

Протокол DCCP (Datagram Congestion Control Protocol) является транспортным протоколом, который использует двунаправленные уникастные соединения с управлением перегрузкой для ненадежной доставки дейтаграмм. Протокол DCCP предназначен для приложений, которые реализуют поточную схему TCP, но имеют приоритет для своевременной доставки данных с сохранением порядка кадров или требуют надежности, или для приложений, которые требуют механизма подавления перегрузки, отличного от TCP. До настоящего времени такие приложения использовали либо TCP, чья надежность и гарантия упорядочения доставки давалась за счет неопределенно большой задержки, либо UDP и независимый механизм управления перегрузкой (или вообще с отсутствием подавления перегрузки). Протокол DCCP будет предоставлять стандартный способ управления перегрузкой и позволит применять механизм ECN.

Протокол DCCP предназначен для приложений, которые не требуют параметров SCTP [RFC-2960], таких, как упорядоченная доставка при нескольких потоках.

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

Одной из целей DCCP было максимальное облегчение для UDP приложений перехода на DCCP, когда он будет внедрен. Чтобы облегчить это, DCCP был спроектирован с минимальной избыточностью как с точки зрения размера заголовка пакета, так и с позиции загрузки ЦПУ машин партнеров. В DCCP была включена минимальная функциональность, при сохранении возможности включения новых функций, таких, как FEC (forward error correction), псевдонадежность и множественные потоки, которые могут быть добавлены поверх DCCP, если потребуется.

Возможны разные механизмы управления перегрузкой для разных приложений. Например, игры реального времени могут требовать быстрого использования всей доступной полосы пропускания, в то время как потоковая среда может использовать компромисс между скоростью отклика и стабильной, менее импульсивной передачей. (Резкое изменение потока может вызвать неприемлемые сбои UI, такие, как слышимые паузы или щелчки). Протокол DCCP, таким образом, предлагает приложению выбор одного из нескольких механизмов управления перегрузкой. Одной из альтернатив является TCP-подобное управление перегрузкой, сокращение вдвое окна перегрузки в ответ на потерю пакета. Приложения, применяющие механизм управления перегрузкой, будут быстро реагировать на изменения доступной полосы, но должны выдерживать резкое изменение окна перегрузки, что типично для TCP. Вторую альтернативу представляет механизм управления скоростью передачи, дружественный по отношению TCP (TFRC) [RFC-3448]. Это алгоритм управления перегрузкой, базирующийся на уравнении, минимизирует резкие изменения скорости передачи.

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

В DCCP было решено не применять менеджер управления перегрузкой [RFC-3124], который допускает несколько одновременных потоков между отправителем и получателем. Менеджер перегрузки может быть использован только приложениями, которые имеют свою собственную обратную связь в случае потери пакетов между конечными точками соединения, но этого нет во многих приложениях, работающих с UDP. Кроме того, сегодняшний вариант менеджера перегрузки, как правило, не поддерживает более одного механизма управления перегрузкой. DCCP должен быть способен использовать механизм управления перегрузкой там, где это требуется приложению.

Предполагается, что протокольные механизмы DCCP, будут адаптированы к любому приложению, требующему уникастных потоков с управлением перегрузки. Механизмы управления перегрузкой, встраиваемые в DCCP, описаны в отдельных ID профайлах управления [CCID 2 PROFILE, CCID 3 PROFILE], они могут, однако вызвать проблемы для некоторых приложений, включая широкополосное интерактивное видео. Эти приложения должны быть способны задействовать DCCP, когда будут стандартизованы подходящие ID профайлы управления перегрузкой.

Протокол DCCP имеет следующие характеристики:

• реализует поток дейтаграмм с подтверждением получения, но без повторной посылки;
• ненадежный диалог установления и разрыва соединения;
• надежное согласование параметров;
• выбор механизмов подавления перегрузки, дружественных по отношению к TCP, включая TCP-подобное управление перегрузкой (CCID 2) и управление потоком [RFC-3448] (CCID 3). CCID 2 использует разновидность TCP-механизма управления перегрузкой и приемлемо для потоков, которые стремятся воспользоваться преимуществами доступной полосы, CCID 3 пригодно для потоков, которые требуют более стабильной скорости передачи;
• опции, которые говорят отправителю с высокой надежностью, какие пакеты достигли получателя, были ли эти пакеты помечены ECN [RFC-3168 и RFC-3540], повреждены или отброшены во входном буфере получателя;
• управление перегрузкой, снабженное встроенной индикацией явной перегрузки ECN (Explicit Congestion Notification);
• механизмы, позволяющие серверу избежать поддержки состояний неподтвержденных попыток соединений;
• выявление MTU пути [RFC-1191].

Основные отличия DCCP от TCP

Ниже рассмотрены наиболее существенные отличия DCCP от TCP.

• Поток пакетов. DCCP является протоколом для потоков пакетов, а не потоков байт.
• Ненадежность. DCCP никогда не пересылает дейтаграммы повторно.
• Порядковые номера пакетов. Порядковые номера относятся к пакетам, а не к байтам. Каждому пакету, посылаемому DCCP, присваивается новый порядковый номер, то же и с пакетами подтверждений. Это позволяет получателю пакетов DCCP детектировать потери подтверждений; смотри раздел "Sequence Number Validity" в [DCCP].
• Обширное пространство для опций (до 1020 байт).
• Согласование параметров. Это является базовым механизмом, с помощью которого партнеры согласуют значения параметров или свойства соединения.
• Выбор управления перегрузкой. Партнеры могут использовать разные механизмы управления перегрузкой. В соединении A<>B информационные пакеты, посланные от A>B, могут применять алгоритм CCID 2, а пакеты данных от B>A могут использовать CCID 3.
• Различные форматы подтверждений. CCID соединения определяет, какой объем данных должно быть передан в ack. В CCID 2 (TCP-подобном) посылается один ack на 2 пакета, а каждый ack должен оповещать, какие конкретно пакеты получены (опция Ack Vector); в CCID 3 (TFRC) посылается в среднем один ack за время RTT, а ack должны сообщать как минимум о длинах последних интервалов потерь.
• Отсутствие приемного окна. DCCP является протоколом управления перегрузкой, а не протоколом управления потоками.
• Разделение различных видов потерь. Опция потерянных данных (Data Dropped) позволяет одному из партнеров сообщить, что пакет был потерян изза повреждения, переполнения входного буфера и т.д..
• Определение подтверждения. В TCP получение пакетов подтверждается, только когда они ставятся в очередь для передачи приложению. В протоколе DCCP это делается не так. Получение пакета подтверждается, когда обработаны поля его опций.
• Встроенная поддержка мобильности.

Основные понятия и термины

Каждое DCCP соединение реализуется между двумя партнерами, которые будут называться DCCP A и DCCP B. Данные могут передаваться в обоих направлениях. В рамках протокола рассматриваются субнаборы соединений, называемых полусоединениями (halfconnection - HC). (Смотри рис. 3.12.) Эти полусоединения обеспечивают передачу информационных пакетов в одном направлении плюс соответствующих подтверждений в противоположном направлении. В контексте одного полусоединения HC-отправитель является партнером отправителем данных, в то время как HC-Receiver является партнером, посылающим подтверждения. Каждое полусоединение контролируется механизмом управления перегрузкой, специфицированным однобайтовым идентификатором, или CCID. Партнеры согласуют режим обмена на фазе формирования соединения. CCID для полусоединения описывает, как HCотправитель ограничивает поток информационных пакетов; как он поддерживает необходимые значения параметров, такие, как окна перегрузки; как HC-получатель уведомляет отправителя о перегрузке, посылая подтверждения; и как он поддерживает частоту подтверждений.

Рис. 3.12. Структура обменов в протоколе DCCP