QoS Mirroring
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).
Feature Overview
QoS prioritizes real-time flows, such as voice, video, and gaming) over asynchronous flows (such as file downloads and movie streaming), in accordance with the associated upstream traffic flows within the WLAN. The following QoS mirroring modes are implemented depending on the WLAN QoS Mirroring configuration):
- Mirrored Stream Classification
Service (MSCS) implemented as per IEEE standards:
MSCS is a Wi-Fi CERTIFIED QoS Management technology that allows each client device to request the AP to assign priorities to specified downlink traffic flows, aligning the priorities with what the client initially assigned to the corresponding uplink traffic flows. When QoS Mirroring is enabled via protocol, the client prompts the AP to initiate mirroring by sending the AP an MSCS request.
MSCS begins only when the downlink packet from the server is tagged as differentiated services code point (DSCP) 0x00 (in other words, the packet is not classified). The client devices use a dedicated frame exchange to trigger the MSCS process.
- RUCKUS Unilateral QoS mirroring
implemented as a RUCKUS Proprietary functionality:
Unilateral Mirroring is an exclusive RUCKUS feature that provides QoS mirroring without requiring signaling between the AP and the client, extending the advantages of mirroring to legacy clients that lack support for MSCS. When QoS Mirroring is enabled for all clients, the AP automatically assigns an equivalent priority to each downlink flow for a legacy client, mirroring each of its flow with the priority of its corresponding uplink flow. Clients with MSCS support explicitly initiate mirroring by sending an MSCS request to the AP.
Following are the benefits of MSCS:
Following are the benefits of RUCKUS Unilateral QoS mirroring:
- Benefits legacy clients without MSCS support
- Mirrors downlink priorities without signaling between an AP and client
- Supports both the MSCS and non-MSCS clients
- 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.
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.
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).