How the VAS Experts DPI can help you to reduce uplink costs by 25% while increasing QoE?

If you look at a weekly channel usage graph of a typical home telecommunication operator, you can see that the peek value usually is reached on the most busy hours (MBH), when everyone is resting after working hours and spend their leisure time on the Internet: download and watch movies, listen to music, visit entertainment portals, etc.

There is a strong temptation to avoid paying for the “extra” bandwidth, which is needed only for an hour and the rest of the time is merely not used. But if you just don’t pay, then your users will notice problems at a rush hour such as: glitches may occur when watching videos, websites may become unavailable, online games may become running slow and IP calls can not be held. The operator will never accept this strategy because, it is essentially prime time and users need high-quality Internet at exactly this time. How about this situation here? Operator wants to save money, and at the same time it is required to deliver high-quality Internet to the end user, and to make him pleased with services provided.

The VAS Experts DPI options to use:

• Gathering and analysis of statistics on protocols and directions
• Optimizing the use of external access channels

Additional Modules:

• For receiving, processing and storing NetFlow - QoE Store statistics software.
  
• For visualization and generating reports - DPIUI2 graphical interface.
  

Let's divide the traffic into classes depending on the protocol used. There are can be assigned in total up to 8 classes, which the VAS Experts DPI can use to label the packets both in the DSCP/TOS field of IP headers and the VLAN/MPLS priority field, and then the external platform can control QOS. But we will consider the case when the VAS Experts DPI does it on its own. We place in the lowest priority class all the services that we can afford to be limited during peak hours. Usually these are services having the speed depending on external factors, it's the case when the user doesn't use the service in interactive mode but instead in the background one. The examples of such a services are: downloading files via torrent trackers, software update services and maybe something else specific to your case. Online broadcasting services being able to adapt to the available bandwidth and select the quality needed should be placed in a class with a higher priority, and, finally, in the highest priority class we should place interactive services, which operation is controlled by the user in online mode, so when the problems ocсur, they will become immediately perceptible; these are web browsing, online games, IP-telephony (SIP, Skype). And to put it simple, we will place everything else in this class. Для каждого класса ограничим максимальную полосу пропускания, которую может занять трафик данного класса, или положимся на механизм заимствования полосы с автоматическим регулированием, заложенный в СКАТ. В последнем случае СКАТ начнет ограничивать трафик по классам только при приближении утилизации полосы входящего трафика к пороговому значению. Также ограничим полосу снизу, чтобы во время пиков трафик данного класса пострадал лишь в контролируемых пределах.

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

Создаем файл 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

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

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