Какова логика установки действительного региона вдвое меньшего размера диапазона PSN?

Для того чтобы отвечающая сторона могла отличить повторяющиеся пакеты от неупорядоченных пакетов, данная очередь отправки должна иметь серию PSN, не превышающую 8 388 608 ожидающих обработки в любой момент времени. Таким образом, очередь отправки должна содержать не более 8 388 608 пакетов, ожидающих обработки в любой момент времени. Сюда входит сумма всех пакетов запроса SEND, а также всех пакетов запроса RDMA WRITE, а также всех пакетов запроса ATOMIC Operation и всех ожидаемых пакетов ответа RDMA READ. Таким образом, пространство PSN (состоящее из диапазона 16 777 216 PSN) разделено на две области, каждая из которых занимает диапазон из 8 388 608 PSN, называемых действительным регионом и недопустимым регионом.

Как я цитировал из спецификации IBTA, почему невозможно отличить дубликаты от неупорядоченных пакетов, если действительный регион больше половины размера региона PSN размером 2 ^ 24?

введите здесь описание изображения


infiniband rdma
person Barney_su    schedule 30.10.2020    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Представьте, что общий диапазон PSN был меньше, для упрощения примера скажем 0..3. Допустимым регионом будет 2 пакета, если мы будем следовать духу спецификации, которая будет включать ожидаемый PSN и 1 предыдущий дубликат PSN, но, скажем, мы увеличим его до 3 пакетов.

Взгляните на два сценария ниже:

Сценарий выхода из строя

Sender sends  | Receiver sends
Send 0        | Ack 0
Send 1 (lost) |
Send 2 (lost) |
Send 3        | ?

После того, как получатель получает Send 0, ожидаемый PSN равен 1. Когда получатель получает 4-й пакет, это неупорядоченный пакет, более продвинутый, чем ожидаемый PSN на 2. Ответчик должен рассматривать это как ошибку последовательности.

Повторяющийся сценарий

Sender sends     | Receiver receives | Receiver sends
Send 3           | Send 3            | Ack 3 (lost)
Send 3 (delayed) |                   |
Send 0           | Send 0            | Ack 0
                 | Send 3 (delayed)  | ?

Здесь отправитель повторно передает Send 3 после истечения времени ожидания потерянного подтверждения. Повторная передача задерживается в сети, и получатель видит ее только после того, как получит Send 0. Ожидаемый PSN на получателе равен 1, и он получает пакет в пределах допустимого региона (отставание на 2 пакета), поэтому он должен его обработать. как дубликат пакета.

Резюме

Как видите, в обоих сценариях состояние получателя (ожидаемый PSN) одинаково, и полученный пакет имеет один и тот же PSN, поэтому с допустимым регионом 3 невозможно различить эти два сценария. Если мы ограничим допустимый регион до 2, первый сценарий будет невозможен, так как отправителю придется ждать подтверждения для PSN 1 перед отправкой PSN 3.

person haggai_e    schedule 01.11.2020
comment
Это объяснение имеет смысл. Так что imo эта схема принимается стороной отправителя, не отправляя запросы, если в приведенном выше примере уже есть, скажем, 2 невыполненных запроса, и сторона получателя будет полагать, что пакет дублируется, если полученный PSN находится в диапазоне (ожидаемый PSN - 2, ожидаемый PSN]. Если это так, то что, если пакет занимает вечность и, наконец, прибыл как устаревший, фантомный пакет, застрявший где-то, можно ли распознать этот пакет только с помощью PSN? - person Barney_su; 03.11.2020
comment
Если пакет может быть задержан на сколь угодно долгое время, я думаю, вы могли бы разработать сценарий, в котором такой пакет ошибочно считался бы неупорядоченным, а не дубликатом или даже ожидаемым пакетом. Я не думаю, что у транспорта IB есть решение для этого. - person haggai_e; 03.11.2020
comment
да, я бы согласился с вами в этом. Спасибо за разъяснение вопроса. - person Barney_su; 03.11.2020
comment
Кстати, я думаю, что протокол защиты от повторов IPSec решает эту проблему, запрещая перенос PSN. По сути, вам нужно устанавливать новую ассоциацию безопасности каждые 2^32 пакета. - person haggai_e; 03.11.2020