Bandwidth Management

Policing in Cubro Service Gateway is applied to channel and subscriber profiles, as well as to application protocol sessions at L2-L7 levels. Per-session policing is managed separately through the connection of a service with type 18 (Service Type 18) for the selected channel or subscriber.

Cubro Service Gateway allows the definition of 8 policing classes. Users can mark network traffic by application protocols L2-L7, distributing the protocols among the available 8 classes. Each protocol is assigned a DSCP name that corresponds to the policing class and priority.

You can use all the DSCP labels specified in the table, but for simplicity, the labels cs0 – cs7 will be used here and thereafter. The DSCP value can be set in numerical (decimal, hexadecimal, or octal) format or using a textual abbreviation. The textual abbreviations cs0 – cs7 will be used here and thereafter.

For the default channel, protocol priorities are loaded from the file:

/etc/dpi/protocols.dscp

For user-defined channel and subscriber profiles, protocol priorities are loaded from any path specified in the service profile settings for service type 18.

Each line of the /etc/dpi/protocols.dscp file or a file specified in the service type 18 profile must contain a definition in the following format:

application_protocol <tab> dscp_keyword

Example:

dns		cs0
skype		drop
whatsapp	cs0
whatsapp_voice	cs1
ftp		keep
http		cs0
bittorrent	cs7
default		keep

The complete list of protocols is available in the Web CNC and in the interactive window for creating a policing profile. For more details, see the relevant part of part B.

Keywords:

• drop — discard packets for the specified protocol.
• keep — do not change the priority value, usually cs0 (0).
• default — means "for all other protocols," which significantly simplifies and shortens the process of creating a configuration file.

Once the protocol marking is completed, the policing profile must be configured directly.

Cubro Service Gateway allows for traffic marking based on both L2-L7 protocols and direction. The direction is determined by the number of the autonomous system (AS) of the traffic source or receiver.

1. If a priority is set for an autonomous system by direction, it overrides the priority set by protocol.
2. If a priority is set for the traffic source, it overrides the priority set for the receiver.

Priorities assigned by the system administrator based on direction are loaded by DPI from the file

/etc/dpi/asnum.dscp

The file preparation is carried out in two stages: first, a test file containing a list of autonomous systems and their assigned priorities is created, which is then converted to the internal format using a special utility. Each line of the file contains an entry in the format as_number <space> dscp_value, for example:

64512		cs0
64512		local
64512		term
64513		drop
64514		pass
64514		peer

where

• cs0 — is the DSCP value
• drop — discard traffic for this direction (drop without further analysis)
• pass — traffic from this AS is passed through DPI transit without analysis and processing
• local — traffic from this AS is considered local traffic of the operator; Only for the BRAS function
• peer — the operator is peering with this AS; Applies only to caching services
• term — termination is allowed for this AS; Only for the BRAS function
• mark1 — Priority of identifying a user protocol by TLS characteristics before IP. Read more in the section "User Protocols."
• mark2 — QUIC traffic without SNI from this AS will be marked as the protocol QUIC_UNKNOWN_MARKED. This is necessary for DPI to interrupt the Zero Handshake QUIC session if it lacks SNI.

Conversion to the internal format and placement in the Cubro Service Gateway configuration directory /etc/dpi/ where the settings will be loaded by DPI: CLI:

cat my_as_dscp.txt | as2dscp /etc/dpi/asnum.dscp
service fastdpi reload

Policing profiles in Cubro Service Gateway can be specified using either the Token Bucket Function (TBF) or the Hierarchical Token Bucket (HTB) disciplines when applying a service to a channel or subscriber.

EXTERNAL LINKS:
Token Bucket Function
Hierarchical Token Bucket

When using TBF (Token Bucket Function), bandwidth limitation is applied to each of the 8 classes. If no limit is defined for a class, its bandwidth is not restricted.

#Ingress
tbf_inbound_class0=rate 15mbit
tbf_inbound_class1=rate 5mbit
tbf_inbound_class2=rate 5mbit
tbf_inbound_class3=rate 5mbit
tbf_inbound_class4=rate 5mbit
tbf_inbound_class5=rate 5mbit
tbf_inbound_class6=rate 5mbit
tbf_inbound_class7=rate 8bit
#Egress
tbf_class0=rate 15mbit
tbf_class1=rate 5mbit
tbf_class2=rate 5mbit
tbf_class3=rate 5mbit
tbf_class4=rate 5mbit
tbf_class5=rate 5mbit
tbf_class6=rate 5mbit
tbf_class7=rate 8bit

Optionally, the parameters peakrate, burst, and cburst are supported; by default, these parameters are calculated automatically. In the previous chapter, the protocols were marked as follows:

dns		cs0
skype		drop
whatsapp	cs0
whatsapp_voice	cs1
ftp		keep
http		cs0
bittorrent	cs7
default		keep

Thus, for protocols classified under cs0 (class0), the bandwidth limit is set to 15 Mbit/s for both incoming and outgoing traffic. For protocols in classes cs1-cs6, the limit of 5 Mbit/s is set for each class. Bittorrent, placed in class cs7 with a rate of 8 bit, will be blocked. Note that the keyword drop instructs the system to discard all packets of the specified protocol. When the drop policy is applied, the traffic is discarded and not analyzed by the classifier engine. As a result, information about discarded sessions is not saved in the IPFIX/NetFlow export and does not appear in statistical reports and reports generated by QoE.

Using a limit of 8 bit achieves a blocking effect, but all statistical information and metadata are still sent to the IPFIX/NetFlow export and reflected in reports and the analytical database.

When using HTB, a total speed is set for the entire restricted bandwidth (root), as well as speeds for classes with guaranteed bandwidth (rate) and borrowing (ceil).

#Ingress
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
#Egress
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

htb_root and htb_inbound_root — root classes that define the limitation on the total size of the bandwidth, which cannot be exceeded. The rates define the guaranteed speed for each class, and the sum of all rates must be less than or equal to htb_root for outgoing and htb_inbound_root for incoming traffic.

ceil — defines the maximum bandwidth size that can be borrowed from the root class if bandwidth is free. The ceil value for EACH class can be less than or equal to htb_root for outgoing and htb_inbound_root. In total, all ceil values can exceed the restrictions of the root class.

HTB allows for more efficient bandwidth utilization and management of service quality, as available bandwidth is dynamically redistributed among classes with borrowing, but if the bandwidth is fully utilized, the restrictions described in rate apply.

Bandwidth allocation for certain classes (e.g., peering) can be removed from the HTB hierarchy by specifying the keyword static in the class description; in this case, the restriction for this class will function similarly to TBF without relation to htb_root.

htb_inbound_class6=rate 200mbit  static
htb_class6=rate 200mbit static

When using HTB, a feedback mechanism can also be enabled, which works as follows:

In the policer settings, a limit on incoming traffic is set, and for the htb_root class, a ceil parameter is defined:

htb_inbound_root=rate 800mbit ceil 950mbit
htb_root=rate 450mbit ceil 600mbit

When the incoming traffic exceeds the specified rate=800mbit, the upper limit of ceil set in the parameter htb_root=600mbit begins to decrease for outgoing traffic. However, even when the incoming traffic exceeds the value of ceil=950mbit, outgoing traffic will not be limited to more than what is specified in the htb_root rate=450mbit. The percentage of excess is calculated over the interval ceil 950mbit ↔ rate 800mbit, and outgoing traffic is reduced by the same percentage. When limiting the ceil value specified in the htb_root parameter, other classes begin to redistribute traffic to avoid exceeding the overall limit established in htb_root.

This mechanism works effectively for protocols based on request-response, where limiting outgoing traffic (request) reduces incoming traffic (response), which applies to most application protocols.

Hereinafter, the terms "channel profile" and "channel," as well as "subscriber profile" and "subscriber," are equivalent and interchangeable concepts.

The policing service in the Cubro Service Gateway can be applied to:

1. The general channel
2. A virtual channel
3. A subscriber

A detailed description of objects 1-3 is provided in section "3. Embedded Objects in Cubro Service Gateway."

The session policing service (Service type 18) is disabled by default on Cubro Service Gateway nodes. This service requires additional memory, which is reserved in the main configuration file of the Cubro Service Gateway in /etc/dpi/fastdpi.conf.

Activating the service:

support_service_18=1

For session policing, a configuration file describing the session policing profile must be prepared using a special utility:
CLI:

cat tbf_prof_1.txt|lst2tbf /tmp/tbf_prof_1.tbf

File content: tbf_prof_1.txt

speedtest tbf rate 16mbit inbound.rate 16mbit
bittorrent tbf rate 8Mbit
TCP Unknown tbf rate 8Mbit burst 1Mbit inbound.rate 8Mbit inbound.burst 1Mbit

To override traffic classes (the correspondence of the application protocol to the DSCP class) defined by default or for the general channel individually for the channel or subscriber, service 18 (Service type 18) is also used.

The procedure for preparing the marking is identical to that described in the section: "Traffic Marking by Application Protocols".

The procedure for creating the file dscp_prof_1.dscp:
CLI:

cat dscp_prof_1.txt|lst2dscp /tmp/dscp_prof_1.dscp

File content: dscp_prof_1.txt

speedtest cs1
default keep

Creating a service profile
CLI:

fdpi_ctrl load profile --service 18  --profile.name test_dscp --profile.json '{ "dscp" : "/tmp/dscp_prof_1.dscp", "tbf" : "/tmp/tbf_prof_1.tbf" }'

Connecting the service:
For a subscriber:
CLI:

fdpi_ctrl load --service 18  --profile.name test_dscp --ip 10.10.10.10
fdpi_ctrl load --service 18  --profile.name test_dscp --login DEMO

For a virtual channel (vChannel):
CLI:

fdpi_ctrl load --service 18  --profile.name test_dscp

Output of service profile information:
CLI:

fdpi_ctrl list all --service 18  
fdpi_ctrl list --service 18 --ip 192.168.0.1  
fdpi_ctrl list --service 18 --login DEMO  
fdpi_ctrl list --service 18 --vchannel 1

Get a list of all profiles for service 18
CLI:

fdpi_ctrl list all profile --service 18