QoS Scenario

From Antcor

1 Qos Scenarios

Qos Scenarios

Example: Bandwidth reservation for FTP Servers

Let's have a look now at one example, in order to better comprehend the QoS mechanism. Let's say that we have an IkarusOS powered Hotspot, equipped with an standard 11mbps wireless interface. The real available bandwidth on such an interface is approximately 5.5mbps or 5500kbps. On the ethernet side, there are two ftp servers and a bunch of other insignificant hosts. The ftp servers are meant to serve the hotspot clients. Hence, we would like to guarantee some bandwidth for them.

Single Class per Policy

We will start by defining a QoS policy to guarantee 3 mbps for FTP traffic. Since we want to guarantee both uploads and downloads from the ftp servers, we will create two different classes, one for each flow direction. On each of them, we will set a PIR limit (3.5 mbps), in order to prevent the FTP server from monopolizing the bandwidth.

Steps to follow:

We click on “Traffic Classes” and right-click on it.
We add a new class, named let's say “ftp_traffic_out”, to handle outgoing traffic from interface ath0.
We click on “ftp_traffic_out” class and configure the MATCHES and TARGET.

Similarly, we set up an 'ftp_traffic_in' class for the incoming flow direction.

Now we will create two policies, one for each flow direction, named 'ftp_in' and 'ftp_out'. We accomplish this by right-clicking on 'Traffic Policies' label.
Then we associate each class to each respective policy (Picture 85). This is done by dragging-dropping classes to policies and policies to interface flows.

Parallel Classes

Up to now, we guarantee 3mbps for FTP traffic coming from any of the directly connected subnets, and destined to the other one. However, we make no provisions for users (of either subnet), who might set up an FTP server on their own initiative. Such ftp servers can consume part of the 3mbps quota, which is reserved for the two original FTP server. If we want to prevent this, we will have to be more specific when defining our classes. In particular:

We rename 'ftp_traffic_out' to 'ftp_traffic_out_ftp1' to handle traffic destined for FTP server 192.168.1.220. We change the destination address to 192.168.1.220/32. We leave the ftp application type to FTP.
Similarly, we rename 'ftp_traffic_in' to 'ftp_traffic_in_ftp1' to handle traffic originating for FTP server 192.168.1.220. Therefore, we change the source address to 192.168.1.220/32. The ftp application type of TARGET remains as it is.
In a similar manner, we create two new classes, named 'ftp_traffic_out_ftp2' and 'ftp_traffic_in_ftp2' to handle traffic originated from/destined to 192.168.1.190/32. We also set the TARGET application type to FTP.
Since we dived the total CIR/PIR of the initial classes (one for each direction) in two classes, we have also to redefine the CIR/PIR on each subclass to 1500/1750. This way, for each direction the policy guarantees an aggregated CIR of 3000 and an aggregated PIR of 3500.

Classes 'ftp_traffic_in_ftp1' and 'ftp_traffic_in_ftp2' are considered Parallel Classes, as far as the incoming interface flow of ath0 is concerned. This is because they don't form a hierarchy and hence, for every arriving packet, both of them are evaluated against against it. Classes 'ftp_traffic_out_ftp1' and 'ftp_traffic_out_ftp2' are also parallel classes, as far as the outgoing interface flow of ath0 is concerned.

Parallel classes, although very convenient feature, should be used with caution. By all means, you should avoid setting parallel classes that overlap each other. In other words, it should be clear which class will be activated for every arriving packet. For instance, the two classes depicted at picture above are overlapping, cause is ambiguous which one will handle traffic originating within subnet 172.8.1.0/24 and destined to host 192.168.1.1/32 with destination port number 200.

Class Hierarchy

Although the aggregated ftp traffic falls within limits (3000/3500), the maximum allowed bandwidth for each FTP server is restricted to 1750 kbps. An intuitive workaround would be to set the PIR of each class to 3500. However, in that case, if there is a lot of ftp traffic for both FTP servers, then the aggregated ftp traffic might exceed the desired restriction: 3500 (since 3500+3500=7000). In order to alleviate this problem, we will have to create a class hierarchy.

We set the CIR/PIR of every class created up to now to 1499/3500 and we remove the application type of FTP.
We create two new classes, named 'ftp_traffic_in' and 'ftp_traffic_out'. We set the CIR/PIR on each of them to 3000/3500. Source IP/Sub of 'ftp_traffic_in' should be set to 192.168.1.0/24 and destination IP/Sub of 'ftp_traffic_out' to 192.168.1.0/24. This is to allow for other ftp sessions to take place. Next, on the MATCHES part, we set the port range to 20 – 21 (ftp-data, ftp-control), and the protocol type to FTP.

We drag&drop the previous classes to these new ones to create a class hierarchy as depicted at picture 88. We also alter the structure of our policies, so that only the newly created classes are assigned to them.

This way we limit the PIR at parent classes (3000/3500) and then we further distribute the bandwidth among the child classes (1499/3500 each). So, we enforce an upper limit on the amount of bandwidth used for FTP traffic, and at the same time, we enable both FTP Server to use the full potential of the reserved bandwidth.

Example: Elimination of P2P Traffic

Currently, IkarusOS does not support filtering of ip traffic based on its Layer 7 properties. For example, you can't set up a firewall rule to block incoming/outgoing P2P traffic. Nonetheless, you can virtual eliminate it, by restricting the bandwidth available to it.

In this example we will set up two Traffic Policies, one for each direction, and two Traffic Classes, that will reduce the bandwidth available to P2P traffic to as low as Kbits/sec. P2P users will soon get frustrated and drop their P2P applications altogether. The following pictures demonstrate the QoS configuration needed.

Shared Policies

In our example, traffic policies p2p_in and p2p_out are shared between interfaces eth0 and ath0. That makes them (both interfaces) to be regarded as a single interface, from the standpoint of QoS. In practice, this means that 1 Kbits/sec can be occupied by P2P traffic coming from either eth0 or ath0, and an other 1 Kbits/sec for P2P traffic leaving from either eth0 or ath0 (not 1 Kbits/sec each).

Example: Access Point Bandwidth Sharing

New QoS Entry

IkarusOS INMS has a convenient way to set bandwidth policies for individual clients of an Access Point. This feature works only for clients that have a statically assgned IP and not via DHCP. If you want to set bandwidth policies for individual AP Clients which get their IP via DHCP, you'll have to set up your classes manually based on client's MAC address.

You define a bandwidth policy for an AP client by clicking on the “New Client” button.