Кратко

  • Проект стипендии Pulse организации Internet Society обучил модель различать двусторонние соединения на IXP и многосторонний обмен через сервер маршрутов по открытым данным BGP и проверенным записям нескольких точек.
  • Публикация от 3 сентября сообщает точность свыше 90% на IXP, исключённых из обучения. На проверенных публичных страницах нет их числа, географии, баланса классов, ошибок по классам и отказов от ответа.
  • До применения результата в политике устойчивости или концентрации нужна карточка применимости: совокупность, покрытие, оба направления ошибки, неизвестные случаи и временной дрейф без раскрытия частных договоров.

Испытание построено разумно. Отложить отдельные отношения внутри знакомых IXP было бы проще; исследователи отложили целые точки обмена. Так модель должна перенести выученный признак в другую рабочую среду. По данным Internet Society Pulse, точность осталась выше 90%.

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

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

Метка относится к обмену маршрутами

На IXP две сети могут напрямую установить двустороннюю BGP-сессию. При многосторонней схеме участники передают доступность серверу маршрутов, а тот распространяет её по локальным правилам. Старый метод использовал необязательные BGP community. Новый проект считает эти метки непоследовательными и порой вводящими в заблуждение и выделяет поведенческий признак: сколько точек наблюдения видят один маршрут.

RFC 7947 подчёркивает: сервер маршрутов посредничает в плоскости управления, но сам не пересылает пакеты и обычно не добавляет свой AS в AS_PATH. RFC 7948 описывает клиентские фильтры, политики, базы и сокрытие путей. RFC 9234 различает роли RS, RS-Client и Peer, но не условия бизнеса.

Правильная метка «через сервер» не доказывает объём трафика, цену, собственность, качество или последствия отказа. Правильная «двусторонняя» метка не доказывает выделенную линию, отсутствие расчётов, исключительность или резервирование.

Направление ошибки меняет вывод

Высокое среднее может скрывать провал редкого класса. Это общий пример, а не утверждение о проекте. Если двустороннюю связь принять за многостороннюю, карта завысит зависимость от общего посредника. Обратная ошибка скроет эту зависимость. Для анализа концентрации смещения противоположны.

Покрытие требует отдельного знаменателя. Сколько отношений было допустимо, сколько имело подтверждённую метку и достаточное число наблюдений? Неясные случаи принудительно распределялись по двум классам или оставались неизвестными? 92% после удаления трудных примеров и 92% на всей заявленной совокупности — разные доказательства.

Сам материал Pulse оставляет на будущее более широкую географию и проверку стабильности во времени. Это часть результата, а не примечание, которое можно убрать из служебной записки.

Короткая карточка сохраняет границы

Работа CAIDA 2013 года вывела 206 тысяч связей на 13 крупных европейских IXP и сразу описала ограничения: она не видела двусторонние связи, зависела от неотфильтрованных community и была сосредоточена в Европе. Число связей не выдавалось за объём трафика.

Daniel Kade предлагает карточку применимости для новой модели. В ней нужны источники, окно, единица, правило допуска и минимум видимости; отдельно обучающие и тестовые IXP, регионы и структуры; размеры классов, precision, recall, матрица ошибок, калибровка и отказы. Версии данных, признаков и модели должны сопровождаться тестом дрейфа и условием вывода из применения.

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

Источники