QoS
From Antcor
Contents |
Quality of Service
Quality of service (also know as Traffic Shaping) refers to the general concept of prioritizing network traffic, according to some of its properties. By default, each packet is treated equally and in a first-come, first-served basis.
However, by utilizing QoS, certain traffic patterns, can be given higher priority or can be guaranteed specific network resources. From now on, we will refer to a traffic pattern as class.
Some of the policies that can be enforced with QoS are:
- Restrict or eliminate the bandwidth consumed by P2P applications.
- Distribute the available bandwidth equally among a group of HOTSPOT users.
- Make sure that certain services (eg. the web portal of a hotspot) will always be accessible, no matter how overloaded the network is.
- Reserve a portion of the available bandwidth for latency-sensitive applications, like VoIP.
- Mitigate DoS attacks by restricting the network usage available for specific kinds of traffic (eg. ICMP traffic).
The QoS window tab
Let's have a look first, at the overall GUI interface. There are three main columns:
Traffic Classes
Traffic classes are entities to which we associate specific traffic patterns, and specific network resources. The traffic patterns constitute the Matches associated to a Traffic Class, and the network resources reserved, comprises the Target of the Traffic Class. These properties can be configured via the rightmost panel of the QoS window.
To add a new Traffic Class, you have to right-click on the “Traffic Classes” label in the respective Panel. You can define as many Traffic Classes as you wish. A Traffic Class can also form a tree-like hierarchy of Subclasses. The tree may have at most two layers of subclasses.
Traffic Policies
A Traffic policy is an object to which we associate one or more classes and one or more interfaces. The set of classes assigned to a Traffic Policy, defines the policy for the associated interfaces. The way you assign classes to policies is unlimited. Traffic policies can be shared by many interfaces, in which case the interfaces are unified from the QoS standpoint. Shared polices will be discussed in more depth later in this chapter.
Network Interfaces
This panel lists all physical interfaces of the system. For each interface, we distinguish two flows: An incoming one, which corresponds to traffic coming to the interface, from the underlying physical layer, and an outgoing one, which corresponds to traffic going out of the interface, to the physical layer.
Note: Bridges and virtual interfaces will not be present here. If you want to set a policy to a bridge, set the same traffic policy to every physical interface that makes up the bridge. Virtual interfaces can only be distinguished, in the basis of their ip address.
Bear in mind, that you can't assign more than one policy per interface flow; as well as, the same policy to both flows of the same interface.
Guarantees and Limitations
On the other hand, the network resources that can be guaranteed or limited are:
- Committed Information Rate
- Peak Information Rate
- Committed Burst Size
- Excess Burst Size
- Priority
These parameters constitute the TARGET part of a class.
Committed Information Rate (CIR)
This is the rate (expressed in kbits/s) which is guaranteed that will always be available to the respective traffic class. Apparently, the CIF dedicated for a specific class, can not exceed the network bandwidth available. When multiple competing classes exist for the same interface and for the same direction (output/input), the sum of all of them should also not overrun the available bandwidth.
Note that, regardless of the CIR the traffic is always transmitted at the maximum speed supported by the physical interface. Literally, the CIR expresses the average rate in which the traffic is sent, in due time.
Peak Information Rate (PIR)
This is the maximum rate (in kbits/s) in which, the traffic of a class, can be sent or received (in average). Even if no other traffic competes for the bandwidth, this barrier can not be exceeded. This value can be as large as the capacity of the link and as small as the CIR.
The bandwidth between CIR and PIR is not guaranteed for a class. The possibility for a class to exploit this range, depends on its priority as we will see later.
Excess Burst Size (EBS)
Some applications are characterized by short periods of intensive network usage and long periods with no network usage at all. For instance, when we browse the Internet, our web browser requests a web page and then remains idle for a long period of time, until another page is requested. Such applications are not served well by the CIR/PIR mechanism alone. The EBS mechanism remedies this problem by allowing an application to send a number of bytes continuously, for some time, without being interrupted. As soon as EBC bytes have been sent, the application is forced back to normal behavior (average rate ranging between CIR and PIR).
Committed Burst Size (CBS)
The CBS corresponds to the minimum number of bytes that have to be available in order for a transmission to start. By the time that the transmission starts, it is not possible to be interrupted, until there are no other data to send. By default this value is the smallest possible (a single packet size ideally) and scarcely will you have to set a different value.
In order to better understand the concept of rate and burst, consider the analogy: Each class (or subclass as we will see later) is like a bucket with size EBS. The bucket is filled up at a rate which ranges between CIR and PIR. In accordance with this analogy, transmission starts when we throw water out of the bucket. The minimum quantity of water (traffic) that we can be thrown out is CBS. Therefore, when a class is idle for a while, it's possible for an application later on, to send a large burst of data, until the “bucket” is empty. Similarly, for a class that sends traffic at a steady rate, lower than CIR, its “bucket” will always be filled up.
Priority
The Priority value dictates which class, among those at the same layer, will get the unused bandwidth. This bandwidth comes from those classes that are not fully utilizing their CIR. This extra bandwidth is delivered first to the class with the highest priority and as soon as the PIR (or EBS) of this class is reached, the distribution continues to the next class in order of priority. Priority value can vary between 0 (higher priority) and 7 (lower priority).
Consider the scenario: We have a standard 11mbps wireless link, and we want to guarantee half of it, to outgoing TCP traffic. Then we further divide it to TCP traffic destined for host x, and that destined to host y. This scenario is depicted in the following table.
Classes in the table denoted as “auto”, are classes that are automatically (and transparently) created by the system to handle unclassified traffic. These automatically generated classes, get the rest of the bandwidth (as its CIR), which is not reserved for any of the user-defined ones. System generated classes are always of priority 7.
Back in our scenario: Let's assume now that 7 mbps traffic (out of the 11 mbps) qualifies for the USER CLASS. This means that we have 7 mbps TCP traffic, which has to be distributed among the three subclasses. Let's also assume that 1/3 of this traffic is destined for host x and another 1/3 for host y. Although, it might be tempting to say that, its of the subclasses will get 1/3 of the 7 mbps, in actual, SUBCLASS 2 and AUTO SUBCLASS will get exactly 1,8 mbps (the CIR) and SUBCLASS 1 will get 3,4 mbps. This is because SUBCLASS 1 has a higher priority. If there is no traffic at all for SUBCLASS 1, then SUBCLASS 2 will get 5,2 out of the 7 mbps available. By now, the role of priority should be clear.
Design Guidelines and Limitations
Destination/Source MAC match type
To use the destination MAC match type, you have to create a bridge interface and assign to it the desired physical interface (a single interface is ok). Then, you can use the destination MAC match type of the interface assigned to the bridge. Also bear in mind that, on a regular ip network, all receiving packets on the gateway, have as destination mac the gateway's mac address. Similarly, all packets forwarded by the gateway, have as source mac the gateway's mac address. Hence, it's pointless to use these fields on an IkarusOS powered AP, which acts as a gateway.
When A sends a packet for B, the packet initially has destination mac: C.Eth0. Thereafter, when gateway C forwards it to its destination (host B) it has source mac: C.eth1.
Application match type
You may set the application match type only on leaf subclasses, on a class hierarchy. The reason behind this is that application type is very specific and should only exist on subclasses that reside on the last level (leaf) of a class hierarchy.
Moreover, when application type is used on a leaf class, it's not possible to set the protocol match type on any of its parent classes. This is because, when you set an application type match, you implicitly define the protocol type which corresponds to the that application type.
Child to Parent class relation
In a class hierarchy, a child's MATCH and TARGET part should be subset of that of each parent class. Therefore, you can't have a parent class to match a destination port range of 1-1024, when one of its child classes matches destination port range 500-2000. Port range 1025-2000 is not a subset of the parent class.
PIR on parallel classes
Currently, the QoS subsystem requires that all parallel classes (or subclasses) will either have a PIR defined or not. Therefore, it's not possible to set the PIR on a subclass and not set it on one of its sibling classes. All of them should either have or not have a PIR defined.
Efficiency considerations
Whenever possible, prefer the port or protocol match type instead of the application one. Application match type is slower and more CPU intensive.
