July 2008 Archives
На этой неделе в Дублине проходит очередная встреча IETF. Я сижу в Москве и наблюдаю издалека. На сегодня большая часть WG уже выложила свои материалы: https://datatracker.ietf.org/meeting/72/materials.html. Поэтому наблюдать интересно.
Несколько штучек, которые меня заинтересовали:
Virtual Aggregation
Некоторое время назад Paul Francis в grow@ietf рассказал про свою статью "Reducing FIB Size through Virtual Aggregation".
С тех пор он передумал и решил дополнить свой подход BGP-сигнализацией для некоторой автоматизации и, соотвественно, опубликовать свой драфт уже не в GROW, а в IDR. Что он и сделал в начале этого месяца, взяв в соавторы Xiaohu Xu из Huawei. В idr@ietf успели пообсуждать этот драфт немного, поэтому, скорее всего, надо ждать версии -01 в скором времени.
Суть предложенного подхода заключается в инжектировании довольно коротких префиксов (локальных для данной AS), и выкидывания из FIB (но не из RIB) префиксов более длинных. Если использовать правильную систему туннелей (например MPLS-туннелей), то это не приведет к циклам, но, естественно, может удлинить пути для трафика в данной AS. Статья показывает, что если выкидывать из FIB не все префиксы, а только "непопулярные", то можно достичь значительного сокращения объема FIB, не сильно ухудшив общую картину с оптимальностью путей трафика. Я в такой результат вполне верю: по словам коллеги из одного [довольно большого] оператора, на 120K префиксов уходит всего лишь около 1% трафика.
Кроме того, инжектирование покрывающих префиксов может помочь улучшить время сходимости. Здесь есть два фактора:
1) Покрывающий префикс распространяется независимо от специфичного и может служить своего рода fall back'ом для случая, когда next-hop специфичного префикса погиб. С несколькими одинаковыми префиксами обеспечить fallback труднее из-за того, что BGP-спикер анонсирует только лучший путь - это так называемая проблема path invisibility.
2) Маршрутизаторы, которые вбрасывают покрывающие префиксы, образуют уровень иерархии. Соответственно, как указал Robert Raszuk, само число роутеров, которые должны нести fallback пути, меньше. Плюс, если использовать BFD для быстрого обнаружения падения next-hop'ов, то BFD mesh серьезно уменьшается.
Надо сказать, в отношении BGP части у авторов получилась какая-то хуавейня, извините за выражение. Никакой особой автоматизации не получилось, а та, которая получилась, попросту опасна. Но это не отменяет ценности самого подхода, и, думается, что BGP часть поддается доработке.
Я эту конструкцию на прошлых выходных собрал в лабе. Работает (с некоторыми недочетами). Но получилось слишком сложно, чтобы рекомендовать это для реального внедрения прямо сегодня.
Текущая версия драфта: http://tools.ietf.org/html/draft-francis-idr-intra-va-00
Презентация на IETF72, кратко описывающая суть предложенного: http://www.ietf.org/proceedings/08jul/slides/idr-3.pdf
TANA
На этой встрече IETF запланирована BoF сессия TANA (Techniques for Advanced Networking Applications)
О чем речь? В одной из своих заметок я упоминал, что для peer-to-peer приложений пригодился бы новый транспортный протокол со специальным congestion control. Вот TANA именно про это. Цель в разработке алгоритма congestion control, который позволял бы p2p не мешать интерактивным задачам, но тем не менее эффективно утилизировал бы полосу, когда она не затребована другими приложениями. Насколько я понял, технология уже есть и используется в Bittorrent DNA.
BoF session по TANA будет 31-го июля. С нетерпением жду minutes.
TANA BoF agenda: http://www.ietf.org/proceedings/08jul/agenda/tana.txt
TANA Problem Statement: http://www.ietf.org/internet-drafts/draft-shalunov-tana-problem-statement-01.txt
Материалы с IETF P2PI Workshop: http://www.funchords.com/p2pi/ (чисто для смеху, там есть Position Paper of the RIAA - это очень смешно)
RRG on Loc/ID split
После прошлогоднего IAB Workshop on Routing and Addressing в списке рассылки RRG (Routing Research group) идет очень активная работа на предмет как намреорганизовать Рабкрин переделать архитектуру маршрутизации в Internet. Подходов там целая куча: LISP, Six/One, Ivip, TRRP и еще несколько. Останавливаться на них я не буду, отсылаю заинтересованных читателей к архиву maillist'а и соотвествующим статьям и драфтам.
На сессии RRG было (или только будет?) выступление Joel Halpern с очень правильной мыслью. Можно устроить разделение функций locator/identifier не внутри сетевого уровня, а между сетевым и транспортным уровнем: на сетевом locator, а на транспортном identifier. В принципе, идея не новая, но очень, по-моему, правильная. Пойдя по этому пути, можно избежать довольно опасных вещей, которые предлагаются в рамках того же LISP, например.
Презентация Joel Halpern: http://www.ietf.org/proceedings/08jul/slides/RRG-0.pdf
Несколько штучек, которые меня заинтересовали:
Virtual Aggregation
Некоторое время назад Paul Francis в grow@ietf рассказал про свою статью "Reducing FIB Size through Virtual Aggregation".
С тех пор он передумал и решил дополнить свой подход BGP-сигнализацией для некоторой автоматизации и, соотвественно, опубликовать свой драфт уже не в GROW, а в IDR. Что он и сделал в начале этого месяца, взяв в соавторы Xiaohu Xu из Huawei. В idr@ietf успели пообсуждать этот драфт немного, поэтому, скорее всего, надо ждать версии -01 в скором времени.
Суть предложенного подхода заключается в инжектировании довольно коротких префиксов (локальных для данной AS), и выкидывания из FIB (но не из RIB) префиксов более длинных. Если использовать правильную систему туннелей (например MPLS-туннелей), то это не приведет к циклам, но, естественно, может удлинить пути для трафика в данной AS. Статья показывает, что если выкидывать из FIB не все префиксы, а только "непопулярные", то можно достичь значительного сокращения объема FIB, не сильно ухудшив общую картину с оптимальностью путей трафика. Я в такой результат вполне верю: по словам коллеги из одного [довольно большого] оператора, на 120K префиксов уходит всего лишь около 1% трафика.
Кроме того, инжектирование покрывающих префиксов может помочь улучшить время сходимости. Здесь есть два фактора:
1) Покрывающий префикс распространяется независимо от специфичного и может служить своего рода fall back'ом для случая, когда next-hop специфичного префикса погиб. С несколькими одинаковыми префиксами обеспечить fallback труднее из-за того, что BGP-спикер анонсирует только лучший путь - это так называемая проблема path invisibility.
2) Маршрутизаторы, которые вбрасывают покрывающие префиксы, образуют уровень иерархии. Соответственно, как указал Robert Raszuk, само число роутеров, которые должны нести fallback пути, меньше. Плюс, если использовать BFD для быстрого обнаружения падения next-hop'ов, то BFD mesh серьезно уменьшается.
Надо сказать, в отношении BGP части у авторов получилась какая-то хуавейня, извините за выражение. Никакой особой автоматизации не получилось, а та, которая получилась, попросту опасна. Но это не отменяет ценности самого подхода, и, думается, что BGP часть поддается доработке.
Я эту конструкцию на прошлых выходных собрал в лабе. Работает (с некоторыми недочетами). Но получилось слишком сложно, чтобы рекомендовать это для реального внедрения прямо сегодня.
Текущая версия драфта: http://tools.ietf.org/html/draft-francis-idr-intra-va-00
Презентация на IETF72, кратко описывающая суть предложенного: http://www.ietf.org/proceedings/08jul/slides/idr-3.pdf
TANA
На этой встрече IETF запланирована BoF сессия TANA (Techniques for Advanced Networking Applications)
О чем речь? В одной из своих заметок я упоминал, что для peer-to-peer приложений пригодился бы новый транспортный протокол со специальным congestion control. Вот TANA именно про это. Цель в разработке алгоритма congestion control, который позволял бы p2p не мешать интерактивным задачам, но тем не менее эффективно утилизировал бы полосу, когда она не затребована другими приложениями. Насколько я понял, технология уже есть и используется в Bittorrent DNA.
BoF session по TANA будет 31-го июля. С нетерпением жду minutes.
TANA BoF agenda: http://www.ietf.org/proceedings/08jul/agenda/tana.txt
TANA Problem Statement: http://www.ietf.org/internet-drafts/draft-shalunov-tana-problem-statement-01.txt
Материалы с IETF P2PI Workshop: http://www.funchords.com/p2pi/ (чисто для смеху, там есть Position Paper of the RIAA - это очень смешно)
RRG on Loc/ID split
После прошлогоднего IAB Workshop on Routing and Addressing в списке рассылки RRG (Routing Research group) идет очень активная работа на предмет как нам
На сессии RRG было (или только будет?) выступление Joel Halpern с очень правильной мыслью. Можно устроить разделение функций locator/identifier не внутри сетевого уровня, а между сетевым и транспортным уровнем: на сетевом locator, а на транспортном identifier. В принципе, идея не новая, но очень, по-моему, правильная. Пойдя по этому пути, можно избежать довольно опасных вещей, которые предлагаются в рамках того же LISP, например.
Презентация Joel Halpern: http://www.ietf.org/proceedings/08jul/slides/RRG-0.pdf
Уважаемые френды и коллеги, в связи с успешным проебанием телефона, прошу содействия в восстановлении контактов - бэкап телефона был тухл, древен, и вообще на новый аппарат залиться не смог.
Оставляйте, пожалуйста, телефоны в комментах тут (скринятся) или присылайте на dbg-сабака-net-geek.org. Очень прошу. Мне ваши контакты были очень ценны. Спасибо и извините за предоставленные неудобства.
Оставляйте, пожалуйста, телефоны в комментах тут (скринятся) или присылайте на dbg-сабака-net-geek.org. Очень прошу. Мне ваши контакты были очень ценны. Спасибо и извините за предоставленные неудобства.
Что обычно говорят жены своим мужьям, когда уезжают в отпуск, а мужья остаются дома? Ну, например, "много не пей", или там "будешь девок водить - яйца оторву". А вот моя любимая супруга, уезжаючи, сказала: "дорогой, ну ты только по книжным не злоупотребляй, а то я ведь тебя знаю".
Действительно, этому пороку я подвержен. Захожу в книжный магазин - у меня начинается такая легкая лихорадка, немножко кружится голова, и чую подступающее безумия. Выхожу обычно со стопкой в 5-6 книжек - это, считай, легко отделался.
Это у меня наследственное. Мой дед, Павел Давыдович, был широко известен в нашем маленьком городке. Во всех библиотеках и книжных магазинах его знали и всегда были ему рады. Ну и меня, понятно. Благо дед меня таскал по этим злачным местам с малолетства. И домашнюю библиотеку дед содержал. Не в смысле полки и книжки, а натуральную библиотеку, куда можно было взять и записаться. Дед выписывал читательский билет и вперед - бери книжку или две и читай на здоровье.
Собственно, в киоск Союзпечати дед на пенсии устроился не просто так. Тут приходили читатели. Никакой подпольщины и диссидентщины, не подумайте. Просто все знали, что можно подойти, познакомиться и записаться в библиотеку. Я ошивался там в этом киоске после школы. Поэтому запах свежей типографской краски и табака - это очень, очень для меня клево.
А вот дядька мой - вот он натуральный маньяк. В нашу квартиру помещалось тысячи три томов и все было как-то цивилизованно, а в дядькину помещалось в два раза больше и там были Книжные Джунгли. Каждый год мы ездили в бабушке в деревню, что на Урале, и проездом гостили в Среднеуральске у тетки и дядьки и моих двоюродных брата и сестры. Это было офигительно, на самом деле. Помимо всего прочего, дядька собирал фантастику. Всю. Все что из фантастики издавалось в стране, у него было. Так вот, у него в квартире книги везде, вообще везде. Из любой точки протянешь руку, а у тебя в руке что-нибудь очень интересное. Дядьке на днях будет 70. С днем рождения, дядя Гера!
Да. Чего-то я заболтался. Я хотел сказать, что в один из последних заходов в книжный (дорогая, всего три раза за этот месяц, не больше, клянусь!), я приобрел пару книжек Лео Каганова. Как я раньше это пропустил, я не знаю. Мне очень понравилось. Много смеялся, немного грустил. В общем, удовольствие получал. Рекомендую.
Действительно, этому пороку я подвержен. Захожу в книжный магазин - у меня начинается такая легкая лихорадка, немножко кружится голова, и чую подступающее безумия. Выхожу обычно со стопкой в 5-6 книжек - это, считай, легко отделался.
Это у меня наследственное. Мой дед, Павел Давыдович, был широко известен в нашем маленьком городке. Во всех библиотеках и книжных магазинах его знали и всегда были ему рады. Ну и меня, понятно. Благо дед меня таскал по этим злачным местам с малолетства. И домашнюю библиотеку дед содержал. Не в смысле полки и книжки, а натуральную библиотеку, куда можно было взять и записаться. Дед выписывал читательский билет и вперед - бери книжку или две и читай на здоровье.
Собственно, в киоск Союзпечати дед на пенсии устроился не просто так. Тут приходили читатели. Никакой подпольщины и диссидентщины, не подумайте. Просто все знали, что можно подойти, познакомиться и записаться в библиотеку. Я ошивался там в этом киоске после школы. Поэтому запах свежей типографской краски и табака - это очень, очень для меня клево.
А вот дядька мой - вот он натуральный маньяк. В нашу квартиру помещалось тысячи три томов и все было как-то цивилизованно, а в дядькину помещалось в два раза больше и там были Книжные Джунгли. Каждый год мы ездили в бабушке в деревню, что на Урале, и проездом гостили в Среднеуральске у тетки и дядьки и моих двоюродных брата и сестры. Это было офигительно, на самом деле. Помимо всего прочего, дядька собирал фантастику. Всю. Все что из фантастики издавалось в стране, у него было. Так вот, у него в квартире книги везде, вообще везде. Из любой точки протянешь руку, а у тебя в руке что-нибудь очень интересное. Дядьке на днях будет 70. С днем рождения, дядя Гера!
Да. Чего-то я заболтался. Я хотел сказать, что в один из последних заходов в книжный (дорогая, всего три раза за этот месяц, не больше, клянусь!), я приобрел пару книжек Лео Каганова. Как я раньше это пропустил, я не знаю. Мне очень понравилось. Много смеялся, немного грустил. В общем, удовольствие получал. Рекомендую.
Я надеялся, что здравый смысл восторжествует, и С. Терентьева оправдают. Нет, дали год условно.
Что я имею по этому поводу сказать.
Социальная рознь у меня со всей этой сволотой существует объективно. Эту рознь не надо разжигать. Они сами замечательно c этим справляются. В том числе и такими вот приговорами.
А что касается методов наведения порядка среди прокуроров, ментов, журналистов и депутатов, то децимации должны помочь.
Что я имею по этому поводу сказать.
Социальная рознь у меня со всей этой сволотой существует объективно. Эту рознь не надо разжигать. Они сами замечательно c этим справляются. В том числе и такими вот приговорами.
А что касается методов наведения порядка среди прокуроров, ментов, журналистов и депутатов, то децимации должны помочь.
Сейчас в end2end-interest идет интересная дискуссия: Why do we need TCP flow control (rwnd). Там выступают очень правильные люди и говорят очень интересные вещи. David P. Reed (тот самый) поделился очень правильной мыслью:
У меня есть предположение, что мы наблюдаем это прямо сейчас в некоторых реализациях TCP.
Часто на форумах встречаются вопросы про сообщение "TCP: Treason Uncloaked!". Некоторые предполагают, что это атака, некоторые - что это ошибка в реализации TCP.
Код ядра, где возникает это сообщение, вполне прозрачен: если получатель закрыл окно, а у нас есть сегменты "в полете", то что-то здесь не так. В принципе RFC1122 (пункт 4.2.2.16) настоятельно не рекомендует получателю так поступать:
Я предполагаю, что такое поведение получателя - это не ошибка, а намеренное следование принципу, который высказал David Reed. И в самом деле, у нас теперь много мобильных устройств. Чем они характерны? У них мало памяти и они часто выходят в интернет через соединения с огромным RTT.
В этих условиях будет разумным анонсировать относительно большое окно, но буфер подо все окно не резервировать, а надеяться на то, что приложение будет выгребать данные достаточно быстро, и буфер не успеет заполниться. Конечно, помимо всего прочего, у этих устройств относительно слабый CPU, и приложение иногда не успевает потреблять данные из сокета. Тогда стеку не остается ничего другого, кроме как окошко прикрыть, несмотря на то, что раньше окно было анонсированно довольно большое.
Хорошо такое поведение или плохо? С одной стороны у мобильного стека большого выбора нет: линк с большим RTT хочется держать заполненным, но памяти под соотвествующий буфер нет. С другой, стек сервера в случае tcp treason продолжает режим retransmit'ов, а не входит в tcp persist, как было бы, если окошко закрылось нормально, т.е. генерирует пакетов больше, чем нужно.
Есть у кого-нибудь машина, куда приходит много мобильных клиентов? С благодарностью приму запись трафика TCP-сессий, в которых возникал tcp treason. Хочется навести кое-какую статистику.
Может быть, кто-нибудь хорошо знакомый с реализациями TCP на мобильных устройствах может подтвердить или опровергнуть предположение об аллокации TCP-буферов? Идеально - ссылка на документацию.
Некоторые авторы связывают сообщение "TCP: Treason Uncloaked" с DoS-атаками и странным поведением apache. Но все что удается найти по этому поводу - не более чем circumstatial evidence. Мне не ясен механизм, как таким образом можно заDoSить машину. Исчерпать память ядра буферами? Есть у кого-нибудь из уважаемых читателей более внятные свидетельства о связи tcp treason с DoS-атаками?
P.S.: Но вот эта презентация, конечно же, вносит некоторую ясность ;)
So the rwnd parameter is NOT actually measuring buffer pool size. It is actually a control loop that measures the endpoint application's ability to do work.
У меня есть предположение, что мы наблюдаем это прямо сейчас в некоторых реализациях TCP.
Часто на форумах встречаются вопросы про сообщение "TCP: Treason Uncloaked!". Некоторые предполагают, что это атака, некоторые - что это ошибка в реализации TCP.
Код ядра, где возникает это сообщение, вполне прозрачен: если получатель закрыл окно, а у нас есть сегменты "в полете", то что-то здесь не так. В принципе RFC1122 (пункт 4.2.2.16) настоятельно не рекомендует получателю так поступать:
A TCP receiver SHOULD NOT shrink the window, i.e., move the right window edge to the left. However, a sending TCP MUST be robust against window shrinkingВоспроизвести такое сообщение очень просто. Вот скрипт для hping3, который делает именно это. Если будете экспериментировать, не забудьте зафильтровать исходящие RST.
Я предполагаю, что такое поведение получателя - это не ошибка, а намеренное следование принципу, который высказал David Reed. И в самом деле, у нас теперь много мобильных устройств. Чем они характерны? У них мало памяти и они часто выходят в интернет через соединения с огромным RTT.
В этих условиях будет разумным анонсировать относительно большое окно, но буфер подо все окно не резервировать, а надеяться на то, что приложение будет выгребать данные достаточно быстро, и буфер не успеет заполниться. Конечно, помимо всего прочего, у этих устройств относительно слабый CPU, и приложение иногда не успевает потреблять данные из сокета. Тогда стеку не остается ничего другого, кроме как окошко прикрыть, несмотря на то, что раньше окно было анонсированно довольно большое.
Хорошо такое поведение или плохо? С одной стороны у мобильного стека большого выбора нет: линк с большим RTT хочется держать заполненным, но памяти под соотвествующий буфер нет. С другой, стек сервера в случае tcp treason продолжает режим retransmit'ов, а не входит в tcp persist, как было бы, если окошко закрылось нормально, т.е. генерирует пакетов больше, чем нужно.
Есть у кого-нибудь машина, куда приходит много мобильных клиентов? С благодарностью приму запись трафика TCP-сессий, в которых возникал tcp treason. Хочется навести кое-какую статистику.
Может быть, кто-нибудь хорошо знакомый с реализациями TCP на мобильных устройствах может подтвердить или опровергнуть предположение об аллокации TCP-буферов? Идеально - ссылка на документацию.
Некоторые авторы связывают сообщение "TCP: Treason Uncloaked" с DoS-атаками и странным поведением apache. Но все что удается найти по этому поводу - не более чем circumstatial evidence. Мне не ясен механизм, как таким образом можно заDoSить машину. Исчерпать память ядра буферами? Есть у кого-нибудь из уважаемых читателей более внятные свидетельства о связи tcp treason с DoS-атаками?
P.S.: Но вот эта презентация, конечно же, вносит некоторую ясность ;)
