Кратко

  • RFC 2354 выбирал восстановление по сроку воспроизведения, полосе, форме потерь, знанию кодека и требуемой точности, а не предлагал один универсальный механизм.
  • Пропуск в последовательности доказывал потерю, но не свободную ёмкость; избыточный ответ мог увеличить перегрузку и запустить следующую потерю.

Документ Колина Перкинса и Ориона Ходсона вышел в июне 1998 года как Informational RFC. Это не Internet Standard и не полный обзор области. В него вошли только методы с участием отправителя; маскировка исключительно на стороне получателя осталась за рамками.

Авторы разделили медиаблок и пакет. Блок представлял временной отрезок из кодека, а пакет мог нести несколько блоков. Точное восстановление байтов, приближённая замена, рассеивание длинного провала на короткие и безупречная копия после срока воспроизведения были разными результатами.

RTP давал два независимых ориентира. Номер последовательности показывал порядок отправки и пропуски. Метка времени указывала место блока в воспроизведении. Поскольку восстановление могло присылать данные не по порядку, планировать нужно было по времени. Пропуск говорил, чего нет; часы — имеет ли ещё смысл ждать.

Страховка соответствовала форме потерь

RFC 2354 ссылался на наблюдения Mbone: в одной большой сессии большинство получателей теряло около 2–5 процентов пакетов, меньшая часть — больше. Одиночные потери преобладали, короткие серии были реже, длинные — редки. Эти числа описывали историческую среду, а не современный Интернет вообще.

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

Повтор работал после события. Получатель запрашивал недостающее, отправитель высылал снова. Результат мог быть точным, но требовал обратной связи, ещё одной передачи и времени. В большой multicast-группе почти каждый пакет мог потеряться хотя бы у одного участника; несогласованные запросы превращали локальный дефект в общую нагрузку. RFC ставил повтор туда, где допустима задержка, и предлагал сочетать FEC для одиночных потерь с дополнительными повторами для серий.

Медианезависимая FEC платила заранее. Паритет или код позволял собрать исходный пакет без запроса. Простой XOR был лёгким; более сильные коды защищали серии ценой вычислений и задержки. Страховой трафик занимал канал даже без потерь.

Медиазависимая избыточность знала устройство кодека. Низкокачественная копия аудио, повтор ключевых частей видео или защита чувствительных битов экономили полосу. Но полезный заменитель не означал точного оригинала.

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

Срок был важнее названия алгоритма

Односторонняя передача могла обменять задержку на качество, поэтому допускала все варианты. Интерактивная сессия не выдерживала кругового времени повтора и глубокого перемежения; оставалась низколатентная FEC. Выбор между общей и кодек-зависимой защитой всё равно зависел от формата.

Главный риск возникал при перегрузке. Дополнительное восстановление заполняло ту же очередь, выбивало новые пакеты и создавало ещё один повод восстановить. RFC предупреждал: крайний объём такого трафика способен стать отказом в обслуживании.

Стандартного управления перегрузкой для потокового мультимедиа тогда не было. Документ использовал приближённое TCP-эквивалентное соотношение как верхнюю границу разумного поведения, но признавал: средняя формула не воспроизводит динамику TCP, а RTT multicast-группы лишь грубая оценка.

Позднее RFC 4588 описал RTP-повторы, RFC 5109 — общую FEC, RFC 8085 — обязанность UDP-приложений контролировать совокупную скорость. Это отдельные контракты, а не один переключатель восстановления.

Наследие RFC 2354 — раздельные квитанции: потеря замечена, восстановительная нагрузка допущена, блок собран, срок соблюдён, восприятие сохранено. Количество попыток не заменяет полезный результат.