Кратко

  • RFC 3448 поручил получателю сообщать скорость прихода, частоту событий потери и время, но RTT и TCP-подобную допустимую скорость по-прежнему вычислял отправитель.
  • Итог ограничивали X_recv, темп роста, pacing и таймер отсутствия обратной связи; ровный график не доказывал ёмкость, точную справедливость или доставку приложению.

Плавность не отменяла обязанности уступать

Оконный TCP резко менял скорость. Для передачи файлов это было приемлемо, для голоса и потокового видео — неудобно. Опубликованный в январе 2003 года RFC 3448 определил TFRC как регулятор скорости для unicast-потоков best effort, конкурирующих с TCP.

«Разумная справедливость» имела узкое значение: обычно оставаться в пределах двукратного отношения к TCP-потоку в тех же условиях. Она не обещала равенство в каждый момент, резерв полосы или качество воспроизведения.

TFRC не был полным транспортом. Он не задавал надёжность и обязательный формат пакета, а мог работать внутри RTP или приложения. Текст, карточка RFC Editor, Datatracker, история, ссылки, последующие упоминания и поиск опечаток подтверждают документ, а не конкретное внедрение.

Получатель считал не пакеты, а эпизоды

Получатель видел последовательность, время, потерю и ECN. Потери примерно в пределах одной RTT объединялись в одно событие. Так сигнал приближался к реакции TCP на один эпизод перегрузки, а не к серии независимых наказаний за каждый пакет.

Интервалы между событиями взвешивались, а обратная величина среднего давала p. Длинный текущий интервал мог уменьшить влияние старой истории. Пять близких потерь и пять потерь в разных RTT создавали разные управляющие данные.

Сжатие не было диагнозом. Оно не сохраняло число пакетов внутри события, не называло очередь и не доказывало физическую причину. RFC 3168 добавлял ECN как сигнал без сброса, но метка не становилась квитанцией приложения.

Получатель также сообщал X_recv и временные данные. Это было свидетельство недавнего прихода, не обещание будущей полосы.

У отправителя оставались три тормоза

По отражённому времени отправитель оценивал RTT и применял уравнение из контекста RFC 2915. Размер пакета, RTT, p и timeout давали X_calc, модельную скорость TCP Reno.

На линию попадал не просто X_calc. В режиме avoidance скорость ограничивалась также удвоенным X_recv и небольшим минимумом, связанным с максимальным периодом отступления. Модель сдерживала оптимизм отчёта; фактический приход сдерживал оптимизм модели.

Третьим пределом было время. За RTT скорость обычно не увеличивалась более чем вдвое, а пакеты распределялись pacing-ом. Даже корректный отчёт становился действием лишь после локального расчёта, потолка и расписания.

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

Молчание уменьшало полномочия

Если feedback не приходил, срабатывал таймер. Отправитель снижал допустимую скорость — часто вдвое уменьшал сохранённый X_recv — и пересчитывал. До первой RTT и первого отчёта существовал прямой путь уменьшения.

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

Так проявлялась граница власти. Получатель предоставлял сведения, а обязанность не перегружать сеть сохранял отправитель.

Последующие версии не превратили модель в результат

RFC 2914 связал congestion control со стабильностью Интернета. RFC 2581 и RFC 3390 дали TCP-контекст, RFC 3550 — RTP-контекст.

RFC 4342 использовал TFRC в DCCP CCID 3. RFC 4828 рассмотрел малые пакеты. RFC 5348 заменил RFC 3448. Эта линия показывает пересмотр, но не всеобщий успех.

p не был причиной, X_recv — ёмкостью, X_calc — разрешением. Выбранная скорость не доказывала пересылку, декодирование или качество. Ровная линия могла сосуществовать с устаревшим отчётом и плохим результатом.

Слои реальности Heng Lu разделяют наблюдение, агрегацию, сообщение, расчёт, действие и исход. Приоритет работающего кода объясняет локальные ограничения вместо слепого доверия числу. Минимальная начальная спецификация подчёркивает границу: контроль перегрузки, а не надёжность или контракт приложения. Это поздняя редакционная интерпретация.

Наследие RFC 3448 — распределённая ответственность. Наблюдатель сообщает; действующий участник всё равно отвечает за осторожность.

Источники