Кратко

  • Перестановка меняет порядок прихода; resequencing намеренно задерживает более поздние кадры, пока пробел не заполнен или не признан потерей.
  • Если пропавший кадр не приходит, именно таймер и правило потери определяют задержку всех удержанных пакетов.
  • Канал обычно не знает, относятся ли удержанные пакеты к тому же TCP/QUIC-сеансу и нужен ли их получателю исходный порядок.
  • RACK, QUIC, ROHC и ESP имеют разные ограниченные механизмы; их параметры и работа конкретного экземпляра требуют отдельного доказательства.
  • Редакция 00 — активный Informational Internet-Draft с предложением обновить RFC 3819, а не RFC или подтверждённое внедрение.

Таймер как скрытый распорядитель

Пришли кадры 901, 903, 904 и 905. Кадр 902 не пришёл. Буфер знает, что порядок неполон, но не знает, появится ли 902 вообще. Поэтому он ждёт до события: успешной ретрансляции, раннего заключения о потере или истечения таймера.

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

draft-ietf-intarea-reordering-00 предлагает вернуть этому решению доказательную форму. Подсеть точно знает, что она задерживает доступные данные. Но она обычно не знает, какой вред перестановка нанесла бы транспорту или приложению.

Чистая последовательность после грязного результата

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

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

Поэтому журнал должен содержать не только «gap resolved». Нужны исходная последовательность, путь, попытки передачи, приход, вход в буфер, ожидание, причина выпуска, версия endpoint, транспортная реакция и итог приложения.

Получатель уже умеет судить по времени

Старые алгоритмы TCP могли принять три повторных ACK за доказательство потери. Перестановка вызывала ложную ретрансляцию и лишнее сокращение congestion window. RACK из RFC 8985 использует временные отношения. RFC 9002 даёт QUIC временные и пакетные пороги.

Эти механизмы располагаются там, где видна история соединения. Канал видит свою последовательность, но не всю причинную цепочку.

Однако наличие стандарта не равно включённой функции. Требуются версия, конфигурация, пороги, память и наблюдаемая трасса. Неизвестный endpoint остаётся неизвестным, а не автоматически старым или современным.

Окна безопасности имеют свои часы

Wi-Fi использует packet number для защиты от replay. Поздний законный кадр может иметь номер меньше уже принятого максимума. Если верхние номера выпускать раньше, механизм безопасности должен уметь отличать такую ретрансляцию от повторной атаки.

ESP по RFC 4303 принимает перестановку в пределах скользящего окна. За пределами окна подлинный пакет может быть отвергнут. ROHC и ROHCv2 зависят от профиля и состояния контекста. Поэтому общая надпись «поддерживает out-of-order» не несёт решающего параметра.

Точно так же нормативное требование NAT об обработке некоторых переставленных фрагментов не доказывает поведение каждого установленного устройства. Между спецификацией и наблюдением должен оставаться явный шов.

Почему источники перестановки различаются

Агрегация каналов создаёт различие из-за разных задержек и ёмкости. Беспроводная ретрансляция позволяет более поздним кадрам прийти с первой попытки, пока ранний повторяется. В сотовой сети добавляются HARQ, RLC и Dual Connectivity. DOCSIS имеет собственные контексты и последовательности.

Эти случаи нельзя свести к одному флагу. У каждого свои пределы, идентификаторы и точки наблюдения.

Приведённые в проекте значения Wi-Fi—более 75 мс на P90 и более 400 мс на P99 при семи других конкурирующих станциях—относятся к цитируемому сценарию. Это не универсальная характеристика Wi-Fi и не измерение BTW.

Предложенный порядок полномочий

Подсеть должна избегать ненужной перестановки. Если она неизбежна ради полезной агрегации или надёжной ретрансляции, её обычно следует показать endpoint. Resequencing остаётся только там, где ясные данные показывают, что польза превышает добавленные задержку и jitter.

Это не правило «всегда выпускать». Это правило «докажи, прежде чем ждать». Сторона, которая знает стоимость и не знает семантическую пользу, не должна расходовать время по бессрочному умолчанию.

Статус текста

Редакция 00 опубликована 27 августа 2026 года, истекает 28 февраля 2027 года и предназначена для статуса Informational. При одобрении она обновит раздел 15 RFC 3819. Запросов к IANA нет.

Материал не подтверждает изменения стандартов IEEE, 3GPP или CableLabs, реализацию продукта или эксплуатацию оператором. Проект может измениться, быть заменён или истечь.