Шейпинг входящего потока в OpenBSD и NetBSD

Смотри man altq.conf на предмет CDNR Commands , только этот кондиционер просто дропает пакеты.

> Смотри man altq.conf

вы давно OpenBSD видели? там уже три релиза как altq в pf....
и соответственно такого мана нету. есть pf.conf

а тому кто спрашивает:
шейпинг входящего потока -- дурость полная. сами подумайте
над этим.

>шейпинг входящего потока -- дурость полная.

Почему? Я вот резал. Да, какие-то пакеты теряются, но интерактив повышается, что есть плюс (для меня).

Ну а если есть возможность их не просто резать, а в буфер загонять, то почему нет? :)

> Ну а если есть возможность их не просто резать, а в буфер загонять, то
> почему нет? :)

я спрашивал ЗАЧЕМ это делать. есть разумное объяснение.
а не интерактив... нету такого сетевого термина.

дело все в том, что со входящим трафиком сделать-то
ничего нельзя. он уже пришел. вы же не ограничите
upstream... так что тут дело как мне кажется
абсолютно однозначное...

> есть разумное объяснение.
читать надо так:

 есть разумное объяснение?

(с вопросительным знаком =)

Чтобы сильно хорошо, то я пока сам не понимаю :(

Но например, такое объястение: если не резать вдодящий трафик на чуть меньшей скорости, чем реально есть, пакеты уходят в круг по буферу у большому провайдера, что плохо сказ0ывается на интерактивном трафике (ssh, иргы).

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

Вообще-то, я был бы _очень_ признателен за любые объяснения по этому вопросу, поскольку меня эта тема сильно интересует, а в последнее время я сильно запутался (особенно после споров по этому вопросу со spirit в аське :)

А может лучше управлять искодящим трафиком для этого соединения и менять размер MSS tcp соединений. Сами говорите раз трафик интерактивный то если от вас запрросы уходят медлено то и к вам будут приходить тоже медленней к томуже есть prio.

А оно так и работает в конце-концов :)

>к томуже есть prio.

Я в курсе, но это не решает проблемы.

> пакеты уходят в круг по буферу у большому провайдера

я не понимаю такой фразы. какой круг? какой ``большой провайдер''?

у вас канал с upstream один и тот же. скажем 10Mbit.
через его шлюз поступают пакеты на ваш шлюз. складываются
в приемную очередь TCP/IP стека на вашем шлюзе. ядро
поочередно достает пакеты из mbuf и обрабатывает.

а теперь: про какой буфер и круг идет речь?

> Или так: мне кажется, что в ввиду того, что разница в размере
> запросов и ответов сильно разная у разных видов трафика, управляя
> только ответами, управлять хорошо трудно.

а запросами у вас попросту нет возможности управлять.
ответы можно, как уже было сказано, приоритизовать.
например, если вы транслируете voice over IP, то этот
трафик можно отпускать с большим приоритетом.
но это означает ровно следующее: ядро будет стараться
пропихнуть эти пакеты ближе по списку mbuf'ов...

>а теперь: про какой буфер и круг идет речь?

Допустим, провайдер программно режет скорость канала на меня. И канал в конкретный момент времени загружен на 100%. Что будет, если данные продолжают поступать?

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

А если я зарежу у себя скорость на уровне 90-95% от возможной, такого не произойдет. Да, скорость в целом будет _немножко_ меньше, зато задержки - тоже.

> Допустим, провайдер программно режет скорость канала на меня.

допустим...

> И канал в конкретный момент времени загружен на 100%

канал между вами и провайдером? допустим...

> Что будет, если данные продолжают поступать?

куда? к вам? канал загружен на 100%, данные не будут поступать.
они не будут отправлены. так работает стек.

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

так какой канал загружен? но в любом случае это пока правда...

> А если я зарежу у себя скорость на уровне 90-95% от возможной,
> такого не произойдет

произойдет. а как же иначе? даже если вы будите отдавать upstream
ICMP сообщения на снижение скорости (SOURCE QUENCH), это только
будет значить, что ваши пакеты будут на шлюзе у прова 
забуферизированы.

этим вы ничего не выигрываете. вы не можите контролировать каналы
провайдера...

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

фактически же, например для TCP траффика, сигнал о начале новой
посылки -- пришедший ACK. ACK задерживается, посылка не
осуществляется.

логика работы. должна быть логика работы! в шейпинге входящего
трафика ее нет.

Предыдущий пост - про простое ограничение входящего трафика, теперь про классификацию.

>а запросами у вас попросту нет возможности управлять. ответы можно, как уже было сказано, приоритизовать.

Я понимаю, но суть-то не в этом.

Пусть я зарежу _исходящий_ поток для ftp и Q3 на (образно) 10К. Для ftp-данных, в этот поток попадают в основном (насколько я понимаю) ACK'ки. Для Q3 - половина всего трафика.

Но беда в том, что десять исходящих ftp-пакетов, отначает 10*1500 байт входящего ftp-трафика, а десять исходящих Q3-пакетов - 10*не_знаю_сколько_но_гораздо_меньше_по_определению.

Т.е., если я зарежу исходящие ftp-данные на 10К, это НЕ значит, что я зарежу входящий ftp-поток на 10К, поскольку отправлять 64-байтовые ACK-ответы, это не тоже, что принимать 1500-байтовые пакеты.

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

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

Очень может быть, что я не прав, но ничего умнее я пока не придумал.

Если я все же еще не изложил мысль достаточно ясно, готов повториться :)

Может, пойдем в аську? :)

Мой ICQ #212063901, я сейчас в сети.

Везде речь идет о канале "Я <-> Провайдер".

>данные не будут поступать. они не будут отправлены. так работает стек.

Вот именно.

>произойдет. а как же иначе?

Нет, задержки на канале от меня до ISP не будет, а это главное.

>этим вы ничего не выигрываете. вы не можите контролировать каналы провайдера...

Да, но я не каналы прова собираюсь резать :) НЕ_ПРОИЗОЙДЕТ задержки на шейпере провайдера.

Видимо, мы говорим о немножко разных вещах :)

fagot тебе хлеба есть не давай дай лижбы про шейперы поспорить. Оставьте юзеров в покое пусть качают не надо жадничать.

Есть пару тем, о которых я люблю как читать, так и писать. Например, обсуждения WindowMaker.

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

>Оставьте юзеров в покое пусть качают не надо жадничать.

Мои юзеры, чего хочу, того и делаю.

> Т.е., если я зарежу исходящие ftp-данные на 10К, это НЕ значит,
> что я зарежу входящий ftp-поток на 10К, поскольку отправлять
> 64-байтовые ACK-ответы, это не тоже, что принимать 1500-байтовые
> пакеты

косвенно да. но это шейпинг не входящего потока, а исходящего.
вы также можете кочвенно регулировать этот самый ftp траффит,
приоритизируя ACK'и.

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

на *BSD не знаю ;)  а на OpenBSD как раз классы и используются,
только опять же непонятна это ``гармоничность''. хотите извращаться,
как и описали -- шейпите исходящий трафик. ведь из того, что вы
сказали не следует, что нужен шейпинг входящего траффика. это просто
более хитрое использование шэйпинга исходящего траффика...

> Нет, задержки на канале от меня до ISP не будет, а это главное.

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

>косвенно да. но это шейпинг не входящего потока, а исходящего.

Правильно. Я как раз и говорю, что шейпить только исходящий трафик не достаточно эффективно.

Но с помощью IMQ на Linux можно классифицировать и _входящий_ трафик. И это будет именно входящий и таким образом, в этом есть смысл :))

я вот кстати подумал еще не много....

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

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

но altq умеет очереди только на исходящий траффик
(фактически только на if_output), поэтому пока
лично мне задумываться об этом не с руки... а как
оно там работает в Linux -- вообще бог его знает...

>что входная приоритизация может работать по той же схеме

Я вот про это и говорю :) Так оно и работает (при желании) в Linux

>для входящего траффика смысла особого не имеет

не согласен, но доказывать, пожалуй, не буду, уже писал выше :))

Ребята всё это конечно хорошо, но вы отклонились от темы :) Каким образом (дополнительными скриптами или программами) это можно делать ? Если это умеет делать сам altq работающий вместе с pf или отдельным демоном то скажите он работает по принципу ingress(просто дропает) или imq (класификация)?

По поводу последней фразы: тоже не совсем в тему, но если быть точным, IMQ сам по себе ничего не классифицирует :)

> Если это умеет делать сам altq работающий вместе с pf или отдельным
> демоном то скажите он работает по принципу ingress(просто дропает)
> или imq (класификация)?

дядя, man pf.conf, раздел QUEUEING.
и сюда поглядите: http://www.openbsd.org/faq/pf/queueing.html