[Прохожий]

и в пустыню особо оптику не потягаешь.

Это в болотах, горах и лесах не особо потягаешь, а в степях и пустынях - одно удовольствие :)

 

Дам общие соображения.

 

1. Любые манипуляции с трафиком целесообразны только на точке входа пакета в сеть. То есть для даунстрима - как можно ближе к аплинку, для апстрима - как можно ближе к порту абонента.

 

2. Главное - грамотно раскрасить, а не правильно обрезать. Если правильно раскрашено, то потом может быть корректно дропнуто. Обрезание - мера тупая и грубая, хотя и необходимая местами.

 

3. Важно то, что видно юзверю, а не технические параметры ;)

[nuclearcat]

По пунктам :-)

1. В любом случае шейпер эффективен когда он ДО узкого места. Т.е. эффективный шейпер должен быть ДО магистрала :-) Но это выходит нерентабельно

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

3. Само собой, customer satisfaction. С другой стороны надо повышать ARPU, и по возможности заманивать многоуровневым сервисом на более высокие тарифы.

[Sonne]

У нас Netflow в центральной точке используется ля управление полисером ISG. Время срабатывания от нескольких секунд на UDP торрентах, до 20 минут на TCP сессии FTP.

 

Наша система работает по цепочке Netflow-Коллектор-(мозг системы)-радиус сервер-ISG-CoA

 

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

 

Вместо ISG можно использовать микротики, значительно дешевле получится и можно вынести на удаленные POPы.

 

Рекомендую работоспособную архиектуру - Центральный сенсор (netflow или что еще) - анализатор - радиус - coa

 

Есть большое неудобство - для авторизации радиус требуется IP пакет от пользователя, соединение не является постоянным, по таймату или времени жизни отваливается и может быть восстановлено только по пакету от потребителя.

[x86]

Добавлю свои 5 копеек к мнениям уважаемых людей.

1. С upload проблема решаема - ибо если трафик от клиента раскрашен( а правильной сети он ДОЛЖЕН быть раскрашен ), то на бордере достаточно простенького QoS по классу трафика + поддержка sfq. Если наступает полка, и данной схемы все-таки оказывается недостаточно, тогда конечно имеет смысл анализировать upload на бордере и динамически менять upload от клиентов.

2. С download все намного печальнее :(

UDP - нормальных способов контроля нет. Используем ненормальные - т.е. специальный демон выявляет злоупотребляющих UDP и выдает NAS'am команду давить их. В результате нагрузка по pps упала на 30% и я не знаю, что такое uTP :). Но это чистая эмпирика и основная сложность состоит в том, чтобы правильно отделять зерна от плевел.

TCP - нужен запас по полосе( да, это потерянные деньги, но в случае перегрузки он дает свой положительный эффект ), RED и конечно динамическое ограничение потребления клиентов. Все это прочувствовано на собственном опыте, ибо был период, когда мы не могли быстро расширить канал и пришлось жить в условиях полки( когда расширили - оказалось она доходила до 50% ). Основной удар на себя принял демон тротлинга, который при наступлении перегрузки бордера по входу( а вот здесь и пригодился запас по полосе - хоть немного, но смягчал ) давал NAS'am команды на динамическое изменение скорости к клиентам. Более того, поскольку весь трафик у нас раскрашен, также динамически и намного более жестко уменьшалась полоса для закачек НА КЛИЕНТА для "злоупотребляющих" клиентов. Жалобы были только на youtube, да и то потому, что этот трафик раньше классифицировался как закачки.

speedtest же показывал кошерные цифры и странички грузились нормально.

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

[Прохожий]

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

[x86]

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

Совершенно согласен.

НО, неоднократно наблюдал картину, когда уменьшение скорости к клиенту НИКАК не отражалось на скорости поступающего UDP потока.

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

[x86]

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

Т.е. достаточно легко узнать, если бы прошейпили юзеров на BRAS суммарно на мегабит, а прилетело полтора, но надо уменьшить цифры. Но я думаю если алгоритмически сделать подстройку, и учитывать что кто-то упирается в потолок, а кто-то недобирает полосу, и лимиты выставлять с "вилкой" - то цифры будут соответствовать требуемым. Главная засада как сделать не на глазок, а алгоритмически правильно.

 

Кстати опять же можно усовершенствовать схему. Скажем если мы режем юзера на положенный ему мегабит, он может засандалить торренты так, что на него все равно будет лететь скажем 1.3Мбита. Соответственно контроллер пересчитает лимит, и (упрощаю, надо изучать вопрос подробнее) зарежет его на 76.9%, т.е. 769Kbit, и с его превышением ему теоретически прилетит мегабит, это если превышение линейно процентное. Опять же даже если нет, систему можно сделать обучаемой, или применить в подсчете закладываемого "запаса" что-то типа Байеса. Тут моих текущих знаний пока не хватает, буду изучать.

 

И еще пара замечаний.

То, что клиенту пришло 1.3 мбит вместо положеных 1 мбит - неважно, если канала хватает.

А если наступает полка, то IMHO, наиболее важно не допустить того, чтобы аплинк дропал наши пакеты - ибо это НЕКОНТРОЛЛИРУЕМЫЙ дроп.

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

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

Также имеет смысл выявлять и зарезать качков, но только в ЧНН.

[nuclearcat]

Когда цена канала пренебрежительно мала, и его апгрейд легко делается - да, можно просто купить в два раза больше канал и не париться.

Но частенько дела обстоят не так.

[make.kernel]

Стесняюсь спросить, но тут смотрели?

 

http://caia.swin.edu.au/urp/diffuse/

 

Project Goals

 

Design packet filter extensions that allow ML-based classification and the de-coupling of flow classification and treatment.

Design a protocol to transport information about flow classes and actions from classifiers to nodes enforcing actions.

Develop extensions for existing packet filters that implement the developed approach and can be used as demonstrator.

Evaluate the accuracy, performance and scalability of a distributed classification system and characterise the various trade-offs.

Investigate methods for dynamic (re)training of classifiers and investigate the impact of noise on the performance of these methods.

Или это совсем не то?

[nuclearcat]

Посмотрел, любопытно, но слишком сложно для моих задач.

 

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

И клиенты довольны, игрунам нет потерь и latency, и качальщики не особо страдают.