RFC: 4340
Оригинал: Datagram Congestion Control Protocol (DCCP)
Категория: Предложенный стандарт
Дата публикации:
Авторы: , ,
Перевод: Николай Малых

11.7. Опция Data Dropped

Опция Data Dropped показывает, что данные приложения из одного или множества полученных пакетов на самом деле не были доставлены приложению. Кроме того, Data Dropped additionally сообщает причину отбрасывания данных — возможно они оказались поврежденными или получатель неспособен принимать информацию с той скоростью, которую установил отправитель и данные были отброшены тем или иным приемным буфером. С помощью опции Data Dropped конечные точки DCCP могут отличать разные варианты потери пакетов. Это отличается от протокола TCP, в котором информация о потере пакетов единообразна.

Если явно не указано иное, механизмы контроля насыщения DCCP должны реагировать на опции Data Dropped, как будто пакеты были помечены в сети маркерами ECN Congestion Experienced. Мы предполагаем, что опция Data Dropped позволит исследовать отклики в условиях сильного насыщения на повреждения и отбрасывание конечными точками пакетов, но механизмы CCID должны консервативно реагировать на опции Data Dropped, пока это поведение не стандартизовано. В параграфе 11.7.2 обсуждаются отклики на перегрузки для всех определенных в настоящее время значений Drop Code.

Если данные приложения из полученного пакета отбрасываются по одной или нескольким перечисленным ниже причинам, об этом следует уведомлять с помощью опций Data Dropped. Кроме того, отправитель может сообщать как о принятых только о тех пакетах, данные приложений из которых не были отброшены, но в этих случаях недопустима обработка опций из тех пакетов, которые не считаются принятыми.

Вид данных опции показан на рисунке:

+--------+--------+--------+--------+--------+--------
|00101000| Length | Block  | Block  | Block  |  ...
+--------+--------+--------+--------+--------+--------
 Type=40          \___________ Vector ___________ ...

Область Vector содержит последовательности байтов, называемые блоками, каждая из которых кодируется в соответствии с одним из двух показанных на рисунке вариантов.

 0 1 2 3 4 5 6 7                   0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+                 +-+-+-+-+-+-+-+-+
|0| Run Length  |       или       |1|DrpCd|Run Len|
+-+-+-+-+-+-+-+-+                 +-+-+-+-+-+-+-+-+
  Normal Block                       Drop Block

Первый байт опции Data Dropped относится к пакету, указанному полем Acknowledgement Number, а последующие байты относятся к более старым пакетам. Опции Data Dropped недопустимо включать в пакеты DCCP-Data и DCCP-Request, которые не включают поля Acknowledgement Number, и все опции Data Dropped, полученные в таких пакетах, должны игнорироваться.

Нормальные блоки (Normal Block), старший бит которых имеет значение 0, показывают, что все пакеты, указанные полем Run Length, были доставлены приложению. Отброшенные блоки (Drop Block), старший бит которых имеет значение 1, показывают, что пакеты, указанные в поле Run Len, не были доставлены приложению. Трехбитовое поле DrpCd указывает, что произошло (в общем случае данные из пакета не были доставлены приложению). Пакеты, указанные как «еще не доставленные», должны включаться в нормальные блоки; пакеты, не включенные ни в одну из опций Data Dropped, трактуются как будто они были включены в Normal Block. Определенные значения кодов отбрасывания (Drop Code) для отброшенных блоков показаны в таблице 7.

Код причины Название
0 Protocol Constraints
1 Application Not Listening
2 Receive Buffer
3 Corrupt
4-6 Резерв
7 Delivered Corrupt
 
Таблица 7: Коды отбрасывания пакетов DCCP

Ниже приводится более детальное описание причин.

  • 0 — данные из пакета были отброшены в результате протокольных ограничений. Например, данные были включены в пакет DCCP-Request, но принимающее приложение не поддерживает такую возможность, или данные были включены в пакет с недопустимо низким значением Checksum Coverage.
  • 1 — данные были отброшены по той причине, что приложение больше не находится в режиме прослушивания (см. параграф 11.7.2).
  • 2 — данные из пакета были отброшены в приемном буфере, возможно в результате его переполнения (см. параграф 11.7.2).
  • 3 — данные из пакета были отброшены по причине их повреждения (см параграф 9.3).
  • 7 — данные из пакета оказались поврежденными, но были доставлены приложению (см. параграф 9.3).

В качестве примера рассмотрим пакет, прибывающий с Acknowledgement Number 100, опцией Ack Vector, сообщающей, что все пакеты получены, и опцией Data Dropped, содержащей десятичные значения 0,160,3,162.

  • пакет 100 был получен (Acknowledgement Number 100, Normal Block, Run Length 0).
  • пакет 99 был отброшен в приемном буфере (Drop Block, Drop Code 2, Run Length 0).
  • пакеты 98, 97, 96, 95 были получены (Normal Block, Run Length 3).
  • пакеты 95, 94, 93 были отброшены в приемном буфере (Drop Block, Drop Code 2, Run Length 2).

Значения Run length, превышающие 128 (для Normal Block) или 16 (для Drop Block) должны кодироваться с использованием нескольких блоков (Block). Одна опция Data Dropped может подтверждать до 32384 Normal Block, хотя получателю не следует передавать опцию Data Dropped, когда все относящиеся к делу пакеты помещаются в нормальные блоки. Если требуется подтвердить больше пакетов, нежели можно поместить в 253 байта опции Data Dropped, можно передавать множество опций Data Dropped. Вторая опция будет начинаться там, где закончится первая и т. д.

Одна или множество опций Data Dropped вместе могут сообщать о состоянии большего числа пакетов, нежели было передано, менять состояние для пакетов, вступать в противоречие с Ack Vector или эквивалентными опциями (например, сообщая о пакетах, которые еще не доставлены, как об отброшенных в приемном буфере). Такие опции следует рассматривать как некорректные. Принимающей стороне DCCP следует игнорировать такие опции или сбрасывать соединение с Reset Code 5, "Option Error".

Прикладному интерфейсу DCCP следует позволять принимающему приложению задавать значения Drop Code, соответствующие полученным пакетам. Например, это позволит приложениям рассчитывать свои контрольные суммы, но продолжать уведомлять об отбрасывании пакетов в результате повреждения с помощью опции Data Dropped. Интерфейсу не следует позволять приложениям снижать «значимость» Drop Code; например, приложению не следует позволять менять для пакета состояние с «поврежден при доставке» (Drop Code 7) на «доставлен нормально» (нет Drop Code).

Информация Data Dropped передается с гарантией доставки. Т. е., конечной точке следует продолжать передачу опций Data Dropped до получения подтверждения, показывающего, что соответствующие опции были обработаны. В терминах Ack Vector каждому подтверждению следует включать опции Data Dropped, которые покрывают все окно подтверждений (Acknowledgement Window, см. параграф 11.4.2), хотя в тех случаях, когда все пакеты из этого окна помещаются в Normal Block, опция не требуется.

Страница 83 из 113

2007 - 2022 © Русские переводы RFC, IETF, ISOC.