en:dpi:dpi_bestpractice:opt_uplink [Документация VAS Experts]

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
en:dpi:dpi_bestpractice:opt_uplink [2020/04/06 08:54] kvazikraven:dpi:dpi_bestpractice:opt_uplink [2023/08/28 14:51] (current) – removed elena.krasnobryzh
Line 1: Line 1:
-====== 1 Optimizing uplink channel ====== 
-{{indexmenu_n>1}} 
-How the VAS Experts DPI can help you to reduce uplink costs by 25% while increasing QoE? 
- 
-====Entry conditions:==== 
-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. 
- 
-<note important>The peak of the channel usage occurs about 23 hours and usually lasts less than an hour, exceeding normal rates by 30%. 
-And meanwhile, the torrent traffic at this time can occupy up to 30% of the channel capacity, about 50% accounts for viewing online video, everything else accounts for only 20%.</note>   
- 
-====What we want to get:==== 
-<note important>To suspend the increasing of channel bandwidth by optimizing usage of available bandwidth by different types of traffic.</note> 
-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. 
- 
-====Tools:==== 
-The VAS Experts DPI options to use:  
-  * [[en:dpi:dpi_options:opt_statistics:start|Gathering and analysis of statistics on protocols and directions]] 
-  * [[en:dpi:dpi_options:opt_shaping:start|Optimizing the use of external access channels]] 
-Additional Modules: 
-  * For receiving, processing and storing NetFlow - [[en:dpi:dpi_components:qoestor|QoE Store statistics software]].\\ 
-  * For visualization and generating reports - [[en:dpi:dpi_components:dpiui:start|DPIUI2 graphical interface]].\\ 
- 
-====Configuration:==== 
-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: 
-<code> 
-default cs0 
-mpeg    cs1 
-bittorrent cs7 
-</code> 
- 
-Конвертируем protocols.txt в protocols.dscp 
-<code> 
-cat protocols.txt|lst2dscp /etc/dpi/protocols.dscp 
-</code> 
- 
-Добавляем жесткие ограничения по классам в файл конфигурации /etc/dpi/fastdpi.conf, 
-ориентируясь на график со статистикой (простое решение, но далеко не оптимальное) 
-<code> 
-#Limit outbound torrent 
-tbf_class7=rate 50mbit 
-#Limit inbound torrent 
-tbf_inbound_class7=rate 50mbit 
-</code> 
- 
-Или позволим DPI выполнять приоритезацию протоколов по иерархии классов  
-самостоятельно в пределах всей доступной полосы (требует подбора параметров  
-верхних границ для учета всплесков трафика, чтобы ограничение происходило по приоритетам dpi,  
-а не полкой, связанной с физическими возможностями канала, за отправную точку возьмем ширину канала минус 10%, 
-для торрентов - минус 50%) 
-<code> 
-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 
-</code> 
- 
-Рестартуем DPI 
-<code> 
-service fastdpi restart 
-</code> 
- 
-====Результат:==== 
- 
-Теперь во время пиков пострадает только трафик, менее критичный и заметный для пользователей, а работа важных для пользователя онлайн сервисов, проблемы в которых сразу видны, будет осуществляться, благодаря приоритезации, быстрее и с минимальными задержками. Нам удалось снизить требования к ширине канала, а работа с интернет, с точки зрения пользователей, стала шустрее. 
-Бонус: 
-Во время пиков трафика большая нагрузка ложится и на другое используемое оператором оборудование и оно может начать под нагрузкой вносить свои дополнительные проблемы – терять пакеты, увеличивать время отклика и т.п. Внедрение шейпинга СКАТ позволит предотвратить превышение критической нагрузки для оборудования, после которой возникают проблемы, и отложить необходимость его апгрейда на более поздний срок.  
- 
-Хотите сэкономить на канале еще больше, тогда смотрите описание опции [[dpi:dpi_options:opt_cache:start|“Кэширование”]].