The option is configured or disabled by parameters in configuration file /etc/dpi/fastdpi.conf.
The bandwidth limits are set up by each of 8 protocol classes (groups) available.
When using TBF (Token Bucket Function), a specific rate is set for each class of traffic:
#For the inbound traffic tbf_inbound_class0=rate 15mbit tbf_inbound_class1=rate 15mbit tbf_inbound_class2=rate 15mbit tbf_inbound_class3=rate 15mbit tbf_inbound_class4=rate 15mbit tbf_inbound_class5=rate 15mbit tbf_inbound_class6=rate 15mbit tbf_inbound_class7=rate 15mbit #For the outbound traffic tbf_class0=rate 15mbit tbf_class1=rate 15mbit tbf_class2=rate 15mbit tbf_class3=rate 15mbit tbf_class4=rate 15mbit tbf_class5=rate 15mbit tbf_class6=rate 15mbit tbf_class7=rate 15mbit
One can optionally indicate parameters peakrate, burst, cburst. The bandwidth is not limited for a class with no explicit restrictions.
When HTB (Hierarchical Token Bucket) is used, the overall and borrowed class rates are specified:
#For the inbound traffic htb_inbound_root=rate 900mbit htb_inbound_class0=rate 300mbit ceil 900mbit htb_inbound_class1=rate 100mbit ceil 200mbit htb_inbound_class2=rate 100mbit ceil 200mbit htb_inbound_class3=rate 100mbit ceil 200mbit htb_inbound_class4=rate 100mbit ceil 100mbit htb_inbound_class5=rate 100mbit ceil 100mbit htb_inbound_class6=rate 50mbit ceil 100mbit htb_inbound_class7=rate 50mbit ceil 100mbit #For the outbound traffic htb_root=rate 900mbit htb_class0=rate 300mbit ceil 900mbit htb_class1=rate 100mbit ceil 200mbit htb_class2=rate 100mbit ceil 200mbit htb_class3=rate 100mbit ceil 200mbit htb_class4=rate 100mbit ceil 100mbit htb_class5=rate 100mbit ceil 100mbit htb_class6=rate 50mbit ceil 100mbit htb_class7=rate 50mbit ceil 100mbit
Here:
htb_root - is a root class that specifies the total bandwidth. The bandwidth redistribution is arranged within this class. The usage can grow up till this limit, if no ceil is specified
rate - minimal bandwidth
ceil - maximal bandwidth that can be borrowed from the root class if available
One can optionally specify parameters burst, cburst. The sum of parameters rate of all classes must not exceed the overall bandwidth limit. Otherwise the behaviour is undefined.
Bandwidth allocation for some classes (for example, peering) can be deduced from the HTB if you specify the keyword "static: for them in the description, in this case the restriction for this class will work like tbf without binding to htb_root
htb_inbound_class6 = rate 200mbit static htb_class6 = rate 200mbit static
The advanced users can activate the feedback loop method. It works as follows:
The inbound traffic limit is set up in the configuration. The ceil parameter is specified for class htb_root:
htb_inbound_root=rate 800mbit ceil 950mbit htb_root=rate 450mbit ceil 600mbit
On exceeding of the specified rate=800mbit by the inbound traffic, the upper limit ceil for the outbound traffic starts to decrease. The latest limit is specified by the parameter htb_root ceil=600mbit. However, even when the inbound traffic exceeds ceil=950mbit, the outbound traffic would not be restricted stronger than specified by htb_root rate=450mbit. The percentage of excess traffic is counted by the range ceil 950mbit ↔ rate 800mbit. The outbound traffic is reduced by the same percentage. On the reduction of сeil value specified in htb_root, other classes redistribute the traffic to keep the total limit set up in htb_root.
This method is effective for protocols operating by query - reply scheme. Limitations of the outbound traffic (query) lead to decrease in the inbound one (reply). Most of application protocols belong to this class.
If the limit is not specified for some class, it can take all the bandwidth available.
The correspondence between dscp priority and poliсing class depends on the setting class_order