Оптимизируем использование Uplink канала [Документация VAS Experts]

Оптимизируем использование Uplink канала

Как СКАТ поможет уменьшить затраты на аплинк на 25% и при этом повысить QoE?

Начальные условия:

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

Пик утилизации канала происходит около 23 часов и обычно длится меньше часа, превышая обычные показатели на 30%. При этом торрент-трафик в это время может занимать до 30% канала, еще около 50% - просмотр online видео, на все остальное приходится лишь 20%.

Что хотим получить:

Отложить расширение канала путем оптимизации полосы под разные типы трафика.

Велик соблазн не платить за “лишнюю” полосу, которая нужна всего лишь в течении часа и остальное время все равно не используется. Но если просто не заплатить, то в час пик пользователи заметят проблемы : начнутся лаги при просмотре видео, перестанут открываться сайты, будут тормозить онлайн игры и не проходить IP-звонки. На это оператор не пойдет: ведь это, можно сказать, прайм тайм и пользователям нужен качественный интернет именно в это время. Как же быть? Хочется и сэкономить, и в то же время чтобы пользователь ничего не почувствовал, да еще и спасибо сказал.

Инструменты:

Опции СКАТ DPI, которые будем использовать:

Дополнительные Модули:

Настройка:

Разделим трафик на классы в зависимости от используемого протокола. Всего может быть назначено до 8 классов, которые СКАТ может использовать для маркировки пакетов как в поле DSCP/TOS IP-заголовков, так и поле приоритет VLAN/MPLS, и далее QOS может управлять внешняя платформа. Но мы рассмотрим случай, когда это делает сам СКАТ. В класс самого низкого приоритета поместим сервисы, которые мы согласны ограничить в часы пик. Обычно это сервисы, скорость которых и так зависит от внешних факторов, пользователь работает с ними не в режиме интерактивности, обычно в фоне. Это закачка файлов через торрент трекеры, сервисы обновления ПО и возможно что-то еще, специфичное для вашего случая. В класс с более высоким приоритетом поместим сервисы online-трансляций, которые обычно имеют возможность адаптироваться к доступной полосе пропускания и выбирать качество, и в класс с самым высоким приоритетом поместим интерактивные сервисы, работу которых пользователь контролирует в онлайн режиме и проблемы с которыми станут сразу заметны: это web браузинг, online игры, IP-телефония (SIP, Skype), в общем для простоты поместим в этот класс все остальное. Для каждого класса ограничим максимальную полосу пропускания, которую может занять трафик данного класса, или положимся на механизм заимствования полосы с автоматическим регулированием, заложенный в СКАТ. В последнем случае СКАТ начнет ограничивать трафик по классам только при приближении утилизации полосы входящего трафика к пороговому значению. Также ограничим полосу снизу, чтобы во время пиков трафик данного класса пострадал лишь в контролируемых пределах.

При превышении верхнего ограничения полосы для класса исходящий трафик данного класса ограничивается СКАТ, при этом уменьшение полосы распределяется между абонентами равномерно. В силу двустороннего режима работы большинства протоколов (запрос-ответ, передача-подтверждение) ограничение исходящего трафика приводит к ограничению входящего. В автоматическом режиме регулирования степень этого влияния определяется СКАТ через механизм обратной связи и сначала ограничению подвергается трафик минимального приоритета вплоть до достижения установленного минимального порога. Если такого ограничения не достаточно, то ограничение распространяется на трафик следующего приоритета и т.п. Оба режима позволяют задействовать механизм заимствования, когда неиспользуемая полоса распределяется между классами в соответствии с текущими потребностями и подвергается перераспределению, когда ее начинает не хватать.

Пример конфигурации для приведенного выше описания

Создаем файл protocols.txt:

default cs0
mpeg    cs1
bittorrent cs7

Конвертируем protocols.txt в protocols.dscp

cat protocols.txt|lst2dscp /etc/dpi/protocols.dscp

Добавляем жесткие ограничения по классам в файл конфигурации /etc/dpi/fastdpi.conf, ориентируясь на график со статистикой (простое решение, но далеко не оптимальное)

#Limit outbound torrent
tbf_class7=rate 50mbit
#Limit inbound torrent
tbf_inbound_class7=rate 50mbit

Или позволим DPI выполнять приоритезацию протоколов по иерархии классов самостоятельно в пределах всей доступной полосы (требует подбора параметров верхних границ для учета всплесков трафика, чтобы ограничение происходило по приоритетам dpi, а не полкой, связанной с физическими возможностями канала, за отправную точку возьмем ширину канала минус 10%, для торрентов - минус 50%)

htb_inbound_root=rate 180mbit
htb_inbound_class0=rate 100mbit ceil 180mbit
htb_inbound_class1=rate 50mbit ceil 180mbit
htb_inbound_class2=rate 8bit ceil 180mbit
htb_inbound_class3=rate 8bit ceil 180mbit
htb_inbound_class4=rate 8bit ceil 180mbit
htb_inbound_class5=rate 8bit ceil 180mbit
htb_inbound_class6=rate 8bit ceil 180mbit
htb_inbound_class7=rate 10mbit ceil 100mbit
htb_root=rate 180mbit
htb_class0=rate 100mbit ceil 180mbit
htb_class1=rate 50mbit ceil 180mbit
htb_class2=rate 8bit ceil 180mbit
htb_class3=rate 8bit ceil 180mbit
htb_class4=rate 8bit ceil 180mbit
htb_class5=rate 8bit ceil 180mbit
htb_class6=rate 8bit ceil 180mbit
htb_class7=rate 10mbit ceil 100mbit

Рестартуем DPI

service fastdpi restart

Результат:

Теперь во время пиков пострадает только трафик, менее критичный и заметный для пользователей, а работа важных для пользователя онлайн сервисов, проблемы в которых сразу видны, будет осуществляться, благодаря приоритезации, быстрее и с минимальными задержками. Нам удалось снизить требования к ширине канала, а работа с интернет, с точки зрения пользователей, стала шустрее. Бонус: Во время пиков трафика большая нагрузка ложится и на другое используемое оператором оборудование и оно может начать под нагрузкой вносить свои дополнительные проблемы – терять пакеты, увеличивать время отклика и т.п. Внедрение шейпинга СКАТ позволит предотвратить превышение критической нагрузки для оборудования, после которой возникают проблемы, и отложить необходимость его апгрейда на более поздний срок.

Хотите сэкономить на канале еще больше, тогда смотрите описание опции “Кэширование”.