Кратко

  • RFC 3366 рассматривает настойчивость канального ARQ как бюджет времени: сколько канал тратит на восстановление кадра, прежде чем прекратить попытки. Это не бесплатное повышение надёжности.
  • Повторная передача может помочь одному потоку, но добавить сквозную задержку, джиттер или блокировку для остальных; подтверждение кадра не доказывает, что приложение получило данные вовремя.

Кадр — не весь пакет

История начинается ниже IP. Automatic Repeat reQuest, или ARQ, обнаруживает потерянный либо повреждённый кадр канального уровня и отправляет его снова. В зависимости от канала один кадр может нести часть IP-пакета, целый пакет или части нескольких пакетов. Подтверждение отвечает на узкий вопрос: принял ли кадр локальный протокол канала? Оно не доказывает, что пакет дошёл от отправителя до получателя или что приложение ещё может им воспользоваться.

Опубликованный как Best Current Practice 62 документ RFC 3366 просил проектировщиков каналов учитывать эту границу. Он не задаёт конкретную радиотехнологию и не предписывает единого числа попыток. Он объясняет, как локальный цикл восстановления взаимодействует с интернет-трафиком поверх него.

Бюджет попыток расходует общее время

Документ называет «настойчивостью» готовность продолжать попытки. Канал может задать фиксированное число повторов либо позволить таймерам и процедурам обнаружения отказа определить момент остановки. Число не равно времени: на фактическую длительность влияют распространение сигнала, ожидание общего ресурса, очереди, размер кадра и обработка.

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

Идеальная настойчивость наглядно показывает цену выбора: повторять без ограничения, пока получатель ещё может принять кадр. Это может подойти передаче, цель которой — надёжная доставка. Однако на многозвенном IP-пути повторное восстановление может дублировать работу, уже выполняемую сквозным транспортом; оно не гарантирует ту же надёжность, что передача между конечными узлами. Для потокового видео и другого чувствительного ко времени UDP-трафика поздний пакет может быть менее полезен, чем потерянный.

Что канал может узнать, а что не должен угадывать

Кажется естественным выделить больше повторов трафику, который «похож на надёжный», а остальному — меньше. RFC 3366 объясняет, почему одного наблюдения недостаточно. Канал может видеть работу контроля перегрузки, не зная срока приложения и того, что для него важнее — полнота или актуальность. Номера портов могут вводить в заблуждение или переназначаться; туннели объединяют разные потоки; шифрование мешает анализу; отметка класса обслуживания может быть перезаписана или иметь лишь локальный смысл.

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

Опубликованный в 2004 году RFC 3819 расширил рекомендации по проектированию подсетей и рассмотрел взаимосвязь потерь, средней задержки и её вариации. Он поддерживает гибкость, но не превращает пример двух-пяти попыток из RFC 3366 в современное правило или статистику внедрения.

Подтверждение остаётся локальным

Урок RFC 3366 касается и доказательств. ACK кадра фиксирует локальное событие. Выход пакета из канала, принятие данных транспортом и своевременное получение их приложением — более поздние отдельные события, для каждого нужны свои подтверждения. Повтор может снизить потери из-за канала и одновременно увеличить джиттер, задержать обратную связь о перегрузке или отнять время у других потоков.

Проектировщик задаёт локальный бюджет, а путь накапливает последствия. Не зная остального пути и требований приложения к актуальности, устройство не может превратить «больше попыток» в обещание лучшего сервиса. BCP 62 требовал учитывать эту неопределённость в проектировании, а не прятать её за словом «надёжность».

Источники

Lu Heng не был автором RFC 3366. Эти эссе явно обозначены как аналитические линзы для различения рекомендации, работающей реализации, конфигурации и наблюдаемого результата.