Кратко

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

Молчание отправителя — не вся система

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

RFC 3738, опубликованный в апреле 2004 года как Experimental RFC, исследовал другое распределение работы. Wave and Equation Based Rate Control (WEBRC) — строительный блок управления перегрузкой для протоколов многоадресной передачи. Получатели не должны были отправлять отчёты о перегрузке отправителю. Каждый измерял состояние своего пути, вычислял целевую скорость приёма и менял набор многоадресных каналов, к которым был подключён. Поэтому «без обратной связи отправителю» не означает «без сигнала». Сигналом служило обычное сетевое действие: подключение к каналу или отключение от него.

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

Управление скоростью через подключение к каналам

WEBRC делил сеанс на низкоскоростной базовый канал и несколько волновых каналов. Базовый канал помогал получателю определить положение в цикле временных интервалов и оставался активным всё время участия. Скорость волновых каналов менялась во времени: начав с высокой скорости, волна снижала частоту пакетов на последовательных интервалах, затем переходила в период покоя, после чего цикл повторялся.

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

Целевая скорость не была произвольным предпочтением. WEBRC оценивал среднюю вероятность потери пакетов и среднее многоадресное время кругового обхода, затем подставлял измерения в TCP-подобное уравнение, основанное на идеях TFRC. Результат определял, можно ли добавить ещё один слой и остаться в пределах цели. RFC задавалась цель разумной справедливости при конкуренции с TCP и более плавной пропускной способности во времени; компромиссом была более медленная, чем у TCP, реакция на изменение доступной полосы. Это цели проектирования в спецификации, а не полевые измерения, доказывающие результат конкретного развёртывания.

Обмен сложностью и осведомлённостью

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

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

RFC 3738 входил в более широкую работу RMT. RFC 3269 описывал модульный подход к надёжному многоадресному транспорту, а RFC 3048 задавал рамку для сочетания строительных блоков. Поэтому WEBRC можно было объединять с механизмами надёжности или доставки объектов, но такая комбинация не сливала их обязанности. Контроль перегрузки может регулировать приём, не гарантируя восстановление объекта; уровень исправления ошибок может помочь восстановлению, не сообщая отправителю, какой получатель закончил.

Статус RFC 3738 — часть этой истории. Авторы прямо обозначили спецификацию как экспериментальную и предложили ждать первоначального развёртывания и практического опыта, чтобы оценить эффективность и масштабируемость. Рабочая группа заявила о намерении повторно подать документ как Proposed Standard, если механизм позднее сочтут подходящим. Это намерение не доказывает ни развёртывание, ни последующее решение о стандартизации, ни эксплуатационное принятие. Документ фиксирует конструкцию и её предположения; для доказательства работающей реализации, измеренного поведения и последующего нормативного решения нужны отдельные данные.

Источники