Кратко

  • OC-Reduction-Percentage = 100 в RFC 7683 требует обработать все совпадающие новые запросы, которые реагирующий узел иначе отправил бы; абсолютное уменьшение объёма трафика алгоритм прямо не гарантирует.
  • Для вывода о работе сети нужно связать точный OLR, принятый OCS, решения по каждому запросу, фактический трафик и полезную пропускную способность в одном контексте узлов, областей действия и времени.

Число отдаёт приказ, а не подводит итог

Фраза «снижение на сто процентов» обычно появляется после сравнения двух величин. В Diameter Overload Indication Conveyance, или DOIC, она появляется до результата. RFC 7683 определяет OC-Reduction-Percentage как долю трафика, которую отправителю предлагается сократить относительно того, что он отправил бы без меры. Значение 100 требует применить меры ко всему охваченному трафику: сообщающий узел испытывает тяжёлую нагрузку и прекращает обработку новых сообщений.

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

Профессиональная биография Ben Campbell помогает провести эту границу. IETF Datatracker описывает его как специалиста по коммуникациям реального времени, отмечает прежнюю работу в IAB, в роли ART Area Director и председателя нескольких рабочих групп. Campbell указан среди авторов RFC 7068 о требованиях к управлению перегрузкой, RFC 7683 о механизме DOIC и RFC 8583 о передаче сведений о нагрузке. Во всех трёх документах знание одного узла не выдаётся за наблюдение всей системы.

Решение разделено между двумя ролями

Сообщающий узел определяет перегрузку и выбирает необходимое снижение собственным, зависящим от реализации способом. Затем он отправляет Overload Report. Реагирующий узел получает отчёт, поддерживает Overload Control State — OCS — и выбирает отдельные сообщения запросов для мер по снижению. Метод выбора тоже остаётся за реализацией.

Стандартный loss algorithm обязывает применить меры к запрошенной доле новых сообщений. Но RFC 7683 сразу ограничивает смысл гарантии: алгоритм не хранит состояния и потому не гарантирует абсолютного уменьшения отправленного трафика. Он гарантирует, что требуемая доля новых запросов будет выбрана для обработки.

И сама обработка не всегда означает уничтожение запроса. Правила приложения могут перенаправить его или ограничить. Для Peer Overload Report RFC 8581 предпочитает перенаправление к другим пирам и требует ограничения, если свободной ёмкости недостаточно. Входящий трафик защищаемого узла способен снизиться, а нагрузка соседнего узла, число повторов или ошибок — возрасти. Это разные результаты с разными точками измерения.

Область действия определяет слово «все»

RFC 7683 различает Host Report и Realm Report. Первый применяется к запросам, маршрутизируемым на хост, второй — к запросам realm; Application-ID участвует в сопоставлении состояния. RFC 8581 добавляет Peer Report для перегрузки Diameter Agent, связанный с Application-ID и Diameter-идентификатором пира.

Поэтому 100 означает все запросы, совпадающие с конкретным активным OCS, а не весь Diameter-трафик. Другое приложение, хост, realm или пир могут остаться вне области. Клиент без поддержки расширения может вовсе не иметь такого состояния. Для Peer Report несовпадение SourceID с идентификатором пира, от которого пришёл ответ, обязывает проигнорировать отчёт. Происхождение определяет право управлять трафиком.

У состояния есть версия и срок. Более высокий OC-Sequence-Number обновляет OCS, равный или меньший номер игнорируется. Изменение срока действия или процента требует увеличить последовательность. Пока прежние отчёты не истекли, порядок должен сохраниться даже после перезагрузки сообщающего узла. Расследованию нужна не последняя отправленная цифра, а версия, фактически принятая каждым узлом в момент выбора запроса.

Молчание не отменяет OCS

Исчезновение поля с панели часто принимают за восстановление. В DOIC отсутствие OC-OLR в ответе означает «без изменений» и не удаляет OCS. Сообщающий узел может явно завершить состояние, отправив нулевой срок действия, либо состояние истекает по сохранённому таймеру.

После стопроцентного снижения возврат тоже должен быть постепенным. RFC 7683 рекомендует осторожное возобновление, например пробные сообщения, чтобы мгновенный поток снова не перегрузил узел. RFC 8581 требует управляемого окончания мер и для Peer Report. Окончание отчёта, локальное истечение, возобновление отправки и восстановление сервиса могут происходить в разные моменты.

Если линия инцидента отмечает восстановление на первом ответе без OLR, она неверно читает автомат состояния. Если она объявляет восстановление по одному истечению OCS, то превращает окончание команды в наблюдение производительности.

Три отчёта нельзя сложить

Host, Realm и Peer Overload Reports способны находиться в одном сообщении. RFC 8581 требует сначала применить меры Host или Realm, а затем обработать оставшиеся сообщения по Peer Report с учётом уже сокращённого количества. Такой порядок помогает избежать колебаний нагрузки.

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

Шкала Load направлена в другую сторону

RFC 8583 отделяет постоянную нагрузку от исключительной перегрузки. Load Report — информационная подсказка для распределения или прогноза. OLR — явное требование уменьшить offered load, фактически договор между сообщающим и реагирующим узлами.

Даже числовые шкалы противоположны. В Diameter Load большее значение означает меньшую реальную нагрузку: 65535 соответствует нулевой нагрузке, 0 — стопроцентной. В OC-Reduction-Percentage 0 означает отсутствие нужды в мерах, а 100 — обработку всех совпадающих запросов. Универсальное поле «процент» способно перевернуть смысл, не вызвав технической ошибки.

RFC 7068 предлагает внешний критерий результата: общая полезная пропускная способность под нагрузкой является окончательной мерой ценности решения. Её требуется наблюдать. OLR доказывает запрос, OCS — состояние узла, журнал выбора — обработку, счётчики — прибытие трафика, телеметрия приложения — полезно завершённую работу. Ни одно звено не вправе выступать от имени следующего.

Цепочка квитанций для разбора инцидента

Первая запись фиксирует решение сообщающего узла: его идентификатор, Application-ID, тип отчёта, версию расчёта и время. Следующая сохраняет точный OLR с последовательностью, сроком действия, алгоритмом, процентом и моментом отправки.

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

Только затем сравниваются входы защищаемого и альтернативных узлов, контрфактический объём отправки, отказы, повторы, полезная пропускная способность и результат приложения в одном окне. Если звено отсутствует, формулировка заканчивается там же. «На узле A действовал OCS со значением 100 %» может быть доказано, пока «трафик был нулевым» остаётся неизвестным.

Источники