Quality of Service: Difference between revisions

From Bondix Wiki
(First draft, describe how to set up QoS on tlt)
 
(General overhaul to reflect latest changes)
Line 1: Line 1:
Quality of Service allows you to differentiate between different types of traffic, and apply different rules to them that affect how they are transported through the bonding tunnel.
Quality of Service allows you to apply different bonding rules for different types of traffic. Traffic can be differentiated via packet type, source and/or destination IP. Bonding rules allow you to set priority or duplication to limiting bandwidth or optimizing for latency.
[[File:QoS Editor.png|thumb|The QoS editor with a default rule.]]


'''This feature is currently in development, information presented here is subject to change.'''
===Presets===
Bondix S.A.NE comes with a selection of QoS presets, which can be used for quick configuration. At a glance:
{| class="wikitable"
|+
! Preset
!Description
|-
|Bonding
|This is the default preset - bonding over any interface with BondingProxy enabled.
|-
|Bonding (No Proxy)
|Bonding with BondingProxy disabled.
|-
|Bonding (QoS)
|A more sophisticated preset including a priority rule for DNS traffic, VoIP and online meetings.
|-
|Packet Duplication
|Default Bonding with packet duplication (1x) enabled.
|-
|Seamless Failover
|Only use one interface as indicated by channel priority or latency.
|-
| Satellite
|A preset for satellite scenarios. Satellite is only used for HTTP(S) traffic, except when no other interfaces are available.
|}
A QoS preset consists of one or more traffic groups (QoS group). When a client connects to a server, it sends along its desired QoS configuration, which the server can either use or replace with a different configuration. The server also comes with a QoS preset editor which allows you to create custom presets that can be applied on multiple tunnels.


=== Configuration on Teltonika ===
===Traffic Group===
Currently it is only possible to configure QoS on Teltonika devices.
A traffic group (QoS group) consists of a ruleset of how traffic should be handled, and a list of matching traffic types to which these rules shoule be applied to.


Navigate to Network > Bondix Bonding > Quality of Service. Currently, you will have to create all classes yourself, we will introduce presets soon.
====Group Settings====
 
==== Traffic Classes ====
First, create traffic classes. These are rules that specify how traffic should be treated. At a glance:
[[File:QoSClasses.png|center|frame]]
{| class="wikitable"
{| class="wikitable"
|+
|+
!
!Property
!
!Description
|-
|-
|Max Channel
| style="width: 150px" |Name
|maximum amount of channels that should be used, 0 = unlimited
|A short descriptive name that ideally describes the type of traffic you want to assign to this group.
|-
|Score
| The group's score determines how often it gets the chance to send out data. The minimum value is 1, each additional score point gives the group a bigger slice of available data. Groups with higher score are also get to write their data first.
|-
|-
|Duplication
|Packet Copies
|specifies how many copies of the packet should be sent out.
|How many copies of each packet should be made. A value of 0 means no duplication, a value of 1 means that single duplication, and so on. Packet Copies are opportunistic, if not enough interfaces are available to send the amount of configured copies, less copies will be made.
|-
|-
|Bonding Latency
|Latency Offset
|sets the latency threshold when selecting channels. The latency of the lowest channel PLUS this value is the upper limit for all other channels.  
|When channels are selected, latency offset describes the maximum difference the interface with the lowest and highest latency may have. This allows you to exclude slow or unreliable lines should their latency become too high. A value of 0 means no limitation.
|-
|-
|Distribute
| Max Down (MBit)
|Whether packets should be distributed evenly accross all channels. If you use packet duplication, this might have only little effect.  
|The maximum bandwidth allowed downstream in MBit. Downstream always references traffic sent from the server to the client. A value of 0 means no limitation.
|-
|-
|Max Bandwidth
|Max Up (MBit)
|A limit in MBit for all traffic in that group.
|The maximum bandwidth allowed upstream in MBit. Upstream always references traffic sent from the client to the server. A value of 0 means no limitation.
|-
|-
|Bonding Proxy
|Max Channel
|Whether traffic should use Bonding Proxy. When disabled and there is matching TCP traffic, it will still end up in the proxy, but in a default QoS class. The goal is to not send matching traffic into the proxy, but this is currently not implemented.
|The maximum number of channels that should be used at once for this group. A value of 0 means no limit.  
|-
|-
|Channel Selection
| Channel Selection
|Specifies how suitable channels are picked for the class. This only has an effect when distribute is disabled, or when only a subset of channels are to be used.  
|How channels should be selected. Possible Options:


* Default: The default mechanism, using a combination of latency and packetloss.
* Default - The default method which considers configured priority, latency and reliability.
* Latency: Prioritize latency
* Latency - Only consider latency (lowest first)
* Bandwidth: Prioritize Bandwidth
* Bandwidth - Only consider available bandwidth (highest first)
* Priority - Only consider priority.
|-
|Bonding Proxy
|If enabled, matching TCP traffic will be bonded using BondingProxy, which optimizes bonding throughput and efficiency.
|-
|-
|Score
| Always Distribute
|Will be renamed to priority. Classes with higher priority can write packets first, and also <score> amount of packets at once. In theory, setting this high enough should allow for a high priority class to starve any other value. However, see remarks down below.
|If enabled, traffic is always spread through all interfaces. This is disabled by default as it usually introduces unnecessary jitter, but may be beneficial if you look to spread traffic evenly across multiple interfaces.
|}
|}
'''Important: Currently, you must reload the page after saving changes made in the Traffic Classes list, otherwise editing QoS rules will likely fail'''. This is a known bug that we are working on.


==== QoS Rules ====
==== Matching Rules ====
After having created a set of traffic classes, you can create sorting rules, which specify what type of traffic should be assigned to which traffic classes.
Matching rules describe the type of traffic you want to assign to a group.
[[File:QoSSorting.png|center|frame]]
{| class="wikitable"
{| class="wikitable"
|+
|+
!
!Property
!
!Description
|-
|-
|Protocol
|Traffic Type
|Which protocol to match to. Currently available options are Any, TCP, UDP, TCP+UDP, ICMP, Other,
|Possible options:
 
* Any - ignore traffic type
* TCP
* UDP
* TCP & UDP
* ICMP
* Other - everything else that is not on this list
|-
|-
|Source
|Source
|What source IP's to match on. Value must be entered in CIDR notation. To be able to match to source IPs, masquerading must be disabled on the client, and an appropiate route must be configured on the tunnel.
|The source IP network in CIDR notation. In order to match properly, make sure to disable masquerading on the client. A value of "0.0.0.0/0" means traffic from any source.
|-
|-
|Source Ports
|Source Port
|What source port(s) to use. You can either specify a single port (e.g. 12345) or a range of ports (e.g. 12340-12350). A value of "0" means any port.
|The source port. This can either be a single value (e.g. "80") or a range (e.g. "22-23"). A value of 0 means any port.  
|-
|-
|Destination
|Destination
|What destination IPs to match on. Again, value must be entered in CIDR notation.
|The destination IP network in CIDR notation. For individual IPs, make sure to include the network prefix /32. A value of "0.0.0.0/0" means traffic to any destination.
|-
|-
|Dest Ports
|Destination Port
|What destination ports to use. Accepts single port or port range, or "0" for any port.
|The destination port. This can either be a single value (e.g. "80") or a range (e.g. "22-23"). A value of 0 means any port.
|-
|Traffic Class
|What traffic class to use. If a traffic class does not appear here, you must refresh the page in your browser, known bug.
|}
|}
Traffic rules are sorted by specificity. If multiple rules would match to certain traffic, the rule that is the most specific will be applied.
Traffic matching rules are sorted by specificity. That means that the most specific rules are checked on first, the broadest rule is checked last.  
 
Traffic that does not match any traffic will be matched to an internal default QoS class, that uses the default bonding settings. We do not intend to make these settings accessible. Instead, you should create a broad rule that matches to all traffic (Any Protocol, 0.0.0.0/0:0 for both source & destination). targetting a traffic class of your choice.


=== Compatibility ===
===Configuration on Teltonika===
Client and server are generally backwards compatible. When a legacy client connects to a QoS endpoint, the client can still apply its original Tunnel Preset. When a QoS client connects to a legacy client, it will apply the default "Bonding" tunnel preset, it's still possible on the legacy server to override these presets.
[[File:Teltonika Preset Selection.png|right]]
If you want to use custom QoS settings on Teltonika, make sure that the preset is set to "Custom QoS" - otherwise the currently selected preset is used instead. Keep in mind that the server can always override any client QoS settings.


Quality of Service will replace the generic "Tunnel Preset" setting. While this setting is currently still available in beta builds, it will eventually disappear.
===Compatibility===
Client and server are generally backwards compatible. When a legacy client connects to a QoS enabled endpoint, the client can still apply its original tunnel preset (which is what QoS replaces). When a QoS enabled client connects to a legacy server, it will always use the default "Bonding" tunnel preset, or the preset propagated by the legacy server.

Revision as of 22:50, 20 September 2023

Quality of Service allows you to apply different bonding rules for different types of traffic. Traffic can be differentiated via packet type, source and/or destination IP. Bonding rules allow you to set priority or duplication to limiting bandwidth or optimizing for latency.

The QoS editor with a default rule.

Presets

Bondix S.A.NE comes with a selection of QoS presets, which can be used for quick configuration. At a glance:

Preset Description
Bonding This is the default preset - bonding over any interface with BondingProxy enabled.
Bonding (No Proxy) Bonding with BondingProxy disabled.
Bonding (QoS) A more sophisticated preset including a priority rule for DNS traffic, VoIP and online meetings.
Packet Duplication Default Bonding with packet duplication (1x) enabled.
Seamless Failover Only use one interface as indicated by channel priority or latency.
Satellite A preset for satellite scenarios. Satellite is only used for HTTP(S) traffic, except when no other interfaces are available.

A QoS preset consists of one or more traffic groups (QoS group). When a client connects to a server, it sends along its desired QoS configuration, which the server can either use or replace with a different configuration. The server also comes with a QoS preset editor which allows you to create custom presets that can be applied on multiple tunnels.

Traffic Group

A traffic group (QoS group) consists of a ruleset of how traffic should be handled, and a list of matching traffic types to which these rules shoule be applied to.

Group Settings

Property Description
Name A short descriptive name that ideally describes the type of traffic you want to assign to this group.
Score The group's score determines how often it gets the chance to send out data. The minimum value is 1, each additional score point gives the group a bigger slice of available data. Groups with higher score are also get to write their data first.
Packet Copies How many copies of each packet should be made. A value of 0 means no duplication, a value of 1 means that single duplication, and so on. Packet Copies are opportunistic, if not enough interfaces are available to send the amount of configured copies, less copies will be made.
Latency Offset When channels are selected, latency offset describes the maximum difference the interface with the lowest and highest latency may have. This allows you to exclude slow or unreliable lines should their latency become too high. A value of 0 means no limitation.
Max Down (MBit) The maximum bandwidth allowed downstream in MBit. Downstream always references traffic sent from the server to the client. A value of 0 means no limitation.
Max Up (MBit) The maximum bandwidth allowed upstream in MBit. Upstream always references traffic sent from the client to the server. A value of 0 means no limitation.
Max Channel The maximum number of channels that should be used at once for this group. A value of 0 means no limit.
Channel Selection How channels should be selected. Possible Options:
  • Default - The default method which considers configured priority, latency and reliability.
  • Latency - Only consider latency (lowest first)
  • Bandwidth - Only consider available bandwidth (highest first)
  • Priority - Only consider priority.
Bonding Proxy If enabled, matching TCP traffic will be bonded using BondingProxy, which optimizes bonding throughput and efficiency.
Always Distribute If enabled, traffic is always spread through all interfaces. This is disabled by default as it usually introduces unnecessary jitter, but may be beneficial if you look to spread traffic evenly across multiple interfaces.

Matching Rules

Matching rules describe the type of traffic you want to assign to a group.

Property Description
Traffic Type Possible options:
  • Any - ignore traffic type
  • TCP
  • UDP
  • TCP & UDP
  • ICMP
  • Other - everything else that is not on this list
Source The source IP network in CIDR notation. In order to match properly, make sure to disable masquerading on the client. A value of "0.0.0.0/0" means traffic from any source.
Source Port The source port. This can either be a single value (e.g. "80") or a range (e.g. "22-23"). A value of 0 means any port.
Destination The destination IP network in CIDR notation. For individual IPs, make sure to include the network prefix /32. A value of "0.0.0.0/0" means traffic to any destination.
Destination Port The destination port. This can either be a single value (e.g. "80") or a range (e.g. "22-23"). A value of 0 means any port.

Traffic matching rules are sorted by specificity. That means that the most specific rules are checked on first, the broadest rule is checked last.

Configuration on Teltonika

Teltonika Preset Selection.png

If you want to use custom QoS settings on Teltonika, make sure that the preset is set to "Custom QoS" - otherwise the currently selected preset is used instead. Keep in mind that the server can always override any client QoS settings.

Compatibility

Client and server are generally backwards compatible. When a legacy client connects to a QoS enabled endpoint, the client can still apply its original tunnel preset (which is what QoS replaces). When a QoS enabled client connects to a legacy server, it will always use the default "Bonding" tunnel preset, or the preset propagated by the legacy server.

Retrieved from "https://wiki.bondix.dev/index.php?title=Quality_of_Service&oldid=583"