Презентация Протокол DCCP (Datagram Congestion Control Protocol; RFC-4336, -4340 онлайн

Содержание слайда: Протокол DCCP (Datagram Congestion Control Protocol; RFC-4336, -4340)

Содержание слайда: До настоящего времени приложения использовали либо TCP, чья надежность и гарантия упорядочения доставки давалась за счет неопределенно большой задержки, или UDP и независимого механизма управления перегрузкой (или вообще с отсутствием подавления перегрузки). Протокол DCCP будет предоставлять стандартный способ управления перегрузкой и позволит использовать механизм ECN (Explicit Congestion Notification) Протокол DCCP предназначен для приложений, которые не требуют параметров SCTP [Stream Control Transmission Protocol, RFC 2960], таких как упорядоченная доставка при нескольких потоках. Протокол DCCP обеспечивает надежное согласование параметров при установлении соединения. В DCCP было решено не использовать менеджер управления перегрузкой [RFC 3124], который допускает несколько одновременных потоков между отправителем и получателем.

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

Содержание слайда: Одной из целей DCCP было максимальное облегчение для UDP приложений перехода на DCCP, когда он будет внедрен.

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

Содержание слайда: Опции, которые говорят отправителю с высокой надежностью, какие пакеты достигли получателя, были ли эти пакеты помечены ECN [RFC 3168 и RFC 3540], повреждены, или отброшены во входном буфере получателя. Управление перегрузкой, снабженное встроенной индикацией явной перегрузки ECN (Explicit Congestion Notification). Механизмы, позволяющие серверу избежать поддержки состояний неподтвержденных попыток соединений. Выявление MTU пути [RFC 1191].

Содержание слайда: Отличия 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 при Х=0

Содержание слайда: Формат подзаголовка номера подтверждения

Содержание слайда: Формат пакета DCCP-запроса

Содержание слайда: Формат пакета DCCP-отклика

Содержание слайда: Формат пакета DCCP-Data

Содержание слайда: TFRC Протокол TFRC (TCP Friendly Rate Control; RFC-3448, -4342, -4828) предоставляет механизм управления перегрузкой для уникастных потоков в Интернет. Реализованный способ управления перегрузкой может быть использован, например, в транспортном протоколе RTP, в приложении с контролем перегрузки в виртуальном канале точка-точка. RFC-3448, -4342, -4828.

Содержание слайда: Выражение для пропускной способности