QoS or Quality of Service is a way to prioritise network traffic and to guarantee performance for users, groups and services. Because most networks have a limited amount of bandwidth, you need an effective strategy to ensure the network does not become overloaded. QoS enables you to make the best use of the available bandwidth at any given time.
Traffic can be prioritised in different ways. Certain traffic may be based on the type of information that is sent (for example, email or FTP) others based on the computer sending or receiving the information (such as a mail or web server), or based on the user sending the information. This is called traffic classification.
Once classified, traffic is placed in different queues. These queues have different properties, enabling more important traffic to pass through the network in a timely fashion.
In Sonar, when prioritising traffic you can ensure that certain user groups or applications with a higher priority will always have high connection speeds. A simple scenario would be making sure system administrators and staff will always have Internet Access at the highest possible connection speed. Another option is to reduce QoS for users that have exceeded their quota. Rather then stopping them from accessing the internet altogether, you can reduce their connection speeds (this is sometimes also referred to as traffic shaping)
You can also use QoS to guarantee sufficient network capacity for certain types of traffic. For example, by directing mail traffic to its own queue you can make sure that if someone sends out a bulk email to, say 5000 recipients this wont interfere with another user's voice over IP calls.
The process of setting up QoS in Sonar consists of the following steps:
- Creating QoS objects for the interfaces whose traffic you want to manage, and QoS classes for the queues in which you want to place traffic.
- Creating QoS rule objects which classify traffic.
- Creating the QoS policy by linking QoS rules to a group and associating it with source and destination network objects.
When setting up QoS, we recommend that you set the assured rate for the interface (the QoS device object) to be 90% of the maximum bandwidth available from the connection to the internet. For example if you wish to shape internet traffic that arrives at 1Mb/s on Eth0, then set the Eth1 interface assured rate to 900 Kb/s. This will ensure that Sonar remains the bottleneck and not your ISP.
Use ceiling rates to make best use of your bandwidth and enable sharing. We strongly advise against setting the ceiling of any class to than 100% of the assured rate if the QoS device object.
Dont mix delay-sensitive and bursty traffic. VOIP and video streaming is delay sensitive, whereas web browsing (HTTP) or email (SMTP) are far less sensitive to delayed or dropped packets. These differenet types of traffic should be placed in their own classes. Keep them separated, so that you can assign ceiling and assured rates appropriate for each type of traffic.
When setting the priority of a QoS class, give classes that handle delay-sensitive traffic higher priority to reduce latency and therefore delay.
CREATING QOS OBJECTS
- Select Sonar -> Network -> Objects -> QoS Classes and click Add Device. The Edit Device window is displayed.
- In the Max Ceiling field enter the highest connection speed you want to allow for this device.
- In the Max Assured field enter the minimum guaranteed connection speed for the device.
CREATING QOS CLASSES
Select Sonar -> Network -> Objects -> QoS Classes and select the device or parent class to which yo want to add the new class, and click Add Class. The Edit QoS window will be displayed.
- In the Class Label field, type a descriptive name for the class.
- Either use the sliders or directly enter a value in the Kbits/s (Kilobits per second) fields to set the ceiling and assured rates.
- Set the priority for this class. The lower the number, the higher the priority. You should give classes that handle time-sensitive traffic (real-time video, VOIP) higher priority than classes that are not time-sensitive (for example, bulk traffic generated by FTP and SMTP Transfers).
- If you want to specify a burst rate, select Advanced. The burst rate determines the number of packets that can be serviced in a burst interval (in this case, a second). Only set this value if you know what you are doing.
Once your QoS policies have been set up, in the Sonar -> Network -> Objects -> QoS Classes window you can quickly view which groups are linked to a class:
- Right-click the class and select View All Groups
Classes are basically queues with certain boundaries (ceiling and assured rates). The actual classification of traffic and placing it in the appropriate queue is handled by network and rule objects.
To explain how QoS rule objects work, we'll use an example that you may want to use on your own network: QoS policy for non-cached webpages and allowed access to cached webpages to bypass any bandwidth restrictions, because this traffic remains on the internal network. HTTP caching is enabled in Sonar by default, so that doesn't require any additional configuration on your part.
The filtering proxy can set the terms of service flag (TOS) priority flag to a certain value whenever the data is received from the cache, enabling the QoS engine to correctly classify web traffic as cached or not. This enables you to send traffic flagged as non-cached to a specific queue.
To enable cache QoS bypass, select Sonar -> Network -> Proxies -> HTTP -> Server and make sure that:
- the qos_hit_bypass is set to true
- the hit_tos is set to 10 which means that data retrieved from cache will be processed with minimum delay.
To do this, you must create a rule matching the destination port of the HTTP traffic (port 8080 by default; you can look up the server_port setting by selecting Sonar -> Network -> Proxies -> HTTP -> Server) and the TOS flag indicating that the data is not retrieved from the cache.
- Select the QoS option.
- In the Rule label field, type a descriptive name for the rule object such as Cache hit.
- Click the Target ellipsis button [...] and in the Maintain Target window that is displayed click Add and Ok.
- From the Match1 drop-down list select multiport.
- Click the Match1 ellipsis button [...] and in the Maintain Match1 window make sure that from the Available Choice drop-down list src-port is selected.
- Enter the number of the HTTP server port which is 8080 by default (you can look up the server_port setting by selecting Sonar Network Proxies HTTP Server) and click Add and Ok.
- From the Match2 drop-down list the tos.
- Click the Match2 ellipsis button [...] and in the Maintain Match2 window select the Not option.
- Then enter 0x10 in the Enter a value field and click Add and Ok.
The final step is to create the actual QoS policy by linking the appropriate network, rule and class objects to a group. To continue the previous example to apply QoS to non-cached traffic, we want to have a different QoS for non-cached data for staff and students (if you want the policy to apply to anyone, select the System group).
The source network object is the outgoing internal LAN object (typically Eth1) which responds to the URL request with either cached or non-cached data to the LAN (Destination object) from which the original request originated.
- Double-click Sonar -> Groups -> Staff and select Rules -> QoS and click Add.
- As the source, select Eth1 object, and as the destination select the LAN object(s).
- In the Rules section click the + button, then select the Cache Miss rule object and the Staff class object, then click Add and Close.
- Click OK. You have now set up the QoS policy for the non-cached traffic for the Staff user group.