QoS Mirroring

QoS Mirroring enables the access point AP to appropriately prioritize downlink traffic into the correct user priority queues by observing how the wireless client sets priority on the uplink traffic. If a client places a particular uplink flow into a voice queue, the AP will recognize that the downlink traffic, which mirrors that flow, should also be placed into the voice queue.
This content is reused between SmartZone and Unleashed. While updating this content, make sure to use appropriate platform conditions to streamline content for respective platforms.
To provide an overview of a feature and its benefits. May require several Concept topics to keep content in short, manageable, and reusable chunks of content.

The intention of this new template is to outline the information that you will need to collect from SMEs and provide to readers.

NOTE: Feature Configuration / Troubleshooting are *not* part of the Feature Concept template. These templates are likely to be part of seperate task/reference templates (to be developed).

General Notes for Concept Topics:
  • Optional sections are to be used with discretion based on the feature characteristics.

Feature Overview

This QoS mirroring is necessary because packets often arrive at the AP without useful DSCP headers, which the AP relies on to place packets in the correct queues. The internet either strips these DSCP headers off or they are never set in the first place.

The QoS mirroring feature allows an AP to provide better quality of service for real-time data flows like Zoom and FaceTime, especially when the AP is loaded with other traffic. This improved quality of service directly translates to a better end-user experience.

There are two types of QoS Mirroring:

  • Enabled via Protocol (Standards-Based QoS Mirroring): In this method, the client device signals the AP about which data flows should have QoS mirroring applied.

  • Enabled for All (Unilateral QoS Mirroring): It automatically mirrors the QoS settings of uplink traffic to downlink traffic, ensuring consistent priority handling.
This section is required. Providing detailed and accurate information in the feature overview is crucial as it helps users understand the functionality, benefits, and usage of the feature. Moreover, it ensures consistency in communication across all platforms, enhancing user experience and product perception.
  • What is the name of the feature? (What do users call the feature? If the feature is referred to by an acronym, what is the acronym expansion? What is the formal name to be used in documentation?)
    Note: Typically, the name is used as part of the section titles, such as the overview title and the configuration section titles.
  • Where does the feature fit within our taxonomy? (What are the taxonomy group and sub-group? This information is important for categorizing the feature documentation and incorporating it into the existing document sets.)
  • What standard or standards govern the feature? (Sometimes needed.)
  • Is the feature a new feature or an enhancement to an existing feature?
  • Does the feature replace another feature?
  • What does the feature do? (General description)
  • How does the feature benefit the user?
  • What set of terms do the writer and reader need to know to understand the feature and its use?
  • How does the feature work? (Detailed description, if needed.)

Requirements

This feature has no special hardware or software requirements for feature enablement or usage.

This section is required. Including this section, even when there is no impact, lets SMEs and customers know that the associated information was not forgotten.

If there are no requirements, use the following default wording:

This feature has no special hardware or software requirements for feature enablement or usage.

If there are requirements, include the applicable below points (depending on product line):

  • What releases support the feature?
    Note: Typically, this is not documented in the configuration guides; however, we need to know where to include the information.
  • What hardware models support the feature?
  • Does the feature require specific modules?
  • Does the feature run only on certain ports?
  • Does the feature have special memory requirements?
  • In an integrated system, can the feature be managed or configured from another device? What are the related release and system requirements?
  • Does the feature introduce new user requirements?
  • Does the feature introduce physical or location-based requirements?

Best Practices

This feature has no special recommendations for feature enablement or usage.

This section is required. Including this section, even when there is no impact, lets SMEs and customers know that the associated information was not forgotten.

If there are no best practices (recommendations), use the following default wording:

This feature has no special recommendations for feature enablement or usage.

If there are considerations, include the applicable below points (depending on product line).

  • Brief list of RUCKUS recommendations on product use to optimize performance.
Parent topic: Quality of Service (QoS)