Configuring Hybrid Networking, QoS, and Path Selection : Configuring QoS
  
Configuring QoS
This section describes how to configure QoS. It contains these topics:
•  Overview
•  Migrating from RiOS 8.6.x and Earlier to RiOS 9.x
•  Creating QoS Profiles
•  Enabling MX-TCP Queue Policies
•  Modifying QoS Profiles
•  How a SteelHead Identifies and Shapes Inbound Traffic
Overview
QoS configuration identifies business applications and classifies traffic according to priorities. The SteelHead uses this information to control the amount of WAN resources that each application can use. QoS ensures that your important applications are prioritized and removes the guesswork from protecting performance of key applications. In addition, QoS can prevent recreational applications from interfering with business applications.
We strongly recommend that you configure QoS on and push QoS policies from a SteelCentral Controller for SteelHead to the SteelHead appliances, particularly with large scale deployments. For details, see the SteelCentral Controller for SteelHead Deployment Guide.
QoS comes with a predefined set of classes, a list of over 1000 global applications, and a default profile. By default, all in-path interfaces are enabled for inbound and outbound QoS with the same link rate.
To view the predefined global application list, see List of Recognized Applications.
Before configuring QoS, we recommend that you define any custom applications for use in QoS profiles. For details, see Defining Applications.
Migrating from RiOS 8.6.x and Earlier to RiOS 9.x
See the SteelHead Installation and Configuration Guide for details on the migration process.
To enable QoS
1. Choose Networking > Network Services: Quality of Service to display the Quality of Service page.
Figure: Quality of Service Page
2. Under Enable QoS, complete the configuration as described in this table.
Control
Description
Enable Outbound QoS Shaping
Enables QoS classification to control the prioritization of different types of network traffic and to ensure that the SteelHead gives certain network traffic (for example, Voice Over IP) higher priority than other network traffic. Traffic is not classified until at least one WAN interface is enabled. The system enables inbound and outbound QoS on all in-path interfaces by default.
To disable outbound QoS, clear this check box.
Enable Inbound QoS Shaping
Enables QoS classification to allocate bandwidth and prioritize traffic flowing into the LAN network behind the SteelHead. Inbound QoS provides the benefits of QoS for environments that can’t meet their QoS requirements with outbound QoS.
For details, see Inbound QoS.
To disable inbound QoS, clear this check box.
Enable QoS Marking
Identify traffic using marking values. You can mark traffic using header parameters such as VLAN, DSCP, and protocols. You can also use Layer-7 protocol information through Application Flow Engine (AFE) inspection to apply DSCP marking values to traffic flows.
The DSCP or IP TOS marking only has local significance. You can set the DSCP or IP TOS values on the server-side SteelHead to values different to those set on the client-side SteelHead.
Manage QoS Per Interface
Click the right arrow next to the WAN interface name and then select Outbound or Inbound QoS.
The system enables inbound and outbound QoS on all in-path interfaces by default (except the primary interface).
Inbound QoS supports in-path interfaces only; it doesn’t support primary or auxiliary interfaces.
3. Click Apply to apply your settings.
4. Click Save to Disk to save your settings permanently.
Creating QoS Profiles
QoS profiles contain a set of QoS classes and rules. You can select a profile to reuse the set of QoS classes and rules for multiple sites. For details about sites, see Defining a Site.
QoS profiles in RiOS 9.0 and later replace QoS service policies in previous versions.
You can create a tree structure using classes within a profile that contains leaf classes. Use a hierarchical tree structure to:
•  segregate traffic based on flow source or destination and apply different shaping rules and priorities to each leaf-class.
•  effectively manage and support remote sites with different bandwidth characteristics.
The SteelHead Management Console supports the configurations of three levels of hierarchy. If you need more levels of hierarchy, you can configure them using the CLI.
A profile can be used for inbound and outbound QoS.
Note: For details about QoS, see the SteelHead Deployment Guide.
To view a profile
1. Choose Networking > Network Services: Quality of Service to display the Quality of Service page.
2. Under QoS Profiles, click Edit next to the profile name.
Figure: Quality of Service Page
The profile name, rules, and classes appear. The classes model the network requirements for applications that exhibit similar characteristics and have similar requirements: minimum bandwidth, maximum bandwidth, and latency priority. For example, the Realtime class contains voice and video traffic.
A QoS profile contains one or more classes. Classes within a profile are typically organized in a hierarchical tree structure.
To edit a profile, class or rule, see To modify a QoS profile name, class, or rule.
To add a profile
1. Choose Networking > Network Services: Quality of Service to display the Quality of Service page.
2. Under QoS Profiles, click + Add a QoS Profile.
3. Specify a profile name.
4. Optionally, select a template or an existing profile on which to base the new profile. The system copies the existing configuration into the new profile. You can then fine-tune the parameters to create a new profile.
5. Click Save.
To add a class to a profile
1. Click Edit next to the profile name.
Figure: QoS Page
2. Under QoS Classes, click Edit.
3. Click + add class.
Figure: Add a QoS Class to a Profile
4. Complete the configuration as described in this table.
Control
Description
Class Name
Specify a name for the QoS class.
Minimum Bandwidth
Specify the minimum amount of bandwidth (as a percentage) to guarantee to a traffic class when there’s bandwidth contention. All of the classes combined can’t exceed 100 percent. During contention for bandwidth, the class is guaranteed the amount of bandwidth specified. The class receives more bandwidth if there’s unused bandwidth remaining.
Excess bandwidth is allocated based on the relative ratios of minimum bandwidth. The total minimum guaranteed bandwidth of all QoS classes must be less than or equal to 100 percent of the parent class.
A default class is automatically created with minimum bandwidth of 10 percent. Traffic that doesn’t match any of the rules is put into the default class. We recommend that you change the minimum bandwidth of the default class to the appropriate value.
You can adjust the value as low as 0 percent.
The system rounds decimal numbers to 5 points.
Maximum Bandwidth
Specify the maximum allowed bandwidth (as a percentage) a class receives as a percentage of the parent class minimum bandwidth. The limit’s applied even if there’s excess bandwidth available.
The system rounds decimal numbers to 5 points.
Outbound Queue
Optionally, select one of these queue methods for the leaf class from the drop-down list (the queue doesn’t apply to the inner class):
•  SFQ - Shared Fair Queueing (SFQ) is the default queue for all classes. Determines SteelHead behavior when the number of packets in a QoS class outbound queue exceeds the configured queue length. When SFQ is used, packets are dropped from within the queue in a round-robin fashion, among the present traffic flows. SFQ ensures that each flow within the QoS class receives a fair share of output bandwidth relative to each other, preventing bursty flows from starving other flows within the QoS class.
•  FIFO - Transmits all flows in the order that they’re received (first in, first out). Bursty sources can cause long delays in delivering time-sensitive application traffic and potentially to network control and signaling messages.
•  MX-TCP - Has very different use cases than the other queue parameters. MX-TCP also has secondary effects that you must understand before configuring:
–  When optimized traffic is mapped into a QoS class with the MX-TCP queueing parameter, the TCP congestion-control mechanism for that traffic is altered on the SteelHead. The normal TCP behavior of reducing the outbound sending rate when detecting congestion or packet loss is disabled, and the outbound rate is made to match the guaranteed bandwidth configured on the QoS class.
–  You can use MX-TCP to achieve high-throughput rates even when the physical medium carrying the traffic has high-loss rates. For example,
MX-TCP is commonly used for ensuring high throughput on satellite connections where a lower-layer-loss recovery technique is not in use.
RiOS 8.5 and later introduce rate pacing for satellite deployments, which combines MX-TCP with a congestion-control method.
–  Another use of MX-TCP is to achieve high throughput over high-bandwidth, high-latency links, especially when intermediate routers don’t have properly tuned interface buffers. Improperly tuned router buffers cause TCP to perceive congestion in the network, resulting in unnecessarily dropped packets, even when the network can support high-throughput rates.
MX-TCP is incompatible with AFE identification. A traffic flow can’t be classified as MX-TCP and then subsequently classified in a different queue. This reclassification can occur if there’s a more exact match of the traffic using AFE identification. You must ensure the following when you enable MX-TCP:
•   The QoS rule for MX-TCP is at the top of QoS rules list.
•   The rule doesn’t use AFE identification.
•   You only use MX-TCP for optimized traffic. MX-TCP doesn’t work for unoptimized traffic.
 
Use caution when specifying MX-TCP. The outbound rate for the optimized traffic in the configured QoS class immediately increases to the specified bandwidth, but it doesn’t decrease in the presence of network congestion. The SteelHead always tries to transmit traffic at the specified rate. If no QoS mechanism (either parent classes on the SteelHead, or another QoS mechanism in the WAN or WAN infrastructure) is in use to protect other traffic, that other traffic might be impacted by MX-TCP not backing off to fairly share bandwidth.
•  There is a maximum bandwidth setting for MX-TCP that allows traffic in the MX class to burst to the maximum level if the bandwidth is available.
Outbound DSCP
Selects the default DSCP mark for the class. QoS rules can then specify Inherit from Class for outbound DSCP to use the class default.
Select Preserve or a DSCP value from the drop-down list. This value is required when you enable QoS marking. The default setting is Preserve, which specifies that the DSCP level or IP ToS value found on pass-through and optimized traffic is unchanged when it passes through the SteelHead.
The DSCP marking values fall into these classes:
•  Expedited forwarding (EF) class - In this class, packets are forwarded regardless of link share of other traffic. The class is suitable for preferential services requiring low delay, low packet loss, low jitter, and high bandwidth.
•  Assured forwarding (AF) class - This class is divided into four subclasses, each containing three drop priorities for more granular classification. The QoS level of the AF class is lower than that of the EF class.
•  Class selector (CS) class - This class is derived from the IP ToS field.
Priority
Select a latency priority from 1 through 6, where 1 is the highest and 6 is the lowest.
Add Class
Adds the QoS class.
x
Click to remove the class. To remove a parent class, delete all rules for the corresponding child classes first. When a parent class has rules or children, the x for the parent class is unavailable.
5. Click Save to Disk to save your settings permanently.
Note: The QoS classes appear in the profile. To display QoS rules associated with the class, select the QoS profile.
To add a child class to a parent class
1. Select the profile name and click Edit.
Figure: QoS Page
2. Under QoS Classes, click Edit.
3. To the right of the parent class, click + add class.
4. Complete the child class definition. You can add up to three children classes belonging to one parent class.
5. Click Save to Disk to save your settings permanently.
Enabling MX-TCP Queue Policies
When you define a QoS class, you can enable an MX-TCP queue policy, which prioritizes TCP/IP traffic to provide more throughput for high loss links or links that have large bandwidth and high latency LFNs. Some use case examples are:
•  Data-Intensive Applications - Many large, data-intensive applications running across the WAN can negatively impact performance due to latency, packet loss, and jitter. MX-TCP enables you to maximize your TCP throughput for data intensive applications.
•  High Loss Links - TCP doesn’t work well on misconfigured links (for example, an under-sized bottleneck queue) or links with even a small amount of loss, which leads to link under-utilization. If you have dedicated point-to-point links and want those links to function at predefined rates, configure the SteelHead to prioritize TCP traffic.
•  Privately Owned Links - If your network includes privately owned links dedicated to rate-based TCP, configure the SteelHead to prioritize TCP traffic.
After enabling the MX-TCP queue to forward TCP traffic regardless of congestion or packet loss, you can assign QoS rules that incorporate this policy only to links where TCP is of exclusive importance.
These exceptions to QoS classes apply to MX-TCP queues:
•  In RiOS 7.x and later, the Link Share Weight parameter doesn’t apply to MX-TCP queues. When you select the MX-TCP queue, the Link Share Weight parameter doesn’t appear. In RiOS 8.x and later, there’s a maximum bandwidth setting for MX-TCP that allows traffic to burst to the maximum level if the bandwidth is available.
•  MX-TCP queues apply only to optimized traffic (that is, no pass-through traffic).
•  MX-TCP queues can’t be configured to contain more bandwidth than the license limit.
When enabling MX-TCP, ensure that the QoS rule is at the top of QoS rules list.
Basic Steps for MX-TCP
This table describes the basic steps to configure MX-TCP. Enabling this feature is optional.
Task
Reference
1. Select each WAN interface and define the bandwidth link rate for each interface.
2. Add an MX-TCP class for the traffic flow. Make sure you specify MX-TCP as your queue.
3. Define QoS rules to point to the MX-TCP class.
4. Select the Enable Inbound or Outbound QoS Shaping check box and click Save. Your changes take effect immediately.
5. Optionally, to test a single connection, change the WAN socket buffer size (to at least the BDP). You must set this parameter on both the client-side and the server-side SteelHead.
6. Check and locate the inner connection.
 
7. Check the throughput.
 
Adding a QoS Rule to a Profile
Each rule maps a type of network traffic to a QoS profile. You can create multiple QoS rules for a profile. When multiple QoS rules are created for a profile, the rules are followed in the order in which they’re shown in the QoS Profile page and only the first matching rule is applied to the profile. SteelHeads support up to 2000 rules and up to 200 sites. When a port label is used to add a QoS rule, the range of ports can’t be more than 2000 ports.
To add a rule
1. Choose Networking > Network Services: Quality of Service to display the Quality of Service page.
2. Click Edit next to the profile name.
3. Under QoS Rules, click + Add a Rule.
Figure: Add a Rule to a QoS Profile
4. Complete the configuration as described in this table.
Control
Description
Application or Application Group
Specify the application or application group. We recommend using application groups for the easiest profile configuration and maintenance.
QoS Class
The QoS class indicates how delay-sensitive a traffic class is to the QoS scheduler. Select a service class for the application from the drop-down list (highest priority to lowest):
•  Inherit from Default Rule - Uses whichever class is currently set for the default rule. By default, this is Low Priority.
•  Real-Time - Specifies real-time traffic class. Give this value to your highest priority traffic: for example, VoIP, or video conferencing.
•  Interactive - Specifies an interactive traffic class: for example, Citrix, RDP, telnet, and SSH.
•  Business Critical - Specifies the high priority traffic class: for example, Thick Client Applications, ERPs, and CRMs.
•  Normal Priority - Specifies a normal priority traffic class: for example, Internet browsing, file sharing, and email.
•  Low Priority - Specifies a low priority traffic class: for example, FTP, backup, replication, other high-throughput data transfers, and recreational applications such as audio file sharing.
•  Best Effort - Specifies the lowest priority.
These are minimum service class guarantees; if better service is available, it’s provided. For example, if a class is specified as low priority and the higher priority classes aren’t active, then the low priority class receives the highest possible available priority for the current traffic conditions. This parameter controls the priority of the class relative to the other classes.
Note: The service class describes only the delay sensitivity of a class, not how much bandwidth it’s allocated, nor how important the traffic is compared to other classes. Typically you configure low priority for high-throughput, non-packet delay sensitive applications like FTP, backup, and replication.
Outbound DSCP
Select Inherit from Class, Preserve, or a DSCP value from the drop-down list. This value is required when you enable QoS marking. The default setting is Inherit from Class.
Preserve specifies that the DSCP level or IP ToS value found on pass-through and optimized traffic is unchanged when it passes through the SteelHead.
When you specify a DSCP marking value in a rule, it either takes precedence over or inherits the value in a class.
5. Click Save to Disk to save your settings permanently.
Note: In RiOS 6.5 and later, the DSCP field in a QoS classification rule for pass-through traffic matches the DSCP value before DSCP marking rules are applied. The DSCP field in a QoS classification rule for optimized traffic matches the DSCP value after DSCP marking rules are applied; that is, it matches the post-marking DSCP value.
Note: To modify a QoS rule, click the rule name. Enter the changes and click Save to Disk.
Verifying and Saving a QoS Configuration
After you apply your settings, you can verify whether the traffic is categorized in the correct class by choosing Reports > Networking: Outbound QoS and viewing the report. For example, if you have configured VoIP traffic as real-time, check the real-time class and verify that the other classes aren’t receiving VoIP traffic.
You can verify whether the configuration is honoring the bandwidth allocations by reviewing the Outbound QoS and Inbound QoS reports.
When you have verified appropriate changes, you can write the active configuration that is stored in memory to the active configuration file (or you can save it as any filename you choose). For details about saving configurations, see Managing Configuration Files.
Related Topics
•  Configuring Port Labels
•  Managing Configuration Files
•  Viewing Outbound QoS Reports