Кратко

  • Уведомление о дубликате может показать, что конкретная повторная передача была лишней, но не доказывает, что все сегменты того же окна дошли без потерь.
  • RFC 3708 допускает вывод о возможности отменить изменение управления перегрузкой только после подтверждения и маркировки как дубликатов всех повторно переданных единиц предыдущего окна — и лишь если не сработало условие остановки.

Показательный пример почти провоцирует ошибку. Отправитель повторно передаёт сегменты N и N+1. Потерян был только N; N+1 лишь задержался. Когда получатель помечает N+1 как дубликат, отправитель узнаёт, что именно эта повторная передача была лишней. Но он не узнаёт, что сеть ничего не потеряла: N остаётся настоящим сигналом потери. Возврат состояния управления перегрузкой для всего окна стёр бы важное свидетельство.

В этом и состоит основная граница RFC 3708 — экспериментального документа, опубликованного в феврале 2004 года. Он описывает осторожное использование уведомлений о дубликатах: TCP DSACK и сообщений SCTP о повторяющихся номерах последовательности передачи (TSN). Документ разделяет два сценария. Стек может просто подсчитывать такие сообщения для мониторинга или учёта. Если отправитель хочет отменить изменения управления перегрузкой, ему нужен более строгий алгоритм различения причин.

Сначала алгоритм проверяет, передавался ли повторно указанный диапазон последовательности или TSN. Если в том же окне повторная передача была больше одного раза, обработка прекращается, а прежнее состояние перегрузки не восстанавливается. Если отправитель вовсе не передавал эту единицу повторно, уведомление может означать, что пакет продублировала сеть. Тогда RFC 3708 требует больше не применять этот алгоритм до конца соединения: последующие уведомления будет труднее отнести именно к лишним повторам отправителя.

Даже уведомления, совпадающего с повторной передачей, недостаточно. Отправитель проверяет все повторно переданные сегменты или части данных в предыдущем окне. Только если каждый из них подтверждён и помечен как дубликат, алгоритм делает вывод, что все повторы были лишними и в окне не было потерь. Если хотя бы один повтор не помечен дубликатом, уведомление не позволяет заключить ничего. Ещё один предохранитель срабатывает при пустой TCP SACK-таблице и DSACK, начинающемся с SND.UNA: такая картина совместима с потерей целого окна ACK, и тогда осторожнее продолжать снижать скорость.

Алгоритму нужна дополнительная память: помимо обычного состояния SACK-восстановления, реализация отслеживает номера последовательности или TSN, уже подтверждённые как дубликаты. Это даёт строго ограниченный вывод, а не уверенность в честности получателя или знание всех событий на пути. В разделе безопасности RFC 3708 предупреждает: при реальной потере получатель может ошибочно объявить переупорядоченные данные дубликатами и тем самым вызвать опасное изменение состояния перегрузки.

RFC 2883 задаёт кодирование дублирующих данных в TCP-блоках D-SACK, но не предписывает отправителю реакцию. RFC 3522 использует другое свидетельство: алгоритм Eifel быстрее обнаруживает лишнюю повторную передачу с помощью временных меток TCP, но для этого опция Timestamp должна присутствовать в каждом пакете. RFC 3708 медленнее, зато разделяет два вопроса: была ли конкретная передача лишней и достаточно ли доказательств, чтобы признать всё окно свободным от потерь. Что делать после обнаружения, документ не определяет.

Источники: RFC 3708, статус RFC 3708, RFC 2883, RFC 3517, RFC 3522, RFC 2960, RFC 4960.