Daniel "dbg" Ginsburg

Few days ago I got an email from Amazon saying "I see that you attempted to purchase "The Early History of Rome (Penguin Classics eBook) (Bks. 1-5)" while in a different country than the United States listed on your Amazon account." The email also requested a proof of residence to the US to let me purchase the said book.

ARE YOU FUCKING KIDDING ME, Amazon?!

That's Livy. TITUS FUCKING LIVIUS, Jupiter damn it!

He lived 2000 year ago, died 1994 years ago to be exact. Don't tell me that some mythical "copyright restrictions" prevent you from selling me this book, all right? Copyright even hasn't been invented back then. Nobody can claim copyright on Livy's works. Get a clue, Amazon.

Moreover I think this whole idea about "this book is not available in [some market] due to copyright restrictions" is just dumb, dumb, dumb. You're dealing electronic goods on the Internet, the global network. There's no "US market" or "European market" or any other geographically restricted market here. It's global, yes it is. My dollars are as green as the next guy's. Get a clue, Amazon.

Yes, I can jump through all these hoops. I can lie in my profile and pretend that I have an US address. I can use a VPN connection to the US to buy the books, but ... You know what, Amazon? The reason for Kindle to exist is not the e-ink display, not the amount of flash memory on the device, not even lightweight sleek design. The raison d'être for Kindle is ability to buy books easily. If I want to read something I should be able to get it with just one click. And you deny me exactly it. Get a clue, Amazon.

I think I'll just go back to pirating books. Yes, it is time consuming. Yes, I have to mess with weird formats and DRM cracking software. Yes, some books are hard to find on pirate sites. But it's not much worse than the artificial roadblocks you put in my way, and it's much, much cheaper. I don't mind paying for books, but I don't want to beg you to kindly accept my money. Screw you, Amazon.

Мне совсем перестало нравиться, как IDR WG проектирует BGP.

Не так давно мы всем интернетом слегка хлебнули фекалий по поводу 32-bit ASN. Там было много разных приколов, но один был очень показательным:

RFC4893 вводит два новых атрибута: AS4_PATH и AS4_AGGREGATOR, оба optional/transitive. Кто умеет, тот обрабатывает, кто не умеет, тот пропускает дальше. Все, вроде бы, замечательно. Однако, получилось как всегда. Спецификация BGP предписывает при ошибке в атрибутах отбиваться notification'ом и класть сессию. Поэтому ошибочный AS4_PATH мог пропутешествовать довольно далеко через цепочку old speakers, которые его не понимают и ошибку обнаружить не могут, и, добравшись, наконец, до new speaker'а, обрушить тому сессию. Совершенно невинную сессию, заметим. В чужой автономной системе. Более подробно об инциденте написано в Арборовском блоге: http://asert.arbornetworks.com/2009/03/more-as4_path-triggered-global-routing-instability/.

Очевидно, что это дефект дизайна BGP, как такового, а не rfc4893, т.е. это могло случиться с любым другим optional/transitive атрибутом.

Общий принцип "fail early" - это хороший принцип, он позволяет проблеме не расползаться, он ограничивает failure domain. Казалось бы, этот принцип противоречит приципу "be conservative in what you send; be liberal in what you accept". На самом деле особого противоречия здесь нет. Вернее, я бы сказал, что эти два принципа находятся в диалектическом противоречии. Баги, увы, случаются, и если мы в какой-то момент получаем явный и откровенный мусор, лучше остановиться сейчас, чем допрыгаться до отдаленных и, скорее всего, очень серьезных последствий. В распределенных системах "garbage in, garbage out" лучше формулировать, как "some garbage in, lots of garbage out". Поэтому, залог успешного протокольного дизайна - это грамотный синтез тезиса (be liberal) и антитезиса (fail early).

Однако, в случае optional/transitive атрибутов принцип "fail early" просто неприменим. Мы не знаем, кто и когда обнаружит ошибку, соответственно, никакого ограничения failure domain'а не получается. В этом случае гораздо лучше реагировать на ошибки умнее и мягче, чем просто гашение сессии. На этот счет есть целых два драфта: draft-chen-rfc4893bis и draft-ietf-idr-optional-transitive. Первый затыкает конкретную дыру с 32-bit ASN, а второй подходит к проблеме более общо.

А вот теперь в нашу сторону катит draft-ietf-idr-add-paths. Замечательная, очень полезная и долгожданная фича, которая решает массу очень противных проблем. Но мне не нравятся детали дизайна. Одна из проблем состоит в том, что предложенное кодирование NLRI не устойчиво к ошибкам.

Пускай два пира A и B пытались договориться об add-path capability, и из-за баги тут или там договорились криво. A думает, что B умеет понимать NLRI в формате add-path, а B ничего про них не знает. Вы мне скажете, что такого быть не может? Еще как может! Таких багов была больше, чем одна.

Теперь A начинает слать апдейты в сторону B в формате add-path (если кому лень заглядывать в драфт, то формат очень простой: 4 октета Path Identifier, а дальше обычный старый NLRI). А B, в свою очередь, будет интерпретировать эти апдейты как будто они в обычном формате.

Казалось бы, B прочитает мусор, произведет синтаксическую проверку, поймет, что дело тут нечисто и, как предписано в случае синтаксических ошибок в NLRI, положит сессию, отбившить положенным notification'ом в сторону A. Все круто?

А вот и не совсем. Совсем нетрудно привести пример комбинации Path Identifier и NLRI, которая не будет распознана, как ошибка синтаксиса. Например, A шлет префикс 15.42.42.0/24 с Path Identifier равным 8. В проводе это будет: 00 00 00 08 18 0F 2A 2A. Если B будет интерпретировать это как обычный NLRI, то он увидит синтаксически верный набор:
0.0.0.0/0
0.0.0.0/0
0.0.0.0/0
24.0.0.0/8
42.42.0.0/15,
и сессию не сбросит. Мало того, B примет эти откровенно мусорные префиксы и распространит их по eBGP, например. Что дальше? Кровь, расчлененка, кишки по сте^Wвсему интернету. Internet-wide routing disruption. Нетадмины умываются слезами, арбор пишет очередной псто с красивыми графиками.

Не надо мне говорить, что вероятность мала. Таких комбинаций можно придумать очень много (если кому не лень, можно подсчитать). А интернет - это один большой Infinite Improbability Drive. Если что-то может случиться, в интернетах оно случится обязательно, уж будьте уверены. "Ford, there's an infinite number of monkeys out here who want to talk to us about this script for Hamlet they've worked out."

Принцип "fail early" опять не срабатывает, хотя в данном случае, это было бы совершенно верным подходом. Просто у нас нет надежного способа отличить мусор от немусора.

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

А побороться с этой неустойчивостью не сложно. Есть много способов. В сегодняшней дискуссии в idr@сами-знаете-где я предложил сделать кодирование add-path заведомо синтаксически невалидным с точки зрения старого способа. Robert Raszuk предложил радикально переработать способ передачи add-path'нутых префиксов. Можно придумать еще с десяток способов с разными достоинствами и недостаткам. Но, ведь, блин, надо же взять и таки придумать. А деплоить add-path в сегодняшнем виде мне немного ссыкотно. Чуть-чуть совсем.

Сегодня все блоги шумят на предмет того, что Yota заблокировала доступ к целому набору сайтов оппозиции: http://www.kasparov.ru, http://www.nazbol.ru, http://www.rusolidarnost.ru, http://www.rufront.ru, http://www.newtimes.ru, http://www.kavkazcenter.com.

Где-то я это уже слышал :)

Ну естественно, я не мог пройти мимо. Я побежал в ближайшую точку продаж и купил модем. Благо, Yota проводит акцию try and buy. Так что у меня есть целая неделя, чтобы покопаться.

Итак, втыкаем модем, проделываем все положенные прыжки и ужимки на предмет регистрации, и идем на http://www.kasparov.ru и видим: "Firefox не может установить соединение с сервером www.kasparov.ru.".

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

Первым делом - проверяем, туда ли мы идем, и не пытаются ли нас обмануть на этапе DNS. Сразу замечаем, что kavkazcenter.com резолвится в 127.0.0.1. С этим сайтом все понятно - он в цензурном списке, и Yota его блокирует без всякого стеснения. Это нормально. "Нормально" не в том, смысле, что я это одобряю - нет, я категорически этого не одобряю и желаю всяческих несчастий всем любителям запретить книжку, газетку или сайтик, какая бы "дрянь" ни была в них написана. Но Йоту можно понять: суд постановил - будь добр выполнять. Увы :(

Остальные же резолвятся совершенно нормально, т.е. в те адреса, в которые должны. В чем же тогда дело?

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

03:08:27.979656 IP (tos 0x0, ttl 128, id 42765, offset 0, flags [DF], proto TCP (6), length 48) 10.128.254.2.3055 > 67.218.116.57.80: S, cksum 0x34cb (correct), 3633491279:3633491279(0) win 64512 <mss 1360,nop,nop,sackOK>
03:08:30.954162 IP (tos 0x0, ttl 128, id 42768, offset 0, flags [DF], proto TCP (6), length 48) 10.128.254.2.3055 > 67.218.116.57.80: S, cksum 0x34cb (correct), 3633491279:3633491279(0) win 64512 <mss 1360,nop,nop,sackOK>
03:08:33.920210 IP (tos 0x0, ttl 253, id 14323, offset 0, flags [none], proto TCP (6), length 40) 67.218.116.57.80 > 10.128.254.2.3055: R, cksum 0x6117 (correct), 0:0(0) ack 3633491280 win 64512
03:08:34.371135 IP (tos 0x0, ttl 128, id 42769, offset 0, flags [DF], proto TCP (6), length 48) 10.128.254.2.3055 > 67.218.116.57.80: S, cksum 0x34cb (correct), 3633491279:3633491279(0) win 64512 <mss 1360,nop,nop,sackOK>
03:08:41.140576 IP (tos 0x0, ttl 253, id 13272, offset 0, flags [none], proto TCP (6), length 40) 67.218.116.57.80 > 10.128.254.2.3055: R, cksum 0x9b8c (correct), 2287877420:2287877420(0) ack 1 win 64512

Так. К нам прилетает RST от сайта. Это, в принципе возможно, но поглядим на TTL: он равен 253. Т.е. тот, кто сгенерировал этот пакет, находится от нас не далее, чем в двух хопах - в сети Йоты! Кто-то в промежутке активно вмешивается в нашу TCP-сессию. Пора подозревать неладное.

Когда есть подозрение на странное поведение промежуточного хопа, то лучше всего исследовать такие случаи путем одновременной записи пакетов с обеих сторон. Так и поступим: у меня есть домашняя машинка, подключенная к Акадо.

Со стороны ноутбука на Yota:
03:52:48.544886 IP (tos 0x0, ttl 128, id 45230, offset 0, flags [DF], proto TCP (6), length 48) 10.128.254.2.3138 > 83.167.114.17.80: S, cksum 0xa2c8 (correct), 2900385036:2900385036(0) win 64512 <mss 1360,nop,nop,sackOK>
03:52:51.555732 IP (tos 0x0, ttl 128, id 45234, offset 0, flags [DF], proto TCP (6), length 48) 10.128.254.2.3138 > 83.167.114.17.80: S, cksum 0xa2c8 (correct), 2900385036:2900385036(0) win 64512 <mss 1360,nop,nop,sackOK>
03:52:55.595682 IP (tos 0x0, ttl 253, id 24737, offset 0, flags [none], proto TCP (6), length 40) 83.167.114.17.80 > 10.128.254.2.3138: R, cksum 0xcf14 (correct), 0:0(0) ack 2900385037 win 64512
03:52:56.082060 IP (tos 0x0, ttl 128, id 45235, offset 0, flags [DF], proto TCP (6), length 48) 10.128.254.2.3138 > 83.167.114.17.80: S, cksum 0xa2c8 (correct), 2900385036:2900385036(0) win 64512 <mss 1360,nop,nop,sackOK>
03:53:03.016041 IP (tos 0x0, ttl 253, id 19571, offset 0, flags [none], proto TCP (6), length 40) 83.167.114.17.80 > 10.128.254.2.3138: R, cksum 0x1ede (correct), 509841875:509841875(0) ack 1 win 64512

Со стороны домашнего компа на Акадо:
03:52:49.348749 IP (tos 0x0, ttl 116, id 45230, offset 0, flags [DF], proto TCP (6), length 48) 109.188.11.104.3138 > 192.168.1.254.80: S, cksum 0xe72c (correct), 2068504495:2068504495(0) win 64512 <mss 1360,nop,nop,nop,nop>
03:52:52.323674 IP (tos 0x0, ttl 116, id 45234, offset 0, flags [DF], proto TCP (6), length 48) 109.188.11.104.3138 > 192.168.1.254.80: S, cksum 0xe72c (correct), 2068504495:2068504495(0) win 64512 <mss 1360,nop,nop,nop,nop>
03:52:56.271631 IP (tos 0x0, ttl 245, id 24736, offset 0, flags [none], proto TCP (6), length 40) 109.188.11.104.3138 > 192.168.1.254.80: R, cksum 0x0c89 (correct), 2068504496:2068504496(0) win 0
03:52:57.018421 IP (tos 0x0, ttl 116, id 45235, offset 0, flags [DF], proto TCP (6), length 48) 109.188.11.104.3138 > 192.168.1.254.80: S, cksum 0xe870 (correct), 2390543161:2390543161(0) win 64512 <mss 1360,nop,nop,nop,nop>
03:53:03.689851 IP (tos 0x0, ttl 245, id 19570, offset 0, flags [none], proto TCP (6), length 40) 109.188.11.104.3138 > 192.168.1.254.80: R, cksum 0x0dcd (correct), 2390543162:2390543162(0) win 0

Первое, что бросается в глаза, - мы получили в точности ту же картику, что и с kasparov.ru, если глядеть со стороны Йоты! Т.е. злые цензоры заблокировали и мою домашнюю машину, чтобы она не нарушала гармонию неуместной надписью "It works!" большими черными буквами на белом фоне.

Второе, и на сервер приходят RST якобы от моего ноутбука: SYN, а следом за ним RST от того же хоста, с тех же портов. Хотя со стороны ноутбука видно, что он получает RST, а никак не посылает. Поэтому приходится заключить, что RST возникают в сети Йоты самостоятельно и непрошенно.

Честное слово, оппозиционер из меня хреновый. Ну, разве что кухонный - так, побухтеть. И на машинке той ничего не живет - апач на ней только для всяких экспериментов, которые боязно проводить там, где этот блог находится. Поэтому мысль о том, что Йота каким-то специальным образом меня ненавидит, придется отмести, как неорганизованную :)

В чем же дело? А вот в чем. Мой домашний апач существует, как я уже сказал, только для экспериментов, и отвечает только весьма небольшому количеству внешних хостов. Убираем файрвольное правило, и, вуаля, все работает замечательно - никаких лишних RST. Нормальную сессию я выкладывать не буду - она скучная, поскольку нормальная.

Вот как интересно получается. Если моя машина работает нормально, то Йота в сессию не вмешивается. А ежели сервер на запросы молчит, то через 6-7 секунда Йота сессию обресечивает. Выходит, левые RST возникают, если на дальнем конце что-то не так.

Зачем Йота может это делать? Я подозреваю, что это попытка освобождать память на ихнем NAT'е побыстрее.

Где же тогда проблема? Берем tcptraceroute (вернее, его аналог по винду) и смотрим:
C:\Documents and Settings\dginsburg\My Documents\tmp\tcpt>tracetcp.exe www.kasparov.ru:80 -t 500

Tracing route to 67.218.116.57 on port 80
Over a maximum of 30 hops.
1       *       *       *       Request timed out.
2       *       *       *       Request timed out.
3       *       *       *       Request timed out.
4       *       *       *       Request timed out.
5       *       *       *       Request timed out.
6       199 ms  127 ms  102 ms  213.248.103.177 [mow-m9-i2-link.telia.net]
7       125 ms  125 ms  261 ms  80.91.253.230   [mow-b2-link.telia.net]
8       291 ms  115 ms  113 ms  80.91.249.210   [s-bb1-link.telia.net]
9       268 ms  217 ms  268 ms  213.248.65.25   [kbn-bb1-pos0-0-0.telia.net]
10      289 ms  215 ms  238 ms  80.91.249.21    [nyk-bb1-link.telia.net]
11      338 ms  312 ms  297 ms  80.91.252.153   [sjo-bb1-link.telia.net]
12      350 ms  305 ms  360 ms  80.239.193.126  [layer42-ic-120233-sjo-bb1.c.telia.net]
13      343 ms  476 ms  330 ms  69.36.225.135   [vl2.sw2.scl.layer42.net]
14      307 ms  420 ms  295 ms  67.218.116.57
15      *       *       *       Request timed out.
16      *       *       *       Request timed out.
17      *       *       *       Request timed out.
18      *
Terminate Event Occurred.

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

Подобьем бабки:
1) kavkazcenter.com действительно заблокирован, и заблокирован явно
2) пакеты в сторону kasparov.ru идут и покидают Йоту совершенно успешно
3) очень похоже, что kasparov.ru не отвечает в сторону Йоты.

Если внимательно погуглить, то можно найти, что проблемы возникают только если йотиному юзеру не повезло, и он натится в сеть 109.188.0.0/18. Что может быть причиной?

Мое предположение состоит вот в чем: блок адресов 109/8 был отдан RIPE для раздачи только в начале этого года. До этого он лежал про запас, а следовательно, фигурировал в списках bogons. Некоторые излишне озабоченные безопасностью люди фильтруют маршруты, пакеты или и то, и то, по этим самым bogon lists, но всегда забывают их обновить. Пруфлинк: http://mailman.nanog.org/pipermail/nanog/2009-October/013941.html (обратите внимание на дату).

(Тяжело вздыхая) Что я могу сказать по всему этому поводу? Много чего. Преимущественно нецензурного.

Update: вот, собственно, и yota отписалась - http://community.livejournal.com/yota_ru/660659.html. Я оказался прав.

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

Поэтому, когда года полтора назад я поехал в Дюссельдорф, ничего особенного от тамошнего пива я не ждал. Ну да, наверняка качественное, наверняка свежее, но не более того.

С коллегами мы побродили по историческому центру и остановились у пивоварни, совмещенной с питейным заведением. Народ выпивал в зале, выпивал на улице, несмотря на мелкий дождик, закусывал чем-то непонятным. Мы, естественно, решили попробовать, что же они тут пьют. Оказалось, что там наливают пиво коричневого цвета, с приятным ароматом. Очень приятное и недорогое. Закуской оказались бутерброды с сырым перченым фаршем. Нам очень понравилось, и мы паслись там всю неделю по вечерам.

После этого я изменил мнение о немецких лагерах, и стал считать, что ежели умеючи, то можно и лагер сделать вкусным.

А тут я чего-то начал гуглить и нагуглил это самое пиво. Им оказался Altbier, а заведением - Uerige, одно из четырех мест, где этот Altbier варят на месте. И таки что выяснилось? Alt - один из немногих немецких элей! Он действительно top fermented, но дозревает при низкой температуре, как лагеры. Его начали варить еще до того, как распространилась мода на лагеры, которые, на самом деле, гораздо более позднее изобретение.

Итого, моя едва зародившаяся вера в лагеры опять погибла. Зато убедился, что вкус меня не подвел :)

Уважаемые коллеги, предлагаю заценить прекрасную картинку. Кто как, а я просто тащусь:

Вы меня спросите: ты, Даня, спьяну с единицами измерения ничего не напутал? Я вам отвечу: нет, ничего я не напутал, все честно.

Вы меня спросите: а что ж это тогда за инфернальный пиздец? А я вам отвечу: это любимое Акадо какбе хочет показывать нам, как ведет себя TCP в перегруженной DOCSIS-сети.

Картиночка получилась очень просто: заливка файла по scp - один tcp поток, никаких торрентов, никакого шумящего вайфая в середине, ничего подобного. Все, повторяюсь, честно.

По словам Акадовской техподдержки, у них чего-то сломалось на нашем CMTS, и пришел дефицит upstream емкости. А DOCSIS - штука многоподлая в отношении upstream'а. Там, как все мы знаем, система request-and-grant и truncated binary exponential backoff (TBEB) с перепосылом ажно до 16 раз. Поэтому, в перегруженном DOCSIS'е пакетик в кабельном модеме может отлеживаться довольно долго.

Ладно, я не буду плеваться в Акаду по этому поводу. У всех аварии случаются. Хотя, конечно, они могли бы временно удавить скорость в upstream в моем районе. Чесслово, лучше честные 256k, чем вот такое вот.

А сегодняшний приз достается замечательным людям из Scientific Atlanta. За ихнее трепетное отношение к буферизации пакетиков. Эти люди не понимают, что пакет, который провалялся в буфере 28(!) секунд - никому нахуй не нужен. Делать такие глубокие буфера - бессмысленно полностью, т.е. абсолютно.

Что делает TCP в таких условиях? Он льет себе потихонечку в буфер, ack'и приходят рано или поздно, дропов нету, TCP разгоняется, заливает буфер еще сильнее и т.д., пока каналом пользоваться становится совершенно нельзя, ибо все начинает разваливаться: броузить нельзя - соединения просто не устанавливаются при такой задержке, почта не ходит, ибо отваливается по таймаутам, про ssh и говорить нечего. Рано или поздно что-то дропнется, TCP замедлится, но разгонится снова, и так далее по классической пиле. Только у нормальной пилы период в сотни миллисекунд, что работать не мешает, а здесь в десятки секунд.

Чем думали наши дорогие друзья из SA, когда придумали сделать такие очереди без AQM? Наверное, какие-то благие побуждения у них были. Впрочем, кто ж их знает - см. эпиграф.

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

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

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

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

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

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

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

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

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

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

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

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

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 во всем мире.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Уже некоторое время 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

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

1. В AS65537 определенно есть новый софт (спасибо, Капитан Очевидность)
2. В AS10 нового софта не замечено. Если б он там был, то AS4_PATH был бы длиннее.
3. Про AS40 и AS50 неизвестно ничего. Даже если в них и есть новый софт, то он был "скрыт" новыми роутерами, через которые апдейт прошел потом.
4. А вот с 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 на этих роутерах получили в довесок и специально выключать ее не стали.

Дальше

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тов. Беннетт занял более вменяемую (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'а внутрь сети окажется еще более бесполезной, чем она есть сейчас.

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

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

Товарищ Беннетт, кажется, окончательно спятил: "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.