Inbound QoS

You configure inbound QoS in the Networking > Network Services: Quality of Service page. RiOS 9.0 and later provide feature parity between outbound and inbound QoS.

Inbound QoS allocates bandwidth and prioritizes 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.

Some examples of environments that can benefit from inbound QoS are:

• A deployment that doesn’t have a SteelHead located at the traffic source (for example, the traffic comes from the internet or from servers at a site without a SteelHead).

• A deployment that has multiple SteelHeads located at the traffic source (for example, behind an Interceptor cluster). The SteelHeads don’t share bandwidth information with each other. As a result, they can overwhelm the branch office site at the remote location.

• A branch office receiving data from multiple data centers (either with or without SteelHeads). Because the two data centers don’t coordinate the amount of bandwidth sent to the branch office, they can overwhelm the link at the branch office, causing degraded performance.

Configuring inbound QoS focuses on prioritizing types of traffic using rules and classes just like outbound QoS. The inbound configuration is separate from the outbound configuration. You define the applications on the local network and then create their corresponding shaping policies.

Inbound QoS applies the HFSC shaping policies to the ingress traffic. Applying policies to the ingress traffic addresses environments in which bandwidth constraints exist at the downstream location. When this condition occurs, the downstream SteelHead (where inbound QoS is enabled) dynamically communicates the bandwidth constraints to the client transmitting the traffic. The client slows down the throughput and the traffic adheres to the configured inbound QoS rule. Inbound QoS, just like outbound QoS, isn’t a dual-ended SteelHead solution. A single SteelHead performing traffic shaping as needed to avoid network congestion controls inbound WAN traffic on its own.

For details about the HFSC queueing technology, see Traffic classification and the SteelHead Deployment Guide.

QoS rules define the types of traffic flowing into the branch office. As with outbound QoS, the rule can match the traffic based on VLAN, IP header values, TCP/UDP ports, and AFE information. As an example, you can ensure that the voice traffic on the WAN is reserved a fixed bandwidth and this traffic has a higher priority over the recreational internet traffic.

Inbound classes shape the inbound traffic. The class configuration resembles an outbound QoS class configuration. An outbound QoS configuration describes remote sites and applications. Inbound QoS describes the local services and applications and how to shape the inbound traffic.

The inbound traffic shaping configuration includes a default shaping class. The QoS scheduler applies the built-in inbound default class constraints and parameters on traffic not placed in any other class by the configured QoS rules. The default shaping class has a 10 percent minimum bandwidth allocation and a 100 percent maximum bandwidth allocation. You can’t delete the default class; however, you can change its bandwidth allocations.

These limitations apply to inbound QoS traffic shaping.

• When packet-mode optimization is enabled, the QoS scheduler places UDP4 traffic into the MX-TCP class. All other traffic goes into the proper class.

• Inbound QoS doesn’t throttle certain flows such as MX-TCP and UDP bulk traffic flows; however, it does provide bandwidth and latency reservation for them.