QoS ingress policer: разъясните кто-нибуть

Что бы таким "не совсем прямым" способом сообщить источнику трафика на другой стороне, что ты не успеваешь принимать данные, тем самым заставляя его снизить скорость передачи?

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

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

Очень может быть.

Вот было-бы здорово ссылочек на обоснование почитать...

Прошу прощения, но ты несколько не в теме :)

дык tcp протокол прекрасно справляеться с изменением скорости канала посредством мехпнизма скользящего окна, так что не боись в буферах провайдера трафик не накапливаеться.

> Резать уже пришедший трафиг бессмысленно
Да ??? И что ж вы тогда предлагаете сделать для ограничения входящего трафика ???

> но это неразумно.
Почему не разумно ? Его ведь не обязательно убивать, его можно придержать - включить IMQ интерфейс, повесить на него какие-нибудь HTB классы, а в конце дисциплину с нужной длиной очереди (например pfifo_fast с limit 100). В итоге TCP пакеты убиваться не будут, но и получены не будут так быстро, поэтому ответы об их успешной доставке будут задерживаться - другая сторона остановит отправку, трафик на время исчезнет, что и требовалось ! Со временем в зависимости от скорости, разрешенной этому трафику (фильтрами, классами,...) для соединения будет установлено оптимальное TCP окно, которое позволит наиболее продуктивно осуществлять передачу.

> Вот было-бы здорово ссылочек на обоснование почитать...
Обоснование чего ? Того, на сколько нужно задерживать ACK пакеты, чтоб скорость входящего трафика изменилась до нужной величины ? Мне было бы тоже очень интересно об этом почитать. Пока что рылся в спецификациях TCP протокола, нихрена не нашел. Разве только то, что ACK пакеты по идее идут пустые, т.е. имеют только заголовок (24 bytes). Сейчас опытным путем пытаюсь расчитать как нужно их выпускать, чтоб на входе получить (примерно) нужную скорость.

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

>прекрасно справляеться с изменением скорости канала

по поводу "прекрасно" ты пожалуй чуть перегнул... :)

>Ну локальный трафик действительно ограничить тяжело.

Это почему?

зависит от реализации.

реализации чего?

> размер очереди в шейпере не бесконечны
Да, но он может быть на много больше, чем max возможный размер TCP окна при модемном соединении, тогда уничтожаться не будут.
Когда я у себя тестил ограничитель, так в очереди было max где-то 60..70 пакетов (это в экстремальных случаях), limit ставил 1000, в итоге везде написано dropped 0.

>реализации чего?

реализации tcp стека

>Да, но он может быть на много больше, чем max возможный размер TCP окна при модемном соединении, тогда уничтожаться не будут.

незабывай что соедининий может быть много а канал достаточно широким.

>реализации tcp стека

Мы сейчас говорим о конкретной реализации - той, что в Linux.

Но если, по твоему, tcp со всем справляется, зачем тогда все эти HTB/CBQ/PRIO/RED/SFQ/TBF и прочее, прочее?

а затем чтобы ограничить скорость на каком-то необходимом уровне а не предотврат ее падения из-за якобы переполнения буферов на стороне провайдера.

>из-за якобы переполнения буферов на стороне провайдера.

А где ты тут видел что-то о переполнении буфера?

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

>а затем чтобы ограничить скорость на каком-то необходимом уровне

В корне не верно, имхо. Те дисциплины, которые я перечислил вообще (ну, возможно кроме TBF) не предназначены для ограничения скорости. Класификация пакетов не есть ограничение скорости их прохождения буквально.

> незабывай что соедининий может быть много а канал достаточно широким.
Я не забываю, просто вопрос был задан таким образом: "Зачем резать уже пришедший трафик и каким образом он может приходить быстрее максимальной скорости модема?"
А если канал действительно большой, то тогда конечно без потерь (DROP) не обойдется, но и они в этом случае тоже могут быть оправданы, потому как "а как иначе ?".

> не предназначены для ограничения скорости
HTB и CBQ не предназначены ? А кто ж тогда ее ограничивает, если, например, из дисциплин есть только HTB и pfifo_fast, плюс еще HTB классы ? Зачем тогда у них параметры rate, ceil ?

>HTB и CBQ не предназначены ?

Для ограничения скорости? Конечно нет! :)

>А кто ж тогда ее ограничивает, если, например, из дисциплин есть только HTB и pfifo_fast, плюс еще HTB классы ?

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

В общем случае, HTB и CBQ используются для планирования (scheduling), а никак не для ограничения исходящего трафика (shaping) или ограничения входящего трафика (policing), или, тем-более, для уничтожения (dropping).

Одно из наиболее простых применений данной дисциплины -- это простое ограничение скорости.

Другой пример - HTB можно использовать для _повышения_ скорости прохождения некоторых пакетов (ssh), разве нет? :)

Цытаты - с http://gazette.linux.ru.net/rus/articles/taleLinuxTC.html

>Значит никто не ограничивает :)

>Только упорядочивает, это может зделать prio базируясь на TOS.

>в следствие чего, прохождение некоторого трафика действительно может быть ограничено

Очень интересная теория. :) :-))) видимо параметры tc bandwidth rate и avpkt так чтобы лучше очередь проходила.

CBQ Class Based Queueing implements a rich linksharing hierarchy of classes. It contains shaping elements as well as prioritizing capabilities. Shaping is performed using link idle time calculations based on average packet size and underlying link band- width. The latter may be ill-defined for some interfaces. Copyright man tc

>пользу другого (елси такового будет больше). это параметр borrow

> Значит никто не ограничивает :) Только упорядочивает...
Хорошо, если я создаю HTB-класс для какого-нибудь вида трафика, например, для почтового. Ставлю ему ceil 3kbps, в то время как ширина канала 16kbps, и наблюдаю, как моя почта ходит со скоростью не больше 3kb/s (по графикам mrtg это видно, да и по watch -n 1 'tc -s -d class show dev imq0'), хотя до включения ограничителя она ходила с max скоростью. Другого трафика в это время нет, канал пустой, а почта все равно принимается со скоростью не больше указанной. Если никто не ограничивает, тогда почему происходит такое ? Причем tc говорит "dropped 0".

> Для ограничения скорости? Конечно нет! :)
> Одно из наиболее простых применений данной дисциплины -- это простое ограничение скорости.
Так вы как-нибудь определитесь :-) Что понимается под понятием "ограничение скорости" ?

> использовать для _повышения_ скорости прохождения... разве нет?
Если в смысле "для _незамедления_", то да, согласен.

Если HTB не ограничивает скорость, зачем тогда нужен весь этот механизм токенов, если можно обойтись простым PRIO с навешиванием соответствующих фильтров ? Да, когда-то на форуме atmsk.ru была статья (не знаю правда на сколько авторитетная, ее копия - http://spirit.org.ua/linux/Advanced-routing-and-QoS.html), так там как раз сказано:
Итак, что дает нам HTB:
...
3) HTB работает похоже на CBQ, но не расчитывает на временнЫе параметры в канале в момент простоев (idle time) для разграничения полос. Вместо этого, он работает как полноклассовый Token Bucket Filter. У НТВ небольшое число параметров, которые неплохо документированы.
4) Вытекает из предыдущего - классы уже работают как TBF-шэйперы и мы можем выбирать qdisc, который будет не резать, а распределять трафик. У CBQ.init в листьях был только TBF.

http://lartc.org/howto/lartc.qdisc.classful.html#AEN1072:
---
HTB works just like CBQ but does not resort to idle time calculations to shape. Instead, it is a classful Token Bucket Filter - hence the name.

> ... для планирования (scheduling), а никак не для ограничения исходящего трафика (shaping)
А тут немного другое написано (http://lartc.org/howto/lartc.qdisc.classful.html#AEN939):
Besides being classful, CBQ is also a shaper...

Что скажете на это ? :-)

Поразмыслив, беру свои слова назад :)

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

Я почему-то не подумал, что pfifo_fast, который по-умолчанию в листьях HTB, действительно не занимается шейпингом, а ограничение происходит на уровне класса, при наличии токенов в буфере которого пакеты попадают в краевую дисциплину.

>"классы уже работают как TBF-шэйперы"

Вот именно эта фраза меня и сбила когда-то :) Как-то не клеился вместе функционал понятий класса и дисциплины.

>Если HTB не ограничивает скорость, зачем тогда нужен весь этот механизм токенов, если можно обойтись простым PRIO с навешиванием соответствующих фильтров

Очень интересный вопрос! Чесно говоря я не далее как сегодня задавался им: а действительно, зачем? Зачем резать скорость, если канал пустой? А если не пустой, но у почтового трафика приоритет низкий, он мешать не будет.

Вот и сижу, думаю весь день, есть ли у меня необходимость использовать HTB, или просто заметить на PRIO (кстати, примерчик интересный - http://xkr47.outerspace.dyndns.org/tmp/tcint3). Понятно, что _вообще_ - причины найдутся, но в моем случае их может и не быть. А ведь проще будет!

ЗЫ. На удивление интересная дисскуссия (для меня) :-)

Кстати! Еще один вопрос.

Пусть A - клиент, B - FTP-сервер. При закачке данных с B большими пакетами, на каждый такой пакет пришедший к A, последний должен ответить маленьким ACK-пакетом.

Пусть A - клиент, B - QIII-сервер. При работе с Q-сервером, A посылает к B маленькие пакеты (кажется даже по UDP, но это не столь важно) и получает маленькие ответы.

Регулируя скорость поступления ответов от A, мы фактически можем регулировать скорость поступления данных от B.

НО! Если одновременно происходит закачка с FTP и игра в Q, регулируя только скорость upload (поступление ответов) ввиду значительно бОльшего размера приходящих пакетов мы НЕ МОЖЕМ предотвратить "захламление" download-канала ftp-данными и лагов в Q. Или нужно _значительно_ (насколько???) задерживать ftp-пакеты.

Хотелось бы услышать, насколько верна моя мысль и выводы :)

> Зачем резать скорость, если канал пустой?
Я тоже задавался этим вопросом, но потом все таки решил оставить HTB. Т.к. ceil у меня во всех классах стоит max (почту я тогда ограничивал для теста), то простоя канала нет. В то же время если все классы будут загружены по максимуму, с помощью rate я могу точно определить гарантированную полосу для тех или иных видов трафика: чтоб низкоприоритетный трафик ужимался, но не до нуля. Плюс к этому у HTB есть буфер, в который попадают пакеты, которым не хватило токенов, т.е. все таки они не убиваются, не возникает простоев - ожидания этих пакетов или ACK на них у отправителя (так пишет Иван Песин, интересно, где он это вычитал ? Как задать размер буфера ?).
Или я чего-то не учел ?

> мы НЕ МОЖЕМ предотвратить "захламление" download-канала ftp-данными
В принципе да, но мы можем попытаться предотвратить, хотя бы на сколько-то. Остался вопрос "на сколько ???". Выше я как раз и писал, что тоже интересуюсь подобным вопросом, но пока конкретного ничего не придумал. Оказывается еще IP пакеты с TCP ACK все таки не совсем одинаковой длины бывают (tcpdump-ом смотрел). Может кто-нибудь сказать почему, от чего она зависит ?

>чтоб низкоприоритетный трафик ужимался, но не до нуля.

Это мысль.

>Плюс к этому у HTB есть буфер

Да, и это пожалуй весомый аргумент. Но, с другой стороны, в листьях PRIO тоже могут быть qdisc с буфером:

tc qdisc add dev eth0 root handle 1: prio
## This *instantly* creates classes 1:1, 1:2, 1:3
tc qdisc add dev eth0 parent 1:1 handle 10: sfq
tc qdisc add dev eth0 parent 1:2 handle 20: tbf rate 20kbit buffer 1600 limit 3000
tc qdisc add dev eth0 parent 1:3 handle 30: sfq

>так пишет Иван Песин, интересно, где он это вычитал ? Как задать размер буфера ?).

Если речь и идет об этом:

---

Давайте теперь рассмотрим параметры дисциплины HTB

default

Необязательный параметр планировщика HTB default задает дескриптор подкласса, куда направляется весь неклассифицированный трафик. По умолчанию равен нулю, следовательно, неклассифицированный трафик минует все классы и обрабатывается с максимальной скоростью.

rate

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

ceil

Задает максимально доступную скорость передачи трафика. При наличии незанятой полосы пропускания в других классах, будет происходить ее заем до данного значения

burst

Определяет размер буфера токенов. Определяет максимальное число байт, для которых могут быть доступны токены в один момент времени.

prio

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

---

То по-моему, он не только о самой root qdisc говорит, но и о классах. prio например, тоже для самой HTB выставить нельзя.

Тоесть, выходит (если об этом речь :), что ситуация почти аналогична PRIO - burst есть только у классов и leaf-дисциплин.

А вычитал он это тут - http://www.tldp.org/HOWTO/Traffic-Control-HOWTO/classful-qdiscs.html#qc-htb

>Может кто-нибудь сказать почему, от чего она зависит ?

Насколько я понимаю, ACK-флаг может присутствовать и не у пустых пакетов, разве нет?

> Если речь и идет об этом:
Не совсем, про параметры я знаю где почитать, а вот про то, что у HTB есть буфер, в котором ожидают пакеты, если они классифицированы в класс, у которого кончились свободные токены и заем осуществить не может (достигнут ceil), я нигде не нашел. Если этот буфер есть, то какой его размер, можно ли его задать вручную ?

> может присутствовать и не у пустых пакетов, разве нет?
Вот и я пока не догоняю: в одних доках написано "могут", в других - нет, некоторые люди тоже говорят, что могут, но данные в этих пакетах будут игнорироваться... Кому верить ? :-)

> Если речь и идет об этом

>Не совсем

А о чем? Я вот только что порылся по ссылочкам, ничего про буфер не нашел.

Ты, того, если вдруг что интересное найдешь, стукни plz в аську - 212063901. Например, по поводу таймаута для ACK пакетов.

> А о чем?
Ну у него написано такое:
Максимальное значение полосы пропускания, до которого может занимать класс, определяется параметром ceil, по достижении которого пакеты начинают помещаться в буфер, ожидая токены.

Про этот буфер я и говорил. А на счет icq - ты у меня уже давно добавлен, но пока что я ни разу не видел тебя online. :-)