Кратко

  • После перехода к обычному TCP через бесконечное отображение соединению запрещено возвращаться к MPTCP до конца его существования.
  • Один подпоток ещё не означает такой переход. Для повторного получения MPTCP нужно другое соединение, но его успех и безопасность повторения прикладной работы не гарантированы.

Сеть может восстановить дополнительные пути, а старое соединение так и не получить возможность ими воспользоваться. В MPTCP существует процедура, при которой это не задержка восстановления и не временное предпочтение планировщика. Поток продолжает жить как обычный TCP, а обратный переход к MPTCP в нём уже запрещён.

Речь идёт об откате через бесконечное отображение, описанном в разделе 3.7 RFC 8684. Ограничение относится к конкретному соединению. Оно не лишает устройство MPTCP навсегда и не распространяется автоматически на остальные соединения. Но улучшение интерфейса, появление ещё одного адреса или восстановление скорости сами по себе не отменяют уже выполненный переход.

Для владельца сервиса это необычная форма успешной защиты: текущая передача сохранена, однако её дальнейшие возможности изменились. Решение не прерывать поток не отвечает на вопрос, когда следует заменить соединение ради возвращения многопутевой передачи. Последний вопрос затрагивает приложение и цену незавершённой работы.

Меняются правила подтверждения, а не только маршруты

MPTCP предоставляет упорядоченный поток байтов, используя отдельные подпотоки TCP. У каждого подпотока своё пространство порядковых номеров; у соединения в целом есть пространство номеров данных. Сигнал DSS сообщает соответствие между ними. Благодаря ему получатель может расположить байты в общем потоке, даже если они пришли через разные подпотоки.

Подтверждения тоже действуют на разных уровнях. В обычном режиме MPTCP отправитель не вправе освободить данные из буфера только потому, что получил ACK одного подпотока. Требуются подтверждение на уровне соединения и подтверждения всех подпотоков, по которым эти данные передавались. Получатель мог подтвердить сегмент TCP, но затем отбросить данные, ожидавшие обработки на уровне соединения, например при нехватке памяти.

Бесконечное отображение использует зарезервированное значение длины данных — ноль — для соответствия, действующего до конца соединения. После отката отправитель очищает буфер только на основании подтверждений подпотока; получателю следует прекратить отправку MPTCP Data ACK. Передача продолжается по правилам обычного TCP.

Следовательно, это не просто временное решение отправлять всё по одному пути. Меняется основание, по которому отправитель перестаёт хранить данные. Именно такую границу определяют разделы 3.3 и 3.7 RFC 8684. Ни одно из этих транспортных подтверждений, однако, не доказывает завершения деловой операции приложением.

Повреждённый подпоток не всегда означает конец MPTCP

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

При наличии нескольких подпотоков ошибка контрольной суммы может привести к закрытию только пострадавшего подпотока. Данные неудачного отображения не подтверждаются на уровне соединения и повторно передаются по другим подпотокам. В такой ситуации MPTCP может продолжить работу. Нельзя описывать любую ошибку проверки как перевод всего соединения в TCP.

Для случая с одним подпотоком существует дополнительное условие. Чтобы применить бесконечное отображение без его предварительного закрытия, нужно знать, что ещё не подтверждённые данные в передаче образуют непрерывную последовательность. Само число подпотоков этого не доказывает: среди данных могут быть повторы из другого подпотока, закрывшегося некорректно.

MP_FAIL указывает номер данных в начале неудачного отображения. В соответствующем обмене при откате обратное направление тоже возвращается к обычному TCP. Если непрерывности нет, спецификация описывает вариант со сбросом и возможным созданием нового подпотока, к которому сразу применяется бесконечное отображение. Этот новый подпоток остаётся частью старого соединения. Он не является новым соединением, восстановившим многопутевые возможности.

Потеря опций при первоначальном согласовании и повреждение уже используемых отображений также требуют разных трактовок. В некоторых случаях следует закрыть проблемный подпоток. Универсального безусловного переключателя, спасающего любое повреждённое соединение, здесь нет. Если контрольная сумма не согласована, обнаружение изменения полезной нагрузки для такого отката требует сигнала другого уровня.

За одинаковым числом скрываются разные возможности

Соединение MPTCP может иметь один подпоток и сохранять возможность создавать дополнительные. После бесконечного отображения отправлять данные разрешается лишь одному подпотоку, остальные должны быть завершены, а возврат к MPTCP внутри этого соединения запрещён. На панели оба состояния могут выглядеть как единица. Но допустимые будущие переходы у них разные.

Перечень адресов не обязательно устраняет неопределённость. RFC 6897 рассматривает абстрактный интерфейс приложения: запросить MPTCP до установления соединения, затем проверить поддержку и получить адреса установленных подпотоков. Документ не доказывает, что конкретная современная операционная система реализует эти символические операции или предоставляет достоверное уведомление о последующем откате.

Он также предупреждает, что список подпотоков может устареть. Прежние вызовы запроса адресов сохраняют сведения первого подпотока, даже если тот уже не используется. Привычный адрес удалённой стороны в журнале поэтому не является инвентаризацией действующих путей. Расширенные уведомления, обсуждаемые в приложении к документу, были направлением дальнейшей работы, а не гарантией базового интерфейса.

Источники здесь нужно читать с учётом их статуса. Карточка RFC 8684 указывает Proposed Standard марта 2020 года, заменивший предыдущую версию MPTCP. Проверенное исправление касается преждевременного подтверждения данных в примере TCP Fast Open, а не запрета возврата из раздела 3.7. RFC 6897 обозначен как Informational марта 2013 года; поиск исправлений не дал соответствующих записей. Это основания для анализа устройства протокола, а не измерения действующего парка оборудования.

Новое соединение — необходимое, но недостаточное условие

Из запрета возврата внутри старого соединения следует необходимость другого соединения для повторного получения MPTCP. Это вывод о необходимом условии, а не обещание успешного согласования. Устройство или особенности пути, вызвавшие откат, могут никуда не исчезнуть.

Конечную передачу иногда разумно завершить в сохранённом потоке, а затем обновить соединение естественным образом. Для длительной сессии может понадобиться явно определённая граница замены. Но правила возобновления и допустимость повторения работы задаёт приложение. Новый сокет не разрешает задним числом неопределённость относительно результата старого запроса.

В рассуждении о проблеме принципала и агента Lu Heng связывает право решать с последствиями решения. В тексте о назначении BTW он ставит описание структуры выше продвижения позиции. Применительно к этому механизму важно показать и сохранённую передачу, и оставшийся вопрос о том, кто вправе назначить момент её замены.