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

11.4.1. Согласованность Ack Vector

Отправитель DCCP обычно будет получать многочисленные подтверждения для некоторых отправленных им пакетов данных. Например, HC-Sender может получить два пакета DCCP-Ack с опциями Ack Vector, каждый из которых будет содержать информацию о порядковом номере 24 (информация о порядковом номере обычно повторяется в каждом подтверждении, пока HCSender не подтвердит получение подтверждения; в этом случае HC-Receiver передает подтверждения быстрее, чем HC-Sender подтверждает их получение). В идеальном мире две опции Ack Vector всегда будут согласованы. Однако существует множество причин, по которым согласования может не быть. Например,

  • Получатель HC-Receiver принял пакет 24 в промежутке между передачей своих подтверждений и в первом он указал, что пакет 24 не принят (State 3), а во втором указал статус ECN (State 0 или 1).

  • Получатель HC-Receiver принял пакет 24 в промежутке между передачей своих подтверждений, а порядок доставки этих подтверждений был нарушен в сети. В этом случае пакеты будут представляться как сменившие State 0 или 1 на State 3.

  • В сети возникли дубликаты пакета 24 и один или несколько таких дубликатов имеют маркер ECN. Это может представляться как переход между состояниями 0 и 1.

Чтобы справиться с такими ситуациями реализации DCCP на стороне HC-Sender следует объединять множество полученных состояний Ack Vector, как показано в таблице на рисунке:

         Received State
           0   1   3
         +---+---+---+
       0 | 0 |0/1| 0 |
 Old     +---+---+---+
       1 | 1 | 1 | 1 |
State    +---+---+---+
       3 | 0 | 1 | 3 |
         +---+---+---+

Для чтения таблицы выбирается строка, соответствующая старому состоянию пакета и колонка, соответствующая состоянию пакета в недавно полученной опции Ack Vector; пересечение покажет новое состояние пакета. Если старое состояние было 0 (принят немаркированный пакет), а новое — 1 (пакет принят с маркером ECN), в качестве нового состояния следует установить 0 или 1. Реализация HC-Sender будет безразлична к изменению порядка доставки подтверждений, если она выберет для данной ячейки в качестве нового состояния 1.

Получателю (HC-Receiver0 следует собирать информацию о принятых пакетах, как показано в таблице на рисунке:

         Received Packet
            0   1   3
          +---+---+---+
        0 | 0 |0/1| 0 |
Stored    +---+---+---+
        1 |0/1| 1 | 1 |
 State    +---+---+---+
        3 | 0 | 1 | 3 |
          +---+---+---+

Эта таблица отличается от таблицы для отправителя лишь тем, что когда сохраненное состояние равно 1, а полученное — 0, получатель может сменить сохраненное состояние на 0.

HC-Sender может выбрать отказ от старой информации, собранной из полученных от HC-Receiver опций Ack Vector; в этом случае отправитель должен игнорировать полученные недавно от HC-Receiver подтверждения для тех старых пакетов. Представляется более разумным сохранение информации Ack Vector, чтобы отправитель HC-Sender мог отказаться от своей реакции на предполагаемое насыщение, когда «потерянный» пакет неожиданно найдется (смена State 3 на State 0).

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