QoS Design
Traffic Classification Design
Services carried on a large or midsize campus network include voice, video, and data services and network protocol control signaling required for transmitting service data. QoS indicators of various services include the bandwidth, packet loss rate, latency, and jitter. Bandwidth can be controlled by configuring parameters, but packet loss rate, latency, and jitter cannot. In practice, QoS is deployed based on engineering experience, as shown in Table 2-68.
Service Category |
Typical Application or Protocol |
Packet Loss Tolerance |
Latency Tolerance |
Jitter Tolerance |
|---|---|---|---|---|
Network protocol |
Link-layer loop prevention protocols for network interconnection and interoperability, routing protocols, and multicast group management protocols, such as STP, OSPF, and IGMP. |
Low |
Low |
Permit |
Management protocol |
Protocols used by network administrators for monitoring network devices, delivering configurations, and diagnosing faults, for example, ICMP, SNMP, Telnet, and XMPP. |
Low |
Low |
Permit |
VoIP data flow |
Real-time voice calls over IP networks. The network must provide low latency and low jitter to ensure service quality. |
Very low |
Very low |
Very low |
Voice signaling |
Signaling protocols for controlling VoIP calls and establishing communication channels, for example, SIP, H.323, H.248, and Media Gateway Control Protocol (MGCP). Signaling protocols have a lower priority than VoIP data flows because call failure is often considered worse than intermittent voices. |
Low |
Low |
Permit |
Multimedia conference |
Multiple parties can share camera feeds and screens over IP networks. Protocols or applications can adapt to different network quality levels by adjusting the bitrate (image definition) to ensure the smoothness. |
Low or medium |
Very low |
Low |
Gaming |
The network is required to provide online interactive applications with low packet loss rate, latency, and jitter to ensure fast and accurate response during gaming. For example, online games that transmit operation instructions through RTP or UDP pose higher requirements on the network. |
Low |
Very low |
Low |
Streaming media |
Online audio and video streaming. Audio and video programs are made in advance and then cached on local terminals before being played. Therefore, the requirements on the network latency, packet loss, and jitter are reduced. |
Low or medium |
Medium |
Permit |
Online live broadcast |
Unlike streaming media, data of online live broadcast is sent and received in real time. Though terminals provide the cache mechanism, the network is required to provide the low packet loss rate and jitter to meet real-time requirements and ensure good experience. |
Very low |
Medium |
Low |
Delay-sensitive data service |
Data services that are sensitive to delay. For example, long delay on an online ordering system may reduce the revenue and efficiency of enterprises. |
Low |
Low or medium |
Permit |
Bandwidth-intensive services |
Network services that involve the transmission of a large amount of data for a long period of time, such as File Transfer Protocol (FTP), database backup, and file dump. |
Low |
Medium or high |
Permit |
Common services |
Basic services that have no special requirements on enterprise networks, such as email and web browsing. |
No requirement |
No requirement |
No requirement |
Low-priority services |
Services that are not important to enterprises, such social network and entertainment applications |
High |
High |
Permit |
QoS Scheduling Policy Design
QoS Scheduling Policy Design for Wired Networks
The basic principle of traditional QoS design for wired networks is to mark or re-mark packets at boundaries of different DiffServ domains and perform bandwidth control. Devices in the same DiffServ domain only need to schedule packets in queues based on the priorities marked on boundary nodes. Typically, service deployment involves traffic identification at the access layer, DiffServ model deployment at the aggregation or core layer, and bandwidth control on egress firewalls.
- Traffic identification at the access layer
Access switches function as boundary switches. The switches identify, classify, and mark data flows at the user side. In actual deployments, different interfaces on access switches are connected to different terminals. Different priorities can be allocated to different services on access switches. Then traffic of the services can be scheduled based on the priorities.
- DiffServ model deployment at the aggregation or core layer
Interfaces on aggregation and core switches are configured to trust DSCP or 802.1p priorities and enforce QoS policies based on priorities marked at the access layer, to ensure that high-priority services are scheduled first. A switch interface trusts 802.1p priorities by default.
- Bandwidth control on egress devices
Egress devices are also located in the DiffServ domain and are configured to trust DSCP or 802.1p priorities of packets and implement QoS policies. Due to egress bandwidth limits, you need to consider differences when setting bandwidth parameters for WAN interfaces of egress devices. Additionally, QoS policies of egress devices vary according to the enterprise WAN construction mode.
- WAN QoS policies can be managed by an enterprise itself in the following scenarios: enterprise-built WAN, private line construction using leased fibers, and customized enterprise QoS policies applied to the carrier WAN. In this case, egress or PE devices on the campus network do not need to re-mark traffic.
- The WAN QoS policies are not controlled by an enterprise itself. The enterprise leases the private line network of a carrier, and the carrier does not trust the packet marking on the enterprise network or the two parties have different definitions of the same packet marking. Thus, egress devices on the campus network need to re-mark traffic.
QoS Scheduling Policy Design for WLANs
The network efficiency of WLANs is lower than that of wired networks, and STAs are more sensitive to user experience. Therefore, you are advised to consider the following aspects when designing the QoS policies for STAs:
- The maximum bandwidth of a single user can be limited based on service requirements. If multiple SSIDs are planned, the total bandwidth of non-critical SSIDs can be limited.
- In high-density scenarios, many users preempt channel resources. As a result, the Internet access quality of each user deteriorates. You are advised to enable the following functions:
- The call admission control (CAC) function is used to control STA access based on the radio channel utilization and number or signal-to-noise ratio (SNR) of online STAs to ensure the Internet access quality of online STAs.
- The dynamic enhanced distributed channel access (EDCA) parameter adjustment function allows APs to adjust EDCA parameters flexibly by detecting the number of STAs to reduce the possibility of collisions, improve the throughput, and enhance user experience.
- To enable STAs (especially sticky STAs) to re-associate or roam to APs with better signals, enable the function of quickly disconnecting STAs to force low-SNR or low-rate STAs to go offline.
- In scenarios requiring high multicast service experience, you are advised to enable the multicast-to-unicast conversion function to improve multicast service experience (for example, HD video on demand) to prevent the impact of low-rate STAs on multicast services.
- In scenarios where VIP user experience needs to be guaranteed, you are advised to enable preferential access of VIP users to ensure preferential access, scheduling, and bandwidth guarantee for VIP users.
Only 802.11ax (Wi-Fi 6) APs support bandwidth guarantee.
Recommended Scheduling Policy Suggestions
The definition of important data services varies with enterprises. For a portal website, Internet access and gaming traffic is important; for the financial services industry, real-time transaction is more important than voice services and Internet access and gaming traffic is unwanted. Therefore, the QoS policy solution must be designed and deployed based on actual service types and QoS requirements of each enterprise. Table 2-69 lists the typical QoS policy solutions formulated based on engineers' experiences, which provide references for design personnel.
Application Type |
Typical Application or Protocol |
CoS |
Queue (Priority) |
Scheduling Algorithm |
Maximum Bandwidth |
|---|---|---|---|---|---|
Signaling and control |
|
CS6 |
6 |
PQ |
Unlimited |
Real-time interactive multimedia |
|
EF |
5 |
PQ |
Available interface bandwidth x 30% |
On-demand subscription of multimedia or key services |
|
EF |
4 |
DRR weight: 20 |
Unlimited |
Other services |
|
BE |
0 |
DRR weight: 20 |
Unlimited |
Intelligent HQoS Design
To deploy the intelligent HQoS solution, a network administrator needs to complete the planning of VIP users and applications, design of customized applications, and design of application scheduling templates.
VIP User-Level Application Planning
To implement application planning for VIP users, the network administrator needs to complete the following tasks:
- Identify user terminals whose traffic needs to be preferentially guaranteed and record VIP user information on iMaster NCE-Campus. The VIP attributes of user terminals are automatically synchronized to network devices through the authentication and authorization process.
- Analyze service traffic of VIP users, identify mission-critical and non-critical services, and classify key service traffic based on indicators such as the packet loss rate, latency, and jitter.
The following table describes an example plan for VIP users, providing a reference for network administrators.
VIP User |
Mission-Critical Service Category |
Typical Application or Protocol |
Packet Loss Tolerance |
Latency Tolerance |
Jitter Tolerance |
Bandwidth (Mbit/s; Burst or Not) |
|---|---|---|---|---|---|---|
VIP1 |
VoIP |
Instant messaging applications APP1 and APP2 |
Very low |
Very low |
Very low |
2; no burst |
Internet_Conferencing |
Online video conferencing applications APP3 and APP4 |
Low or medium |
Very low |
Low |
10; burst |
|
VIP2 |
Remote_Desktop |
Remote desktop application APP5 |
Low or medium |
Very low |
Low |
20; burst |
Database |
Database applications APP6 and APP7 |
Low |
Medium or high |
Permit |
1; no burst |
This example defines two VIP users (VIP1 and VIP2) and analyzes indicators of mission-critical applications of the VIP users, including the packet loss rate, latency, jitter, and bandwidth requirements. For details about traffic classification, see Traffic Classification Design.
The VIP users and applications in the preceding table are for reference only, and used to demonstrate the planning and design methods and logic. Therefore, the indicator data cannot be recommended in actual deployments.
Design of Customized Applications
After planning for VIP users and analyzing service traffic, you need to design rules for defining applications. Applications on a campus network fall into predefined applications and customized ones.
- Predefined applications are those predefined in the Huawei Smart Application Control (SAC) signature database. SAC-capable network devices can automatically identify such applications. Administrators only need to select applications from the SAC signature database and add them to an application scheduling template. After an application scheduling policy is delivered to a network device, the network device can use the SAC function to identify applications. For details about the Huawei SAC signature database, visit https://isecurity.huawei.com/sec/web/freesignature.do.
- Customized applications are not present in the SAC signature database. The intelligent HQoS solution supports application customization by specifying URLs or combinations of service IP addresses and ports. The following table lists an example of designing customized applications.
Application |
Description |
Type (URL/IP) |
Protocol |
Port |
|---|---|---|---|---|
APP1 |
Live video streaming |
172.16.33.22 |
UDP |
6666 |
APP2 |
Database access |
https://database.company.com |
- |
- |
You are advised to customize applications using the preceding two methods. After customizing applications on iMaster NCE-Campus as an administrator, you can add the customized applications to an application scheduling template.
When the intelligent HQoS solution is used, only standalone WACs support SAC-based application identification, whereas switches do not support this application identification method.
Design of Application Scheduling Templates
After completing the design of application identification for VIP users, you need to design application scheduling templates. In the intelligent HQoS solution, differentiated application scheduling templates are authorized to VIP users to implement differentiated traffic scheduling policies. This ensures that key service traffic of VIP users can be forwarded properly. After designing application scheduling templates, you need to complete the following tasks:
- Define the priorities of mission-critical services based on the analysis results of VIP users.
- It is recommended that a shaping bandwidth be configured for applications that may have burst traffic. For example, if the average bandwidth of a video application is less than 10 Mbit/s and the peak bandwidth is 100 Mbit/s, the shaping bandwidth can be set to 10 Mbit/s.
- A maximum of 31 application scheduling templates can be defined through iMaster NCE-Campus. Table 2-71 describes the configuration logic for reference.
- Application scheduling templates cannot be defined for common users. Application traffic of common users can only be scheduled based on the default configuration of network devices, requiring no additional configuration.
Application List |
Priority (a Higher Value Indicates a Higher Priority) |
Shaping Bandwidth of Burst Traffic (Mbit/s) |
|---|---|---|
Other applications |
1 |
- |
Non-critical service application APP6 |
2 |
- |
Non-critical service application APP5 |
3 |
- |
Customized application APP4 |
4 |
20 |
Video conferencing application APP3 |
5 |
10 |
Customized application APP2 |
6 |
- |
Instant messaging application APP1 |
7 |
- |
Since the service traffic models of VIP users VIP1, VIP3, and VIP5 are similar, the same application scheduling template is defined for the three VIP users. After the application scheduling templates of all VIP users are designed, you can authorize these templates to respective VIP users on the controller. Scheduling policies will be automatically delivered to network devices.
Design Precautions
- Access points (APs) on a wireless network must be configured to work in tunnel forwarding mode, and wireless traffic must be centrally forwarded by the WAC.
- The following table describes the recommended campus network architectures.
Network Topology
User Gateway
User Authentication Point
WAC
Independent wireless network
WAC
AirEngine 9700-M
AirEngine 9700-M
Wired and wireless converged network
S12700E (core switch)
S12700E (core switch)
Native WAC (S12700E)
- To support HQoS, the S12700E must be equipped with the LST7Y40SX6H0 interface card. The allowable number of VIP user terminals depends on the number of interface cards. Each interface card can be configured with a maximum of 16,000 VIP user terminals (allowing up to 12,000 wireless terminals).
- When the AirEngine 9700-M functions as a wireless user gateway, a maximum of 1800 VIP user terminals can be configured.
- In the centralized gateway solution, the S12700E functioning as a border node provides the native WAC function and is used as the wired and wireless user gateway. In this scenario, HQoS is supported only for wireless terminals, but not for wired terminals.
- When a core switch functions as the user gateway, the network administrator needs to enable application identification and priority remarking on the egress firewall and configure uplink ports of the core switch to trust DSCP values.
- To avoid excessive resource competition among VIP users, it is recommended that the proportion of VIP users be within 10% of the total number of users.
- The network administrator can configure a maximum of 31 application scheduling templates on iMaster NCE-Campus.
- To configure application scheduling templates through the WAC, the network administrator needs to switch to the WAC's web system from iMaster NCE-Campus.