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/02 14:48] – [Entry conditions:] 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 many spend their leisure time on the Internet: download and watch movies, 
-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%. 
-At the same time, 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. 
- 
-====Инструменты:==== 
-Опции СКАТ DPI, которые будем использовать:   
-  * [[dpi:dpi_options:opt_statistics:start|Сбор и анализ статистики по протоколам и направлениям]] 
-  * [[dpi:dpi_options:opt_shaping:start|Оптимизация использования внешних каналов доступа]] 
-Дополнительные Модули: 
-  * Для приема, обработки и хранения NetFlow [[dpi:dpi_components:qoestor|программный продукт для сбора статистики QoE Store]].\\ 
-  * Для визуализации и построения отчетов [[dpi:dpi_components:dpiui:start|графический интерфейс DPIUI2]].\\ 
- 
-====Настройка:==== 
-Разделим трафик на классы в зависимости от используемого протокола. Всего может быть назначено до 8 классов, которые СКАТ может использовать для маркировки пакетов как в поле DSCP/TOS IP-заголовков, так и поле приоритет VLAN/MPLS, и далее QOS может управлять внешняя платформа. Но мы рассмотрим случай, когда это делает сам СКАТ. 
-В класс самого низкого приоритета поместим сервисы, которые мы согласны ограничить в часы пик. Обычно это сервисы, скорость которых и так зависит от внешних факторов, пользователь работает с ними не в режиме интерактивности, обычно в фоне. Это закачка файлов через торрент трекеры, сервисы обновления ПО и возможно что-то еще, специфичное для вашего случая. В класс с более высоким приоритетом поместим сервисы online-трансляций, которые обычно имеют возможность адаптироваться к доступной полосе пропускания и выбирать качество, и в класс с самым высоким приоритетом поместим интерактивные сервисы, работу которых пользователь контролирует в онлайн режиме и проблемы с которыми станут сразу заметны: это web браузинг, online игры, IP-телефония (SIP, Skype), в общем для простоты поместим в этот класс все остальное.  
-Для каждого класса ограничим максимальную полосу пропускания, которую может занять трафик данного класса, или положимся на механизм заимствования полосы с автоматическим регулированием, заложенный в СКАТ. В последнем случае СКАТ начнет ограничивать трафик по классам только при приближении утилизации полосы входящего трафика к пороговому значению. Также ограничим полосу снизу, чтобы во время пиков трафик данного класса пострадал лишь в контролируемых пределах. 
- 
-При превышении верхнего ограничения полосы для класса исходящий трафик данного класса ограничивается СКАТ, при этом уменьшение полосы распределяется между абонентами равномерно. В силу двустороннего режима работы большинства протоколов (запрос-ответ, передача-подтверждение) ограничение исходящего трафика приводит к ограничению входящего. 
-В автоматическом режиме регулирования степень этого влияния определяется СКАТ через механизм обратной связи и сначала ограничению подвергается трафик минимального приоритета вплоть до достижения установленного минимального порога. Если такого ограничения не достаточно, то ограничение распространяется на трафик следующего приоритета и т.п. 
-Оба режима позволяют задействовать механизм заимствования, когда неиспользуемая полоса распределяется между классами в соответствии с текущими потребностями и подвергается перераспределению, когда ее начинает не хватать. 
- 
-==== Пример конфигурации для приведенного выше описания ==== 
-Создаем файл 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|“Кэширование”]].