Daniel "dbg" Ginsburg

Интеллигенция

2009-09-25T17:37:08Z

Я многократно говорил, что я не люблю интеллигенцию. К интеллигентам отношусь терпимо, а вот интеллигенцию не люблю, как явление.

Вся эта история с письмом Подрабинека замечательно иллюстрирует почему. Этот господин разразился беспредельно гнусным письмом в сторону ветеранов, за что его начали прессовать Наши. ЖЖшная интеллигентная публика тут же начала причитать о незавидной судьбе г-на Подрабинека.

Что же, собственно, заставляет эту по большей части порядочную публику так переживать за мерзавца? Ну ведь объективно, мерзость этого письма видна невооруженным взглядом. Вот например, avva@lj, в порядочности которого я ничуть не сомневаюсь, вынужден прибегнуть к очень натужному ментальному выкрутасу, чтобы вытеснить письмо из сознания и позволить себе сказать "Подрабинек во всем прав и молодец".

Разгадка этого проста. Подрабинек для интеллигенции свой, а своему простится любая гадость, сделанная в отношении чужих. А когда чужие (те же самые, в отношении которых сделана гадость, или другие - не важно) начинают высказывать недовольство, тогда необходимо дать отпор единым фронтом. Эта так называемая интеллигенция не более чем примитивный кланчик, объединенный взаимной лояльностью.

В этой связи очень объяснимой представляется деятельность некоторых наших "правозащитников", несомненно принадлежащих к интеллигенции, которым одна свобода слова и собраний вполне годится, а другая вызывает страх и гневное осуждение.

Да, и это объясняет, почему в интеллигентских кругах самым обсуждаемым вопросом является "что же такое интеллигенция, и кто такой интеллигент". Это совершенно естественно. Для примитивного сообщества, задача которого обслуживать интересы своих членов, вопросы принадлежности, вопросы классификации свой/чужой - это самые важные вопросы.

ГЛОНАСС и ГЭС

2009-09-25T16:03:32Z

Ехал сегодня домой и слушал в машине радио. Радио произнесло что-то вроде: "Крупномасштабной аварии на Саяно-Шушенской ГЭС можно было бы избежать при наличии на станции специальных датчиков ГЛОНАСС, которые измеряют вибрацию. Как сообщает ИТАР-ТАСС, такое мнение высказал сегодня в беседе с журналистами вице-премьер РФ Сергей Иванов."

Я от такой заявки мрачно охуел. Ну, какой нафиг ГЛОНАСС для измерения вибрации? Всякие GPS'ы и ГЛОНАССы меряют с метровой погрешностью. Чего им там можно измерить?

Приехал домой, полез гуглить. Да, Иванова все цитируют. Блоггеры злорадствуют.

Я уж было хотел присоединиться к стройному хору обличителей, но задумался. ГЛОНАСС - это не только ценный мех^W^W источник координат, а еще и источник точного времени. А синхронизация времени очень нужна в сетях с распределенными датчиками.

Иногда все-таки полезно придержать себя и не бросаться оплевывать говном высокопоставленного придурка. Погуглишь для начала - узнаешь что-нибудь интересное.

А вот после погугления уже можно отметить, что Иванов - все равно мудак, и заебал уже торговать своим ГЛОНАССом.

Declare victory and go home

2009-09-19T19:39:34Z

Iljitsch van Beijnum in ietf@ietf:
"a small but potentially meaningful thing that the IETF could do to push IPv6 adoption is move RFC 2460 from draft standard to standard"

Действительно. Конечно. Безусловно. Статус RFC - это, пожалуй единственное, что мешает повсеместной победе добра над разу^W^W^W IPv6 во всем мире.

Архитектура - это застывшая музыка

2009-06-01T19:39:47Z

Сегодня я увидел кое-что Прекрасное.

Я, когда устаю работать и хочу побездельничать, обычно хожу в гуглоридер почитать всякие новости-сплетни, башорг и прочую расслабляющую дребедень. Вот и сегодня... Но до башорга не дошел. Смотрю, сверху в списке драфтик с интригующим названием. Дай, думаю, гляну. Глянул.

Встречайте, E6 Addressing Scheme and Network Architecture.

Аплодирую автору стоя.

Только настоящему таланту дано написать документ настолько беспощадный в своей бессмысленности и бессмысленный в своей беспощадности. Это даже не летающие свиньи из RFC1925 - там все-таки свиней заставляли летать с какой-то подразумеваемой целью. Здесь - нет! Здесь они полетят только потому, что это отвечает эстетическим запросам автора, который не связан не только мелкими и пошлыми соображениями целесообразности, но и целеполагания как такового. Я считаю, что это архиверный подход, - ибо только так можно сделать что-то действительно возвышенное.

Нужна кристальная ясность мысли, чтобы так полно и точно придерживаться в своей работе принципа "много нового и много правильного". Не беда, что то новое не правильно, а правильное не ново. Пускай. Нет никакой необходимости пачкать одно другим. Пусть они просто будут рядом, не касаясь друг друга.

Заслуживает отдельной похвалы выбранная автором стратегия архитектурного проектирования. Если нечто нельзя за пол-лекции объяснить похмельному студенту, то этому совершенно не место в архитектуре Сетей Будущего. Действительно, ну кому нужен этот дурацкий TCP'шный и не-TCP'шный congestion control вместе со всем TCP? LLC2 прекрасно со всем справится, ведь у него даже предусмотрено скользящее окно! Я, кстати, думаю, что здесь недоработка. Скользящие окна стоило бы тоже запретить - от них оверхед и сплошное расстройство чувств.

Я уверен, что такое замечательное начинание, как E6 Network Architecture, найдет своих горячих поклонников. Я уже в их числе.

Detecting ASN32-capable routers in the Internet (revisited)

2009-05-15T15:40:37Z

Уважаемые, я должен вам признаться, что я лох. Тупой лох.

В прошлом посте я предложил критерий выбора одного из решений системы логических уравнений, возникающей при обнаружении ASN32-capable роутеров по сочетаниями BGP атрибутов.

Мало того, что этот критерий довольно произвольный, так он еще и не приводит к единственному решению. Таких решений на том dataset'е, который у меня есть, - 1728 штук. В общем, файлик с решениями, удовлетворяющими выдвинутому критерию, здесь: allminsol.txt.

В принципе, эти решения имеют много общего, так что "какую-то" картинку на их основе можно сложить.

Где была моя голова, о чем я думал? Почему мне показалось, что такое решение одно? Не понятно.

Мне очень стыдно за свою тупость, простите меня. Пойду заливать стыд пивом в ближайшую пивную.

Надо что-то придумывать. Во-первых, побольше данных. Больше данных - больше ограничений в системе - меньше решений. Во-вторых, мой критерий явно дурацкий, нужен другой.

Detecting ASN32-capable routers in the Internet

2009-05-12T20:12:28Z

Уже некоторое время RIR'ы выдают 32-битные номера автономных систем. В Интернете появились префиксы, анонсируемые 32-битными AS. Очевидно, для того, чтобы такие префиксы появились, нужна поддержка в софте роутеров. Основные вендоры, конечно же, уже выпустили софт с такой поддержкой. Однако, одно дело - выпущенный софт, другое - софт, задеплоенный в работающих сетях.

RFC4893 (BGP Support for Four-octet AS Number Space) позволяет переходить к повсеместной поддержке ASN32 постепенно и не требует, чтобы весь Интернет взял и одномоментно проапгрейдил софт на всех роутерах. Для того, чтобы сохранить совместимость новых номеров автономных систем со старым софтом, RFC4893 предусматривает довольно интересный механизм совместимости.

Вкратце, RFC определяет optional transitive атрибут AS4_PATH. Роутеры, которые поддерживают ASN32, при передаче апдейта роутеру без такой поддержки, сохраняют AS_PATH с 32-битными ASN в этом атрибуте, а в AS_PATH 32-битные номера заменяет на специальное значение 23456. Роутеры без поддержки ASN32 прозрачно передают этот атрибут дальше, а когда роутер с поддержкой ASN32 видит в апдейте атрибут AS4_PATH, он восстанавливает AS_PATH, основываясь на текущем значении AS_PATH и AS4_PATH.

Там немножко больше процедур, чем я описал одним абзацем, но пересказывать весь RFC я здесь не буду. Поэтому, интересующихся отошлю к тексту документа. Разобраться довольно не сложно.

Задача

Новый софт необходим только для тех автономных систем, которым присвоен 32-битный номер. Для 16-битных AS апгрейд, в принципе, необязателен - почти все будет работать как надо. С другой стороны, апгрейд имеет некоторые бенефиты: можно использовать в as-path regexp настоящие номера AS, а не 23456, MED будет работать правильно и т.п. Кому-то мелочи, кому-то нет.

Вопрос: а насколько распространен софт с поддержкой ASN32 в настоящий момент?

Метод

Можно попытаться ответить на этот вопрос, наблюдая за BGP-апдейтами, в которых есть атрибут AS4_PATH.

Рассмотрим апдейт вот с такими атрибутами (пример 1):
AS_PATH: 10 20 30 40 23456 50
AS4_PATH: 30 40 65537 50

Что можно сказать, глядя на такой апдейт?

В AS65537 определенно есть новый софт (спасибо, Капитан Очевидность)
В AS10 нового софта не замечено. Если б он там был, то AS4_PATH был бы длиннее.
Про AS40 и AS50 неизвестно ничего. Даже если в них и есть новый софт, то он был "скрыт" новыми роутерами, через которые апдейт прошел потом.
А вот с AS20 и AS30 все несколько интересней. AS_PATH со значением 30 40 65537 50 был сохранен в AS4_PATH в одной из этих двух автономных систем.

Если в AS20 новый софт стоит вперемешку со старым, то могло получиться так, что сначала апдейт попал на роутер с новым софтом, а потом по iBGP ушел на старый - в этом случае получится именно такой AS4_PATH.
При этом в AS20 обязательно должны быть и роутеры со старым софтом. Например, роутер на стыке с AS10. Если б этот роутер имел новый софт, то AS4_PATH выглядел бы как 20 30 40 65537 50.
Если в AS20 нового софта нет, то такой AS4_PATH мог получиться только, если в AS30 роутер на стыке с AS20 - новый.

Видно, что рассматривая апдейты по одиночке, сказать что-то определенное о поддержке ASN32 в каждой из замеченных AS сложно. Кое-что можно, а кое-что нет. Но можно рассмотреть апдейты в совокупности.

Пусть в дополнению к предыдущему апдейту мы увидели еще и такой апдейт (пример 2):
AS_PATH: 30 80 65538
AS4_PATH: 65538

Становится понятно, что апдейт прошел через AS30 только по роутерам без поддержки ASN32. В принципе, могло получиться и так, что в AS30 есть новый софт, но апдейт прошел через другие роутеры. Т.е. либо AS30 не поддерживает ASN32 полностью, либо поддерживает частично. Если AS30 не поддерживает ASN32, то получается, что AS4_PATH в примере 1 был сформирован в AS20, и тогда в AS20 есть частичная поддержка ASN32.

Если мы посмотрим на апдейты за какой-то промежуток времени, то получится система логических ограничений, которая решается классическими методами для таких систем. Такая система имеет решение - в конце концов мы наблюдаем реальный интернет, который существует объективно (предполагаем, что сеть функционирует так, как описано в RFC4893 без ошибок). Такая система имеет много решений - например, есть тривиальное и неинтересное: говорим, что все наблюдаемые AS имеют частичную поддержку ASN32 и тогда все сойдется.

Поскольку решений может быть много, нам надо как-то выбрать одно. В связи с этим, я выдвину предложение: наиболее близким к реальности будем считать то решение, которое содержит наименьшее число утверждений "в автономной системе X мешанина из старого и нового софта", ибо это разврат, а разврата не может быть много. Называйте это presumption of sane operational practices :)

Эксперимент

Я собрал апдейты, содержащие атрибут AS4_PATH за трое суток c 7 мая 17:00 по 10 мая 17:00 (время московское) с http://bgpmon.netsec.colostate.edu/. Этот сервис отдает BGP-апдейты в реальном времени, которые получает от нескольких автономных систем. Файл с данными: as4upd.log. Формат, я думаю, очевиден.

За это время было зарегистрировано 869 апдейтов, несущих AS4_PATH, из них 294 с уникальными AS_PATH и AS4_PATH. 33 различных префикса. 30 автономных систем с номером более 65556. 119 автономных систем (считая 32-битные), про которые зарегистрированные апдейты дают какую-то информацию.

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

Update: Это не просто не "установленный факт". Эти результаты - говно чуть менее, чем полностью. См. следующий пост.

Результаты

Результаты приводятся только ASN16, ибо для ASN32 все очевидно.

Обнаружен новый софт, старого не обнаружено:

AS702
AS1103
AS1213
AS2828
AS3255
AS8758
AS8928
AS9035
AS9070
AS13249
AS20960
AS20965
AS22773
AS23352
AS24863
AS35320
AS42184
AS43561
AS48100
AS48850

Обнаружен старый софт, нового не обнаружено:

AS701
AS715
AS1267
AS1273
AS2516
AS2907
AS2914
AS3043
AS3216
AS3327
AS3491
AS3701
AS3741
AS4436
AS4600
AS4648
AS4697
AS5539
AS5784
AS6298
AS6453
AS6461
AS6762
AS6789
AS6854
AS7018
AS7091
AS7660
AS7911
AS8207
AS8400
AS8452
AS8495
AS8601
AS8866
AS9050
AS10764
AS10876
AS11537
AS12389
AS12552
AS12956
AS12989
AS13030
AS15412
AS15589
AS15703
AS15742
AS15772
AS20485
AS21011
AS21219
AS26769
AS34224
AS42396

Обнаружена мешанина из старого и нового софта:

AS174
AS286
AS812
AS1239
AS1299
AS3257
AS3303
AS3356
AS3549
AS6939
AS8342
AS9002
AS16150
AS22388

Обсуждение

Из 89 16-битных автономных систем (119 всего минус 30 32-битных)

в 55 обнаружен только старый софт (а нового не найдено)
в 20 обнаружен только новый софт (а старого не найдено)
в 14 обнаружено и то, и другое.

В принципе, результаты совпадают с моим представлением о положении дел. Большинство (62%) - разумные консерваторы, которые не стремятся к апгрейду на новый софт, пока их не вынуждают обстоятельства. Некоторые (22%) апгрейдятся, либо из-за относительно небольших преимуществ, которые дает поддержка ASN32, либо из-за каких-то других фич и фиксов.

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

Дальше

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

Blog upgrade

2009-04-26T18:11:38Z

Проапгрейдил MT на 4.25. Новая версия не захотела принимать бэкап старого блога, и пришлось пойти путем экспорта/импорта. Все засосалось, но поменялись идентификаторы постов в фиде, так что ридеры покажут некоторое количество старых записей, как новые. Я дико извиняюсь за это неудобство.

Ежели еще чего поломано, прошу жаловаться. Буду по возможности чинить.

Райффайзен, продолжение

2009-04-03T09:23:09Z

В продолжение к предыдущему.

Райффайзен заявление рассмотрел, расследовал, от претензий отказался, бабло вернул. Причем вернул правильно - по тому курсу, который был на момент возникновения "задолженности".

Ну что ж, молодцы. Уважаю за умение признавать ошибки. Это в наше время среди банков редкость.

Лох - это судьба

2009-03-18T16:07:52Z

Некоторое время назад я матерился в адрес альфабанка (пользуясь случаем в очередной раз желаю им сдохнуть в корчах).

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

Они умудрились год назад перевыпустить одну из моих карточек, но ничего мне про это не сказать. Взяли комиссию, которая задвинула карточный счет в минус на какую-то незначительную сумму. В connect.raiffeisen.ru об этом, естественно, ни слова - там просто нарисован 0. Потом в июле, когда они от меня приняли завление на закрытие карточки, они опять же не сказали о минусе ни слова и заявление не исполнили, при этом само заявление осталось лежать у них в архиве и они мне его сегодня вытащили. А на минус погнались овердрафтовские проценты.

В общем, пару дней назад они таки проснулись и прислали СМСку. Минус за это время вырос в несколько раз и превратился баксов в пятьдесят. В connect.raiffeisen.ru опять же нарисован нолик.

Сегодня ездил писать заявление, краткое содержание которого сводится к "а вы, часом, не охуели?". Рядом стояла парочка, у которой аналогичный минус вырос за несколько лет до 20000 руб.

Я понимаю, кризис-хуизис, долги взыскивать. Но сначала: починить интернет-банк и научить своих клерков не проебывать заявления.

Тем временем, подыскиваю альтернативный банчок, чтобы послать Райффайзен в жопу. Советы принимаются.

Сам себя не похвалишь ...

2009-02-21T15:45:31Z

Смотрю презентации с MWC2009. Bruce Davie и Yakov Rekhter хором рассказывают про использование BGP+labed unicast для масштабирования MPLS в нескольких IGP area. Я такую конструкцию описывал полтора года назад - http://net-geek.org/dbg/2007/08/interarea-ldp.html. Там конфиги и описание, как это работает.

Сижу и горжусь собой.

Там есть еще много интересного. Как появятся презентации в открытом доступе, обсудим. Stay tuned.

Достижение

2009-02-20T19:24:01Z

Вышел вечером на часик пересечься с коллегой в ближайшем кабаке.

Возвращаюсь домой, жена обнюхивает.

- Дорогая, чего принюхиваешься? Да, выпил.
- Да я пытаюсь определить, чего пил.
- Пиво пил.
- Да нет. Это я понимаю. Какое ...
- Ну, давай, определяй.

Принюхивается внимательно.

- Стаут!
- !!!!

Всегда хотел научить жену разбираться в пивах. Теперь горжусь - воспитал.

Long prepends

2009-02-20T17:10:45Z

Вот оно, оказывается, как: http://www.merit.edu/mail.archives/nanog/msg15730.html
Аплодирую наблюдательности.

Оказывается, так ведет себя Mikrotik в некоторых версиях. Если попытаться задать препенд номером AS, как мы все привыкли, то он интерпретирует это не как ASN, а как число ASN, которыми надо запрепендить AS_PATH, возьмет остаток от деления на 256, и собственно, запрепендит - мало не покажется никому.

Мораль? Молчаливые "нормализации" параметров - зло злодейское. Ну и с интерфейсом выделываться не надо - делай семантику как у всех, а то потом люди будут удивляться.

Bennett backs off (Torrent FUD III)

2008-12-05T20:16:59Z

Тов. Беннетт занял более вменяемую (BitTorrent net meltdown delayed) позицию по отношению uTP в новом релизе uTorrent'а. Видимо, общественность вложила ему немного понимания. Что не может не радовать.

Однако, и в новой его статье не со всем можно согласиться.

The overall picture suggests that uTP has a serious flaw. If it simply relies on latency measurements to find preferred paths, it’s likely to favor paths where it’s successfully circumventing management.

Это не недостаток, это достоинство. Под traffic management тут понимаются нелепые попытки придавить одни приложения в пользу других чаще всего при помощи DPI. Так вот, the Net interprets non-neutrality as damage and routes around it.

Я уже говорил и еще раз повторю: доллар вложенный в расширение емкости сети делает сеть лучше, доллар вложенный в DPI - ничего нового не создает, а только [тщетно] пытается перераспределить имеющееся.

When a path is managed to give UDP priority over TCP (as is apparently the case in the Bell Canada network,) uTP will see that path as uncongested even as it's struggling to deliver TCP. In this case, uTP will in fact impair other applications, as we suggested in our previous piece.

Ежели кто-то от большого ума дает UDP приоритет просто по факту того, что это UDP, то это просто неправильно построенная сеть.

This may not be a widespread scenario, but that’s uncertain. Several management tweaks can prevent perverse side-effects like this from happening, such as reconfiguring traffic shapers to key on stream volume rather than protocol type. This approach to traffic shaping is slower to respond than protocol-based systems, however, so uTP just trades responsiveness at the application for responsiveness at the traffic shaper. Another solution would be for traffic shapers to look inside the UDP payload in order to differentiate VoIP from uTP, but this approach is frustrated by the protocol obfuscation option that remains a live feature in BitTorrent over uTP. uTP will cause traffic shaping to become more expensive.

Угу. Есть еще третье решение. Отказаться от идеи per application shaping, но Беннетт "почему-то" ее не высказывает.

Вообще, уважаемый автор, кажется, так и не понял, зачем все это затеяно. А именно, это попытка реализовать less-than-BE без интеллекта внутри сети и добиться того, чтобы bulk data transfers не мешали остальным приложениям. Если эта попытка окажется удачной, то вся затея с засовыванием per application traffic management'а внутрь сети окажется еще более бесполезной, чем она есть сейчас.

Torrent FUD II

2008-12-01T21:41:34Z

Все как обычно. Slashdot'овские pathetic wannabe losers пляшут в комментах - из 600+ коментов только два не мимо тазика.

Тов. Беннетт бесстыдно несет ахинею в уютном бложике и глупо отмазывается в ledbat@ietf.org. Удивительно, все-таки. Раз он подписан на рассылку, значит знает о workgroup'е, наверняка читал charter и материалы с BoF, соответственно знает, кем workgroup была инициирована и зачем. Но это не мешает ему FUD'ить в полный рост.

Torrent FUD

2008-12-01T16:36:37Z

Товарищ Беннетт, кажется, окончательно спятил: "Bittorrent declares war on VoIP, gamers (The next internet meltdown)". Кто бы ему объяснил, что использование UDP не обязательно означает отсутствие congestion control?

В данном случае, uTorrent стал использовать UDP не потому что хочет забрать больше полосы, а наоборот, потому что обычный TCP congestion control излишне агрессивен и хочется уступать больше ресурсов интерактивным приложениям, т.е. это end-to-end реализация less-than-best-effort. Я сугубо это приветствую.

Спецификацию своего протокола они обещают отдать на стандартизацию в IETF. Я предполагаю, что это будет workgroup item в LEDBAT WG.

Впрочем, ничего объяснить ему не получится, ибо он пропагандон с ясной политической целью:
The best way to ensure that uTP doesn’t kill the internet is to throttle it at the source, and any law that stands in the way of ISPs exercising that level of management is deadly to the internet.