Recently in к обдумыванию Category
Сейчас в 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.: Но вот эта презентация, конечно же, вносит некоторую ясность ;)
Вечер пятницы - время для досужих мечтаний. Вот и мне после вкусного ужина со стаканчиком пива слегка подумалось.
Вот какая есть штука: между работой data plane и работой control/management plane сетевого элемента есть существенный концептуальный разрыв.
Если опустить некоторые детали и упростить, то control/management plane оперирует понятиями логического интерфейса, адреса, маршрута, т.д., а на data plane ничего подобного нет, там есть физическая веревка, несколько таблиц и несколько простых операций: lookup в той или иной таблице (с возможным ее пополнением) по одному или нескольким полям, переписывание части пакета, передача его в физическую веревку или опять на lookup в другой таблице. А все эти subinterfaces, pseudowires, vlans, vrfs и прочая, и прочая, в терминах которых мы конфигурим наши железки, - их на самом деле нет, это интерфейс к реальным механизмам форвардинга, абстракция, предоставленная нам производителем роутера.
Хорошо это или плохо? С одной стороны это хорошо, поскольку необходимо, т.к. те же протоколы маршрутизации оперируют теми же понятиями интерфейса, адреса, маршрута. С другой стороны, иногда эти выразительные средства не позволяют добиться желаемого поведения сетевого элемента, или позволяют ценой немыслимых извращений, или насколько криво отображаются в примитивные средства data plane, что это приводит к самым неочевидным эффектами, из которых потеря в производительность не самый страшный, хотя и самый распространенный. Leaky abstraction и abstraction inversion во всей своей красе.
До относительно недавних пор все двигалось в одну сторону - когда кастомеры били ногами вендора, вендор вводил фичу, расширяя и усложняя control plane'овую абстракцию, но все же оставаясь в ее рамках. Так и появлялись всякие "this over that support", "whatever scalability enhancements", "virtual something", которыми пестрят release notes каждой новой версии софта. Это оптимизации, это поддержанные на официальном уровне accidental features, это закрытие зияющих прорех абстракции. И все это ad hoc, все лоскутно, все реактивно, а не проактивно.
Однако, недавно циску (у некоторых других вендоров есть, кажется, похожие вещи) это достало, и она сделала EVC (Ethernet Virtual Circuit). Это конфигурационный механизм, который позволяет определять поведение непосредственно в терминах match-rewrite-forward. По .1q'шным тэгам, но это уже хорошо. Этот EVC - большой рулез. Это гибкий механизм, который позволяет делать более естественно, то что можно было делать раньше с помощью субинтерфейсов, и делать новые, ранее невозможные вещи. Правильная, очень правильная вещь.
Но этого мало. Я хочу распространения похожего механизма на все data plane'овые операции. Это очень облегчило бы жизнь. Сразу исчезли бы глупые и крайне неочевидные хаки типа global keyword для статических маршрутов в VRF, или совершенно ужасного GRT prefix import into a VRF. Можно было бы строить интересные и полезные наложенные топологии со смешанным L2/L3 форвардингом (ох, у фанатов модели OSI сейчас будет инфаркт, хехе).
Я прекрасно отдаю себе отчет, что возможности разных платформ очень разные, и такой механизм был бы очень тесно привязан к платформе. Ну и что. Можно сделать это платформозависимо, можно придумать что-то вроде MQC - на самом деле, если немного расширить PBR, скомбинировать его с EVC, то получится похоже на то, что я хочу.
Вот какая есть штука: между работой data plane и работой control/management plane сетевого элемента есть существенный концептуальный разрыв.
Если опустить некоторые детали и упростить, то control/management plane оперирует понятиями логического интерфейса, адреса, маршрута, т.д., а на data plane ничего подобного нет, там есть физическая веревка, несколько таблиц и несколько простых операций: lookup в той или иной таблице (с возможным ее пополнением) по одному или нескольким полям, переписывание части пакета, передача его в физическую веревку или опять на lookup в другой таблице. А все эти subinterfaces, pseudowires, vlans, vrfs и прочая, и прочая, в терминах которых мы конфигурим наши железки, - их на самом деле нет, это интерфейс к реальным механизмам форвардинга, абстракция, предоставленная нам производителем роутера.
Хорошо это или плохо? С одной стороны это хорошо, поскольку необходимо, т.к. те же протоколы маршрутизации оперируют теми же понятиями интерфейса, адреса, маршрута. С другой стороны, иногда эти выразительные средства не позволяют добиться желаемого поведения сетевого элемента, или позволяют ценой немыслимых извращений, или насколько криво отображаются в примитивные средства data plane, что это приводит к самым неочевидным эффектами, из которых потеря в производительность не самый страшный, хотя и самый распространенный. Leaky abstraction и abstraction inversion во всей своей красе.
До относительно недавних пор все двигалось в одну сторону - когда кастомеры били ногами вендора, вендор вводил фичу, расширяя и усложняя control plane'овую абстракцию, но все же оставаясь в ее рамках. Так и появлялись всякие "this over that support", "whatever scalability enhancements", "virtual something", которыми пестрят release notes каждой новой версии софта. Это оптимизации, это поддержанные на официальном уровне accidental features, это закрытие зияющих прорех абстракции. И все это ad hoc, все лоскутно, все реактивно, а не проактивно.
Однако, недавно циску (у некоторых других вендоров есть, кажется, похожие вещи) это достало, и она сделала EVC (Ethernet Virtual Circuit). Это конфигурационный механизм, который позволяет определять поведение непосредственно в терминах match-rewrite-forward. По .1q'шным тэгам, но это уже хорошо. Этот EVC - большой рулез. Это гибкий механизм, который позволяет делать более естественно, то что можно было делать раньше с помощью субинтерфейсов, и делать новые, ранее невозможные вещи. Правильная, очень правильная вещь.
Но этого мало. Я хочу распространения похожего механизма на все data plane'овые операции. Это очень облегчило бы жизнь. Сразу исчезли бы глупые и крайне неочевидные хаки типа global keyword для статических маршрутов в VRF, или совершенно ужасного GRT prefix import into a VRF. Можно было бы строить интересные и полезные наложенные топологии со смешанным L2/L3 форвардингом (ох, у фанатов модели OSI сейчас будет инфаркт, хехе).
Я прекрасно отдаю себе отчет, что возможности разных платформ очень разные, и такой механизм был бы очень тесно привязан к платформе. Ну и что. Можно сделать это платформозависимо, можно придумать что-то вроде MQC - на самом деле, если немного расширить PBR, скомбинировать его с EVC, то получится похоже на то, что я хочу.
Давным-давно в беседе на IRC с одним коллегой из циски я сказал, что BGP - давно уже не только и не столько routing protocol, собеседник помялся-помялся, но согласился. Сейчас вот мне эта беседа чего-то вспомнилась и я решил написать немного подробней.
Почему же BGP не только routing protocol. Дело в том, что этот замечательный протокол давно уже приспособили для переноса очень разной информации (я как-то упоминал отличный Google Tech Talk с Яковом Рехтером - он там про это немного говорит). Действительно: QoS Policy Propagation, BGP-based VPLS, autodiscovery всех типов, you name it. То, что нынче ездит по BGP, с трудом можно назвать "маршрутом". Т.е. в современной сети BGP (iBGP, если быть точным, с eBGP есть ) - это не просто способ донести какие-то маршруты отсюда досюда, а универсальная инфраструктура для распространения практически произвольной информации в сети.
Рехтер утверждает, что BGP делает это эффективно. Я почти согласен. BGP, как инфраструктура распространения произвольной информации, очень хорош: можно переносить практически все что угодно, ограничений на количество переносимой информации практически не существует (важна частота изменений, но не само количество), можно всячески фильтровать, кто хочет, тот эту информацию слушает и хранит, а кому какая-то не информация не нужна - так не слушает и не хранит. Все здорово. Почти.
Я могу назвать лишь только одну проблему, но эта проблема меня часто выводит из себя.
Дело вот в чем. Когда появляется очередное приложение BGP, разработчики протокола берут AFI/SAFI, изобретают NLRI с какой-то структурой, возможно придумывают еще один-два extended community со специальной семантикой - и вперед.
Естественно, для того, чтобы новый address family заработал, надо, чтобы его понимали оба BGP пира - ведь если один не понимает этот AF, то эта информация ему и не нужна. Казалось бы, логично. Но нет. Есть исключение - route reflectors. Им на самом деле пофигу на address family, их роль проста - принять анонсы, прогнать BGP decision process и раздать анонс, а что внутри, им по барабану. В нынешней схеме для поддержки новой address family приходится апгрейдить и конфигурить route reflector'ы - во-первых лишняя, а во-вторых рискованная работа: баги, недосып, похмелье, кривые руки.
Что бы спасло положение? Wildcard address family capability. Все просто: отдельный AFI/SAFI для использования в capability advertisement и небольшое дополнение к decision process, типа просто пояснение о том, как его делать на неизвестном типе NLRI.
Написать драфт, что ли?
Почему же BGP не только routing protocol. Дело в том, что этот замечательный протокол давно уже приспособили для переноса очень разной информации (я как-то упоминал отличный Google Tech Talk с Яковом Рехтером - он там про это немного говорит). Действительно: QoS Policy Propagation, BGP-based VPLS, autodiscovery всех типов, you name it. То, что нынче ездит по BGP, с трудом можно назвать "маршрутом". Т.е. в современной сети BGP (iBGP, если быть точным, с eBGP есть ) - это не просто способ донести какие-то маршруты отсюда досюда, а универсальная инфраструктура для распространения практически произвольной информации в сети.
Рехтер утверждает, что BGP делает это эффективно. Я почти согласен. BGP, как инфраструктура распространения произвольной информации, очень хорош: можно переносить практически все что угодно, ограничений на количество переносимой информации практически не существует (важна частота изменений, но не само количество), можно всячески фильтровать, кто хочет, тот эту информацию слушает и хранит, а кому какая-то не информация не нужна - так не слушает и не хранит. Все здорово. Почти.
Я могу назвать лишь только одну проблему, но эта проблема меня часто выводит из себя.
Дело вот в чем. Когда появляется очередное приложение BGP, разработчики протокола берут AFI/SAFI, изобретают NLRI с какой-то структурой, возможно придумывают еще один-два extended community со специальной семантикой - и вперед.
Естественно, для того, чтобы новый address family заработал, надо, чтобы его понимали оба BGP пира - ведь если один не понимает этот AF, то эта информация ему и не нужна. Казалось бы, логично. Но нет. Есть исключение - route reflectors. Им на самом деле пофигу на address family, их роль проста - принять анонсы, прогнать BGP decision process и раздать анонс, а что внутри, им по барабану. В нынешней схеме для поддержки новой address family приходится апгрейдить и конфигурить route reflector'ы - во-первых лишняя, а во-вторых рискованная работа: баги, недосып, похмелье, кривые руки.
Что бы спасло положение? Wildcard address family capability. Все просто: отдельный AFI/SAFI для использования в capability advertisement и небольшое дополнение к decision process, типа просто пояснение о том, как его делать на неизвестном типе NLRI.
Написать драфт, что ли?
В прошлом посте я кратко упомянул вопрос flow fairness в разрезе P2P, а сегодня вот накопалась интересная статья на предмет flow fairness вообще: Flow Rate Fairness:
Dismantling a Religion. Статья написана несколько необычно для такого рода публикаций, вот что пишет сам автор:
It is a classic case of a hegemony where those living within the box don’t recognise the existence of the box, let alone the world outside the box. This paper was written from frustration that no-one inside the box believes that voices outside the box should be listened to. We expect complaints about the blunt style of this paper, but it seemed the only way forward was to force the issue, by making the box look ridiculous in its own terms.И идеи, которые высказываются в статье, на первый взгляд выглядят неоднозначно. По крайней мере, непривычно. Некоторые из них звучат вполне логично, а некоторые мой разум/опыт сходу не принимает. Но прочитать стоит, и стоит обдумать.
