Кратко

  • Индивидуальный Internet-Draft от 28 октября 2026 года предлагает собирать метрики путей, рассчитывать оценку каждой Segment List и менять их относительные веса внутри активного Candidate Path. Определение качества и функция расчёта остаются настраиваемыми.
  • По RFC 9256 относительный вес определяет предполагаемую долю потоков, а точность распределения зависит от платформы. Изменение числа в контроллере ещё не измеряет долю байтов, установленное состояние устройства или результат приложения.

Стрелка на схеме проста. Весы под ней — чужое решение

Проект рисует активный Candidate Path с тремя Segment List одинакового веса. Один путь ухудшается, статическое распределение в примере по-прежнему направляет туда треть трафика. Авторы предлагают петлю обратной связи: наблюдать качество, вычислять новые веса и уменьшать нагрузку на плохой маршрут. Если рядом есть путь получше, идея кажется естественной. Но конкретный путь получает право называться «лучшим» только после того, как кто-то выбрал способ подсчёта.

У этой петли есть участники. Промежуточные и конечные узлы могут измерять задержку, потери и загрузку. Логический Candidate Path Quality Agent, CPQA, собирает отчёты, агрегирует показатели для каждой Segment List, применяет функцию F и выдаёт набор новых весов. Head-end устанавливает его в плоскости пересылки. Проект требует пропорциональности веса оценке качества, но не устанавливает универсальную формулу, складывающую потери, задержку и загрузку в одно число. Определение качества настраивается. Два добросовестных оператора могут получить от одних и тех же наблюдений разные рекомендации для пересылки.

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

В RFC дробь есть; обещания пропускной способности нет

RFC 9256 описывает уже определённую архитектуру SR Policy. У политики может быть несколько Candidate Path; для обычной пересылки используется активный путь, с оговорёнными исключениями для защиты. Если у него несколько Segment List, head-end применяет взвешенное ECMP на уровне потоков. Список с весом w получает ожидаемую долю w / сумма весов среди направленных потоков. Точность этого распределения зависит от реализации платформы. Вес не является резервом полосы, измерением переданных байтов или временем ответа приложения.

Три одинаковых веса в схеме проекта дают равные доли в модели потоков. Один большой поток может нести больше байтов, чем десятки маленьких. После динамического пересчёта «хороший» путь может принять больше потоков, но почти не прибавить по объёму; на пониженном по весу пути может остаться один тяжёлый поток. В результате команда CPQA, установленный набор весов, фактическая разбивка потоков и эффект для пользователей — четыре разных наблюдения. Реклама, в которой изменение веса уже названо ускорением сети, пропускает три из них.

Проект ограничивает зону вмешательства: меняются веса Segment List в пределах активного Candidate Path. Приоритет Candidate Path и состав списков остаются прежними. Отдельный режим касается перенаправления конкретных перегруженных потоков на менее загруженный список. Общий пересчёт долей и выбор отдельных потоков требуют разных решений. Для второго нужен порядок определения затронутых потоков, выбора альтернативы и прекращения обхода. Если свести оба режима к слову «оптимизация», теряется след того, кто именно передвинул трафик.

Формула может жить в центре или на самом маршрутизаторе

В централизованном режиме CPQA находится у Controller: он принимает отчёты, вычисляет веса и отправляет их head-end через южный интерфейс, например PCEP. В распределённом режиме роль CPQA исполняет head-end: мониторы отчитываются ему напрямую, он сам считает и применяет новые веса. Проект не определяет новое сообщение PCEP. В разделе IANA он не запрашивает назначение кодов и лишь допускает, что будущим протокольным расширениям они понадобятся. Эта работа предлагает схему принятия решения, а не готовую новую команду во всех устройствах.

Центральный расчёт позволяет распространить единую функцию на несколько head-end, но ошибочный параметр также будет распространён широко. Локальный расчёт ближе к месту применения и может опираться на местные данные; соседние head-end при этом способны понимать слово «качество» по-разному. Проект оставляет выбор открытым. Значит, оператору нужен учёт его владельца: какие точки измеряли, какой интервал анализировался, как рассматривались пропавшие отчёты, какая версия F породила новый набор весов и какие веса устройство реально установило.

Защита обмена важна, но не заменяет проверку оценки. Проект говорит, что сообщения между мониторами, CPQA и исполняющим узлом должны быть аутентифицированы; TLS или TCP-AO рекомендуются. Отчёты способны раскрывать внутреннее состояние сети, поэтому при вопросах приватности предлагается рассмотреть шифрование. Авторы также требуют устойчивости к потоку ложных отчётов и рекомендуют ограничение частоты и проверку источника. Аутентификация устанавливает отправителя. Она не доказывает, что точка измерения представляет весь путь, отчёт пришёл вовремя и метрика учитывает нужную нагрузку.

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

Дата новой редакции не меняет происхождения основной идеи. Версия 00 от июля 2026 года уже описывала наблюдение, отчёты, расчёт и применение весов. Октябрьская 01 добавила аргумент о смешанных вычислительных нагрузках и третьего автора. Datatracker относит документ к индивидуальным Internet-Draft. В официальных исходниках нет названной опытной сети, для которой рядом приведены исходные метрики, версия F, установленные веса и результаты приложения. Такой набор изменил бы оценку конкретной реализации.

Источники