Кратко

  • В редакции концептуального проекта SIMAP от 2 октября рабочая группа NMOP добавила REQ-CONGESTION. Будущая привязка протокола должна исключать устойчивую перегрузку от собственного трафика SIMAP. В редакции 13 этого отдельного требования не было.
  • Транспорт с управлением перегрузкой, например привязка на основе TCP, удовлетворяет данному условию на своём уровне. Если у транспорта такого механизма нет, как в приведённом примере с UDP, развёртывание должно ограничиваться контролируемой средой с заранее выделенной или зарезервированной ёмкостью; объём выдачи сервера также требуется ограничить. Пока это действующий Internet-Draft, а не утверждённый RFC.

Сетевую карту легко оценивать по скорости обновления. Сложнее заметить обратную сторону: каждый опрос большой топологии, поток событий и подписка расходуют пропускную способность наблюдаемой инфраструктуры. Более свежая информация не обязательно означает более безопасную работу сети. Редакция 14 документа Service & Infrastructure Maps, или SIMAP, делает эту разницу предметом отдельного проектного требования.

В разделе 4.3 draft-ietf-nmop-simap-concept-14 появился пункт REQ-CONGESTION. Трафик привязки протокола SIMAP не должен создавать устойчивую перегрузку. Сопоставление с редакцией 13 подтверждает, что речь именно о новом пункте. Варианты на транспорте с управлением перегрузкой, в частности на базе TCP, считаются удовлетворяющими этому условию на транспортном уровне. Для вариантов без такой функции документ приводит UDP как пример и требует контролируемой среды с заранее подготовленной или резервной ёмкостью, а также ограничения объёма трафика, который может создать сервер.

Это не общий запрет UDP. Проект не выбирает единственную реализацию SIMAP, не устанавливает универсальный численный предел скорости и не сообщает о реально работающем UDP-варианте, вызвавшем сбой. Условие зависит от свойств транспорта и условий эксплуатации. Столь же неверно считать TCP доказательством общей надёжности сервиса: управление перегрузкой не подтверждает точность карты, правильность доступа или готовность продукта. Новость относится к одной конкретной границе нагрузки.

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

Ссылка на RFC 8085 объясняет предпосылку для UDP: в нём нет встроенного управления перегрузкой, поэтому соответствующие меры должна предусматривать сама программа. RFC существовал до этой редакции; его нельзя выдавать за новую публикацию или свидетельство аварии SIMAP. В Datatracker документ NMOP по-прежнему значится действующим проектом рабочей группы, предназначенным для информационного RFC и ожидающим дальнейшей работы Area Director. Это не окончательное одобрение IETF.

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

Вывод касается права службы наблюдения на ресурсы. Карта может правильно описывать сеть, но это не даёт ей неограниченного бюджета трафика. Надёжность наблюдения включает и доказательство того, что сеть выдержит само наблюдение.

Источники