Рейтинг связности провайдеров RU&UA на 15.06.09
К середине июня весьма изменился даже рейтинг с учетом пиров, а ведь он более стабилен из-за отсутствия алгоритмической неустойчивости на искусственном интеллекте определения роли взаимодействующих операторов в иерархии провайдинга – апстрим-пир-даунстрим.
И в этом рейтинге Обит вырвался на 2-ое место. Всего за месяц, не присутствовавший ранее в ТОП1000 оператор пошатнул устои лидеров, пока лидеры упоенно бодаются друг с другом. И это реальный прорыв Обита, т.к. количество его межоператорских стыков в мае-июне продолжало и продолжает неуклонно расти. А из-за того, что у всех количество маршрутизируемых префиксов /24 почти равно, то положение оператора начинают определять количество его межоператорских стыков – degree.
Новые имена для этого рейтинга – Ситителеком, Евротел, Стек. Ситителеком один из ликов многоликой(ого) Филанко. Евротел – чистейшей воды магистрал, ставший на скользкий путь IP транзита. Стек же – ДЦ. И каждому есть место для подвига в рейтинге.
Брр.. Это как получилось что, количество AS в AS-SET у 13 провов оказалось равно друг другу? Такому рейтингу незачот.
Все эти АСки видят всё и это всё могут транзитить. Это же полносвязность, о которой так долго мечтали… Это же BGP коммунизм… :))
Алексей, подскажите pls где посмотреть математику рейтинга. Если была таковая, неплохо бы её вынести отдельной ссылкой, чтоб новичкам было удобно ознакомится с ней.
Описания математики в чистом виде нет(вернее, я не знаю где), есть идеология: http://www.caida.org/research/topology/rank_as/
>Все эти АСки видят всё и это всё могут транзитить.
Правильно ли я понимаю, что остальные 35 в этом списке не видят этого “всего” и не могут “транзитить”?
Ну вот посмотрим внимательнее на прорыв месяца Обит AS8492
На LG ГТ (неважно аплинк он ему или пир) смотрим получаемые префиксы.
http://lg.gldn.net/lg.cgi?query=bgp&protocol=IPv4&addr=neighbors+81.211.2.162+routes&router=cat03.Moscow.gldn.net(KK12)
То есть тот самый клиентский конус и видим 64 префикса. Пересчитываем в /24 получаем 1001 префикс.
Убеждаемся что Обит клиент ГТ
BGP routing table entry for 85.114.0.0/20, version 214200082
Paths: (2 available, best #1, table default)
Multipath: eBGP
Advertised to update-groups:
2 3 4 5 7 8
8492
81.211.2.162 from 81.211.2.162 (85.114.0.2)
Origin IGP, metric 0, localpref 100, valid, external, best
Community: 3216:2001 (Full transit customer and own networks) 3216:4100 (Originated in Moscow) 3216:5100 3216:5120
8492, (received-only)
81.211.2.162 from 81.211.2.162 (85.114.0.2)
Origin IGP, metric 0, localpref 100, valid, external
Community: 3216:5100 3216:5120
Расчёт клиентского конуса по RIPE даёт число AS в конусе 50. (понятно что это забор, но всё же)
Откуда для него насчитался весь рунет непонятно. Не иначе раут лик..
Нет не правильно. “Всё”, как правило, могут транзитить все. Но не всем есть на кого это транзитить. А рейтингуются веса именно клиентских конусов. И самое главное, не все при наличие возможности способны транзитить “всё”, что насчитано в рейтинге. Полосы не хватит.
А по мне этот рейтинг (первые 13) просто показывает подключен ли он хотябы к одному Tier1 или нет.
to NB
Корбина подключена аж к двум. Однако это ей не помогает. Но то, что в таком виде рейтинг бессмысленный согласен :(
О, неужели наконец-то кто-то пытается осмыслить значение попугаев из этого рейтинга :-)
Я вам такую подсказку дам: на http://as-rank.caida.org/ сказано “AS links: BGP ribs from bgp_site (rrc12)” — вот там и нужно искать причины, на http://www.ris.ripe.net/cgi-bin/lg/index.cgi?rrc=RRC121
А еще можете поискать корреляцию прыжков в рейтинге с выходом на DE-CIX.
2Thomas.
Клиентский конус он же не только ближайшие соседи, но и их клиенты, клиенты клиентов и т.п., а также, именно в этом рейтинге, клиенты и клиенты клиентов пир-партнеров. Полагаю руками из райпа до по LG этого не надергать.
Впрочем и роутлики не исключены. По оценкам Renesys 5% маршрутов, распространяющихся по таблицам – кривы. Рейтинг считается по данным за пять дней, и можно насобирать кривизны достаточно. Творческий вопрос – как усреднять всю эту ботву.
2ек:
корелляцию с чьим выходом на DE-CIX искать будем?
to А.Кипчатов
ну клиентский конус в RIPE считается на ура простеньким скриптом по объекту AS-SET. Именно по этому объекту (+ роут обжект) ISP и строят свои фильтры. Рассчитываются в этом случае именно конус, т.е берется запись о каждой AS в AS-SET, а вложенный AS-SET разворачивается до примитива то есть до AS. Вот такой результат мы получаем например для AS-OBIT
(42518|39598|43671|42113|43693|44969|48370|43317)
(48841|34217|44640|42893|43898|42301|44050|21048)
(42839|42563|29371|42137|48704|48905|39866|44380)
(34664|39679|43951|44727|44068|24758|41145|43966)
(44923|49017|47785|35807|48234|35550|8492|44657)
(47133|48974|39390|44230|49200|41546|48481|43747)
(47757|29619)
думаю что РЕТН фильтры строит в том числе и по этому объекту.
ну с конусом всех пиров всё сложнее. Если посмотреть туже Корбину бросается в глаза что член ОПГ не имеет точек присутствия на зарубежных IX и достойного места в табеле. Это конечно важно и кашерно, но боюсь слишком затирает клиентский конус ISP. То есть становится не важно, что у тебя со связностью клиентов и закрытыми пирами лишь бы до IX долезть. Впрочем чуда никто и не обещал :).
Thomas, эту загадку разгадать почти невозможноа может быть и не нужно. То, что Caida считает каких-то странных попугаев, не секрет. Я всегда хотел уйти от чужих непоняток к своим собственным. Тем более, что Кайда стала результаты выдавать нерегулярно и с большим опозданием.
Однако, хотеть и мочь – две большие разницы. Во-первых, я как программист исполнил все свои песни много лет назад и тупо не догоняю требуемый уровень. Во-вторых, моя голова не имеет встроенного IOSa или JunOSа, что тоже плохо. И в-третьих, время, которое я могу выделить на это – ограничено. Но я могу его сколько-то выделить, а так же могу выделить сколько-то ресурсов, например, в виде сервера c хорошей коннективностью. Могу привлечь толковых консультантов, у которых есть знания, ум и опыт, но вообще нет времени. И вот в такой позе я себя обнаруживаю регулярно и спрашиваю сам себя “Ну и фигли?” И ничего себе не отвечаю.
Нечто для оценки коннективности так и остается привидением…
Если кто еще не видел: http://gul-tech.livejournal.com/1039.html
to ek
Видели :). Там алгоритм обещан был. Без него опять набор цифр.
Могу разве что проверить свою AS на предмет соответствия.
Поскольку это всего лишь число клиентских префиксов, то проверить его очень просто. Например посмотев на число анносов в “show ip bgp summary” на looking glass-ах IX-ов (MSK-IX, LINX, DE-CIX, …).
Ура! Наконец-то!
Уважаемый gul-tech, напишите мне сюда хоть что-нибудь. Тогда я узнаю ваш мейл и смогу написать адресное письмо. Ваша принципы про открытость алгоритма и публичность данных мне очень импонируют. Я всегда боролся с загадочными данными и загадочными людьми, делающими вид, что им известна тайна.
Может объеденим усилия?
Добрый день.
Я Ваш email получил, спасибо, отвечу.
Алгоритм опубликую в ближайшее время. Для украинских и российских провайдеров количество префиксов, действительно, можно посчитать гораздо проще, если принять, что точка сборки маршрутов не подключена через клиента ни одного из исследуемых ISP (пиринг допустИм). Но это не даст место в мировом рейтинге – там определять, кто чей клиент, сложнее.
Ну и, собственно, пока это лишь самый примитивный рейтинг – просто количество и размер сетей в клиентском конусе. Раз уж все данные и начальная версия их обработчика есть, теперь можно будет добавлять всякие другие критерии. Что и как считать – предложения принимаются (лучше у меня в блоге, потому что тут могу не регулярно читать).
Павел, в блоге не смог, т.к. там только для своих. Заводить аккаунт в ЖЖ я не буду. Ненавижу рекламные площадки и извращения френдизма. Есть простой нейтральный путь – E-mail.
Проблемы счета верхушки рейтинга в существующем подходе почти нерезрешимы. На полюсе, как известно, компас бесполезен. Надо ориентироваться по звездам. А звезд на верхушке рейтинга нет, там каждый сам себе звезда. Отсюда и регулярная круговая пурга.
В тоже самое время назначить точку сборки маршрутов можно. И это будет работать в рейтинге для далеких от этого умозрительного “центра интернета”. Но т.к. “центра Интернета” нет и даже группа Тирванов, постепенно теряющая свою роль в маршрутизации, то при попытке проанлизировать ценность больших операторов требуется другой механизм счета и другие ориентиры.
Сомневаюсь, что это можно сделать только на базе таблицы маршрутизации.
Короче. есть над чем думать…
Прошу прощения за невежество. Файлики с http://ftp.routeviews.org чем можно посмотреть?
У меня что-то сходу не вышло… :(
Как читать файлики с http://ftp.routeviews.org, написано там же:
http://routeviews.org/data.html
http://www.routeviews.org/tools.html
Алексей,
с верхушкой всё не так плохо, взаимоотношения там определяется с неплохой достоверностью. Я выложил у себя описание алгоритма.
Конечно, сам выбранный критерый (суммарный размер клиентских сетей) слабо отражает “крутизну” провайдера, но тут уж не знаю, как быть.
Обсуждать в ЖЖ я приглашал, чтобы обсуждение было открытым (и, кстати, чтобы комментировать, не обязательно иметь там аккаунт). Но если Вам удобнее в email, пусть будет email.
Павел, я тут кратенько о критериях напишу.
А потом по сути, что хотелось бы видеть в качестве результата, отпишу у вас в блоге.
Про критерии “крутизны”
У каждого оператора есть две абстрактные связности. Связность вверх и связность вниз.
Связность вверх весьма академична, т.к. в штатном режиме у всех есть фулвью. Распределение количества хопов до конкретно моих собственных интересов надо только мне. А среднее распределение могло бы стать мерой, если бы были способы измерить средние интересы пользователей по префиксам. Такие замеры надо вести на клиентских машинах повально и, естественно, что они будут разными для разных народов и групп пользователей. Бесконечное поле деятельности. Подозреваю, что Google способен это сделать, а может уже и сделал. Особенно совместно со своим Хромом. Но он никогда не обнародует эти результаты.
Связность вниз, т.е. клиентские конусы – штука измеряемая со стороны маршрутизаторов. Более простое измерение. И критерий крутизны проще – размер конуса. Казалось бы, что это слишком примитивная мера. Но мое мнение иное. Это очень хорошая мера, т.к. маршрутизация интегрирует в себя сразу несколько аспектов способности оператора подключить и удержать на себе такое количество клиентов. Это означает, что
1. Оператор имеет большое покрытие своей сети
2. Оператор имеет адекватную ценовую политику
3. Оператор имеет адекватную связность вверх
5. Оператор способен пропускать постоянно растущий трафик
6. Оператор имеет адекватную техническую поддержку
(“Адекватный” означает, что предложения оператора соответсвтуют уровню претензий его клиентов. Не более.)
Да, разделить на части эти аспекты и посмотреть по отдельности их оценки из размеров клиентского конуса не получится. Но зато мы сразу получаем рыночную ценность оператора со всеми его технологическими, маркетинговыми и коннективными свойствами. И отслеживаю динамику этого интегрального показателя мы можем четко знать привлекательность оператора для клиентов.
Про точку сбора маршрутов
Вот тут я противник использовать это понятие на любом уровне. Интернет не вертикальная иерархия. Это будет очень сильное упрощение, применимое для популяризации, но не для выявления сути. Любой алгоритм с таким подходом может намерить лишь частности и подменить суть. Самый крутой оператор с отличной связью с этой далекой точкой сборки на местном уровне будет предоставлять плохую по местным интересам связность (очень длинную). И он, привезя ее из-за моря, должен отдавать ее либо дешевле местной, либо вообще раздавать даром, чтобы накопить коннективность. И какой смысл меряться относительно такого ориентира? П
Поэтому попытка честного пересчета клиентских маршрутов, пролегающих через оператора, представляется самой интересной мерой. Тут возникает целый набор неопределенностей. И роутлики, и хайджеки, и почти пустые префиксы, и временные маршруты, и, самое, главное, определение уровней связи даунстрим-пир-апстрим, которые могут быть для двух операторов в разных местах разными. В этом случае, как мне кажется, очень важно иметь набор разных выдач данных по результатам счета для получения тех или иных срезов и использования тех или иных видов фильтрации для сглаживания.
Про это я уже напишу непосредственно в http://gul-tech.livejournal.com/1436.html