Приоритет Torrent-трафика в домовой сети

[pinger]

Подскажите пожалуйста, как минимализировать приоритет torrent-трафика, или вернее, как сделать http-трафик максимально приоритетным. Наслышан про QoS, как реализовать?
ос - FreeBSD 8

[l30l3]

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

[pinger]

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

Что рядовому юзеру важнее, что бы вконтакт открывался быстро ежедневно, или раз в неделю по скайпу потрындеть?

[sopov]

Тут какбэ дело в том, что приоритет можно задать только исходящему трафику. Входящему задавать бесполезно - он уже приехал и занял какую-то полосу. Поэтому нужно понимать зачем вам вобще нужны приоритеты? Если тонковат общий канал - это одно. Если хочется сделать серфинг более комфортным, то совсем другое. Но в любом случае зарезать клиентам какие-то сервисы не стоит, т.к. уйдут они от вас. Для улучшения качества серфинга нужно использовать burst.

[Sergey Shumov]

Приоритет над строить на уровне свича доступа.

[NiTr0]

Входящему задавать бесполезно - он уже приехал и занял какую-то полосу.

Не совсем так. Congestion control ведь никто не отменял. И в следующий интервал времени "приедет" траффика меньше

[sopov]

Оно то так, но на свиче доступа может и тунель ppp ехать. Плюс толку от Congestion control в udp, а это utp_torrent, voip, игры - чуть более чем 0 - rst не пошлеш.

[NiTr0]

Плюс толку от Congestion control в udp, а это utp_torrent, voip, игры - чуть более чем 0 - rst не пошлеш.

Почему же, congestion control на uTP пытаются всем миром родить, и вроде как по теоретическим выкладкам при обнаружении засирания канала торрент должен снижать интенсивность отправки "аск"-пакетов и уменьшать размер пакета. Хотя раньше особое усердие в этом приводило к полному коллапсу канала, который на 100% засирался торрентом, и смерти всех SOHO роутеров. Как сейчас дела обстоят - не знаю, uTP задушено и пускать его назад не собираемся. Ибо нефиг.
А voip/игры - им как раз максимальный приоритет нужен, ибо у них congestion control - собссно сам юзер. Который при обнаружении факта возрастания пинга и дропа пакетов игру/скайп то закроет, но пойдет материться в саппорт.

[sopov]

Я у себя пробовал душить на брасах, но нагрузка на процы с задушеным utp больше чем с незадушеным. В итоге оставил. На freebsd выделили гранд на разработку congestion control, но пока нет особых подвижек. Будем ждать, может чего и родят. А пока, из реального и дешевого, кроме барста и нормального канала, способов повышения качества серфинга не вижу. Способы конечно есть, но они требуют либо больших финансовых затрат, либо больших вычислительных ресурсов. В итоге все сводится к тому, что все проблемы от экономии .

[NiTr0]

Я у себя пробовал душить на брасах, но нагрузка на процы с задушеным utp больше чем с незадушеным. В итоге оставил.

Не процом единым. Хомяки с говнороутерами от разгула uTP пищать начинают, скайп и прочие udp тоже какбы надо приоритетом повыше торрента пускать - чтобы в ЧНН при внезапном росте канала (а, к примеру, в дождливый летний день канал внезапно может вырасти на % 20-30 в ЧНН по сравнению с другими днями) юзеры не ощущали дискомфорта, и т.п.
От того - дешевле зарезать каку, чем разгребаться с последствиями ее жизнедеятельности.

[l30l3]

uTP задушено и пускать его назад не собираемся. Ибо нефиг.
А voip/игры - им как раз максимальный приоритет

скайп и прочие udp тоже какбы надо приоритетом повыше торрента пускать

µTP — переимплементация TCP на основе протокола UDP с измененным контролем за переполнением, который реагирует раньше, чем соответствующий алгоритм в TCP. http://ru.wikipedia.org/wiki/%CE%9CTorrent
Если коротко то µTP это UDP на Транспортном уровне.

Skype для передачи непосредственно голоса тоже использует UDP. Порты и там и там случайные.

Как вы задушили µTP не затронув скайп? Я давно хочу их разделить, но это и на Прикладном уровне проблематично. Да и неоправданно дорого, если даже реализовать.

[NiTr0]

Как вы задушили µTP не затронув скайп?

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

[lessless]

а какой ToS у него ?

ps. Linux

iptables -t mangle -A POSTROUTING -m layer7 --l7proto bittorrent \
-j CLASSIFY --set-class 2:3

tc qdisc add dev ppp0 parent root handle 1: htb
tc class add dev ppp0 parent 1:0 classid 1:1 htb rate 1mbit
tc qdisc add dev ppp0 parent 1:1 handle 2: prio

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