Протокол DCCP (Datagram Congestion Control Protocol; RFC-4336, -4340

Сентябрь 2, 2022

Главная
Алгебра
Протокол DCCP (Datagram Congestion Control Protocol; RFC-4336, -4340

Содержание

2. До настоящего времени приложения использовали либо TCP, чья надежность и гарантия упорядочения доставки давалась за счет
3. Протокол DCCP предназначен для приложений, которые реализуют поточную схему TCP, но имеют приоритет для своевременной доставки
4. Одной из целей DCCP было максимальное облегчение для UDP приложений перехода на DCCP, когда он будет
5. Протокол DCCP имеет следующие характеристики: Реализует поток дейтограмм с подтверждением получения, но без повторной посылки. Ненадежный
6. Опции, которые говорят отправителю с высокой надежностью, какие пакеты достигли получателя, были ли эти пакеты помечены
7. Отличия DCCP от TCP Поток пакетов. DCCP является протоколом для потоков пакетов, а не потоков байт.
8. Выбор управления перегрузкой. Партнеры могут использовать разные механизмы управления перегрузкой. В соединении A B, информационные пакеты,
9. Определение подтверждения. В TCP получение пакетов подтверждается, только когда они ставятся в очередь для передачи приложению.
10. Заголовок DCCP Если X равно нулю, передаются только младшие (LSB) 24 бита порядкового номера, а базовый
11. Базовый заголовок пакетов DCCP при Х=0 Если Х=1, в заголовке используется 48-разрядные порядковые номера Каждому механизму
12. Формат подзаголовка номера подтверждения
13. Формат пакета DCCP-запроса
14. Формат пакета DCCP-отклика
15. Формат пакета DCCP-Data
16. TFRC Протокол TFRC (TCP Friendly Rate Control; RFC-3448, -4342, -4828) предоставляет механизм управления перегрузкой для уникастных
18. Скачать презентацию

Слайд 2

До настоящего времени приложения использовали либо TCP, чья надежность и гарантия

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

Слайд 3

Протокол DCCP предназначен для приложений, которые реализуют поточную схему TCP, но

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

Слайд 4

Одной из целей DCCP было максимальное облегчение для UDP приложений перехода

на DCCP, когда он будет внедрен.

Слайд 5

Протокол DCCP имеет следующие характеристики:
Реализует поток дейтограмм с подтверждением получения, но

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

Слайд 6

Опции, которые говорят отправителю с высокой надежностью, какие пакеты достигли получателя,

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

Слайд 7

Отличия DCCP от TCP
Поток пакетов. DCCP является протоколом для потоков пакетов,

а не потоков байт.
Ненадежность. DCCP никогда не пересылает дейтограммы повторно.
Порядковые номера пакетов. Порядковые номера относятся к пакетам, а не байтам. Каждому пакету, посылаемому DCCP, присваивается новый порядковый номер, это относится и к пакетам подтверждений. Это позволяет получателю пакетов DCCP детектировать потери подтверждений; смотри раздел “Sequence Number Validity” в [DCCP].
Обширное пространство для опций (до 1020 байт).
Согласование параметров. Это является базовым механизмом, с помощью которого партнеры согласуют значения параметров или свойства соединения.

Слайд 8

Выбор управления перегрузкой. Партнеры могут использовать разные механизмы управления перегрузкой. В

соединении 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) позволяет одному из партнеров сообщить, что пакет был потерян из-за повреждения, переполнения входного буфера и т.д..

Слайд 9

Определение подтверждения. В TCP получение пакетов подтверждается, только когда они ставятся

в очередь для передачи приложению. В протоколе DCCP это делается не так. Получение пакета подтверждается, когда обработаны поля его опций.
Встроенная поддержка мобильности.

Слайд 10

Заголовок DCCP
Если X равно нулю, передаются только младшие (LSB) 24 бита

порядкового номера, а базовый заголовок имеет длину 12 байт
Смещение (8 бит) от начала заголовка пакета DCCP первого октета прикладных данных (выражается в 32-битных словах).
Checksum Coverage (CsCov – покрытие контрольным суммированием)

Слайд 11

Базовый заголовок пакетов DCCP при Х=0
Если Х=1, в заголовке используется 48-разрядные

порядковые номера
Каждому механизму управления перегрузкой, поддерживаемому DCCP, присвоен идентификатор, или CCID: номер в диапазоне от 0 до 255

Слайд 12

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

Слайд 13

Формат пакета DCCP-запроса

Слайд 14

Формат пакета DCCP-отклика

Слайд 15

Формат пакета DCCP-Data

Слайд 16

TFRC
Протокол TFRC (TCP Friendly Rate Control; RFC-3448, -4342, -4828) предоставляет механизм

управления перегрузкой для уникастных потоков в Интернет. Реализованный способ управления перегрузкой может быть использован, например, в транспортном протоколе RTP, в приложении с контролем перегрузки в виртуальном канале точка-точка. RFC-3448, -4342, -4828.