Quality of service guidelines
Table of contents
1. Introduction
The purpose of this document is to provide information to ensure that quality of service (QoS) is properly deployed in enterprise networks to support unified communication traffic.
2. End-to-End network path performance requirements
The requirements stated in Table 2.1 need to be satisfied to optimize the network path for VoIP and Video media traffic when using RingCentral unified communication services. For video communication, the same or slightly relaxed requirements may be imposed since it must, ideally, be transported synchronously with voice.
| Table 2.1 - End-to-End network path performance requirements | |
| Network Property | Requirement |
Link Capacity
|
Each link in the end-to-end path must have symmetric (bi-directional) capacity larger than the network traffic generated by the maximum number of simultaneous voice and video calls. This is in addition to capacity for other types of non-real-time traffic and growth (Section 5).
|
Delay
|
< 150 ms (one-way)*. This translates to <300ms round-trip latency.
Longer times, as in the case of geosynchronous satellite links, will work, but the call parties must accept the extremely long communication delay.
|
Packet Loss
|
< 1%
|
Jitter
|
< 30 ms
|
*https://www.itu.int/rec/T-REC-G.114-200305-I/en, Appendix II.
3. Deployment, configuration, and assessment guidelines
To ensure that the end-to-end path performance requirements are met, a set of deployment, configuration, and assessment guidelines must be followed:
- Supported devices and configurations must be used (Network Requirements).
- Domain, IP address and port configurations must be applied to network devices. including network and compute firewalls, routers, and Layer 3 switches (Network Requirements).
- DSCP tagging must be applied and honored by enterprise networks (Section 4).
- Sufficient capacity must be available on all network links that are traversed by unified communication traffic, under maximum usage (Section 5).
- Network assessment must be performed at enterprise sites if deemed necessary (Section 6).
4. QoS classification and traffic treatment policies
Unified communication services traffic needs to be classified and appropriately treated in enterprise and service provider networks to ensure that end-to-end QoS requirements are met for cloud-based communications services so that intermittent service quality issues due to large file or email transfers are minimized.
VoIP and video QoS impose the most severe constraints on the network because of the delay, packet loss, and jitter requirements that need to be met. Signaling traffic has lower QoS requirements since real-time requirements do not apply and packets can be retransmitted when lost. Other types of service traffic, such as messaging and directory services, can be treated more like data traffic.
The following sections indicate how communication services traffic should be ideally classified and treated in the context of the enterprise network and WAN. In practice, it may only be possible to partially follow the QoS traffic class and treatment requirements due to limitations of endpoints, network devices, and ISP and carrier networks. Recommendations to handle these sub-optimal cases are provided as well.
The following conventions are used concerning the direction of unified communication traffic flow:
- Outbound traffic is directed from the enterprise or remotely deployed end-point (phone/PC) toward the unified communication cloud service.
- Inbound traffic is directed from the unified communication cloud service toward the enterprise or remotely-deployed endpoint.
4.1 Traffic classification
Packet classification identifies and categorizes traffic into a specific class. Table 4.1.1 indicates the traffic classes that are differentiated for unified communication services. The class requiring the highest priority treatment (VoIP Media) is indicated at the top. At Layer 2, Class of Service (CoS) frame header tagging is indicated, while DSCP packet marking is available in the IP header in Layer 3.
In the next considerations, tagging at Layer 2 and marking at Layer 3 is generically called marking. Video media is assigned a slightly lower priority than voice since it is deemed more important to have high-quality voice communication in case of adverse network conditions.
CoS is a 3-bit field in the Ethernet frame header with possible values ranging from 0 to 7. DSCP is a 6-bit field in the IP packet header with possible values ranging from 0 to 63.
Security is implemented above the IP layer, e.g., secured VoIP media is transported as SRTP/UDP/IP (SRTP is the secure version of RTP), which does not affect CoS and DSCP values.
| Table 4.1.1 - Traffic Types and Classification | ||||
| Layer 2 | Layer 3 | |||
| Traffic Class | CoS Decimal Value |
DSCP Decimal Value |
Name |
Drop Probability |
VoIP Media - Real Time |
5 |
46 |
EF |
N/A |
Video Media - Real Time |
4 |
34 |
AF41 |
Low |
SIP |
3 |
26 |
AF31 |
Low |
Transactional: • Network Time Service • Mobile App Data Sync • LDAP Directory Service |
2 |
18 |
AF21 |
Low |
Best Effort: Phone Provisioning and firmware update |
0 |
0 |
BE |
Undetermined |
4.2 Traffic scheduling
Traffic scheduling in network devices determines how the different traffic from different classes is prioritized when transmitted out an interface. VoIP traffic must be transmitted before any other traffic types. This ensures that the requirements detailed in Table 2.1 are met.
Video conferencing is interactive and must be separated from one-way video streaming services. End-user experience will not be affected if traffic is delayed when a user is watching this type of content.
4.3 Practical constraints
Ideally, the CoS tagging and DSCP marking values indicated in Table 4.1.1 are used across the entire network between endpoints and cloud-based servers. When traffic is treated according to this classification, it is referred to as honoring the marking. However, in practice, this is often not entirely possible because:
- Some network devices do not support sufficient QoS capabilities. Examples are low-end routers.
- CoS values are often not managed in small networks.
- ISPs may change DSCP markings along the Internet path, e.g., from DSCP 46 to 0.
- In large corporate enterprise networks, with sites connected to an MPLS or Metro-Ethernet network, the DSCP ⇔ CoS mapping must be performed by the WAN network border devices. These mappings may not maintain the exact optimal CoS/DCSP values indicated in Table 4.1.1.
- Some endpoint types do not yet mark CoS/DCSP value (Section 4.4).
Some practical requirements and recommendations for traffic classification, DSCP marking, and a description of Layer 2 WAN interconnections are provided in the following sections to address these constraints.
4.4 Traffic classification methods
The QoS capabilities of the local network device determines which traffic classification and scheduling method can be used.
- Multi-Band Classification – Providing maximum traffic prioritization to and from cloud servers is mapped according to Table 4.1.1. Providing optimal traffic delivery for five traffic types:
- Voice
- Video
- Signaling
- Transactional
- Best Effort
- Voice
- Three Traffic Classes Model – Traffic to and from cloud servers is mapped according to Table 4.4.1.
- Two Traffic Classes Model – Real-time voice and video UDP traffic and SIP TCP traffic originating from or destined to cloud communication media servers are all classified as DCSP 46. Other traffic is classified as unprioritized data traffic with DSCP and CoS values equal to 0. This model is indicated in Table 4.4.2.
Multi-band classification offers the best way to handle QoS in large corporate networks and whenever the network devices support this. Two traffic type classes model is relatively simple to implement and works well in most SoHo and corporate environments with devices with limited QoS capabilities.
Where feasible, expanding the classes to differentiate VoIP from video, and other traffic will enhance quality of service functionality in an enterprise network.
| Table 4.4.1 - Three Traffic Classes Model | ||||
Traffic Class |
CoS Decimal Value |
DSCP Decimal Value |
Name |
Drop Probability |
VoIP Media - Real-Time SIP |
5 |
46 |
EF |
N/A |
Video Media - Real Time |
4 |
34 |
AF41 |
Low |
Transactional: • Network Time Service • Mobile App Data Sync • LDAP Directory Service • Best Effort: Phone Provisioning and firmware update |
0 |
0 |
BE |
Undetermined |
| Table 4.4.2 - Two Traffic Classes Model | ||||
Traffic Class |
CoS Decimal Value |
DSCP Decimal Value |
Name |
Drop Probability |
VoIP Media - Real-Time Video Media - Real-Time SIP |
5 |
46 |
EF |
N/A |
Transactional: • Network Time Service • Mobile App Data Sync • LDAP Directory Service • Best Effort: Phone Provisioning and firmware update |
0 |
0 |
BE |
Undetermined |
4.5 Endpoint and internet DSCP traffic marking constraints
The following types of DSCP marking are applied by endpoints, cloud media servers, and Internet Service Providers:
- Endpoints
- Desk phones use IP Differentiated Services Code Point 46 (Expedited Forwarding - EF) marking for UDP media (RTP) packets. This way, routers in an enterprise network can prioritize VoIP media traffic over best-effort data traffic.
- Soft endpoints (softphones, video client, MVP, and Google Chrome clients) mark UDP media packets according to the proper priority marking. However, the Operating System may reset them to DSCP 0. To mitigate this issue, one of two options may be applied:
- An Operating System policy (Group Policy) must be configured to override this
behavior.
- The first Layer 3 device away from the soft endpoint must be configured to
remark traffic appropriately.
- Desk phones use IP Differentiated Services Code Point 46 (Expedited Forwarding - EF) marking for UDP media (RTP) packets. This way, routers in an enterprise network can prioritize VoIP media traffic over best-effort data traffic.
- Media Servers - Cloud media servers mark UDP media traffic as DSCP 46 (voice) or DSCP 34 (video).
- Mobile Applications mark traffic with a DSCP value according to Table 4.1.1.
- Internet Service Providers - Internet Service Providers frequently remark DSCP priority values to different (lower) values, which has the following implications:
- Outbound direction: Traffic often arrives in the RingCentral cloud with improper marking.
- Inbound direction: Internet traffic may arrive at an enterprise site incorrectly marked from the Internet and, therefore, needs to be re-marked immediately by the enterprise network border device. This will ensure that traffic will be forwarded inside the internal network based upon the correct priority relative to other traffic.
4.6 DSCP marking policy
This section describes traffic treatment policies for (re-)marking DSCP values in enterprise networks. The following DSCP marking and honoring (i.e., keeping the assigned DSCP value and forwarding it according to the priority of the assigned value) policy must be implemented in switches, routers, and firewalls in the end-to-end communication path between endpoints and cloud-based servers:
- Outbound Direction - Remark traffic to the correct DSCP value as close as possible to the endpoint if the endpoint does not mark the correct value using the guidelines in Section 4.4. The remarking may occur in network devices like Access Points, access switches, routers, and firewalls.
- Inbound Direction - Remark traffic to the correct DSCP value as soon as it enters the enterprise network via a carrier WAN link or WiFi Access Point.
- Inside the Local Network - Honor the DSCP markings throughout the enterprise network in both the inbound and outbound direction.
- WAN Network - Any mapping from DCSP to CoS and back needs to be performed so that end-to-end path QoS requirements are maintained.
The supernets and whitelisting tables as provided in Network requirements | MVP must be used in the inbound and outbound ACLs to define the stated QoS policies. Local subnet address ranges should not be used to define QoS policies because any subnet changes would require modification of the policy.
Some firewall manufacturers do not support re-marking of DSCP but may support prioritization of packet forwarding based on source IP addresses and IP address ranges, which also requires that the supernets must be used in the QoS policy definition.
4.7 Bandwidth management
Most routers support bandwidth management, which can be used to guarantee the capacity for certain types of traffic even under saturation conditions. If routers support bandwidth management, then it is advised to enable this feature and set the bandwidth for traffic to the number obtained from Section 5. If the traffic classification and policies are configured according to the recommendations and requirements stated in prior sections and the traffic exceeds the configured bandwidth, traffic may still get prioritized over regular data traffic although bandwidth may not be guaranteed for all calls (depends on the router and setting).
It is essential that the committed bandwidth value of the ISP/carrier link is configured in the edge router/firewall since it has no other way to accurately determine the circuit capacity. The ISP/carrier burst value should not be used as there is no guarantee that it will be honored, and traffic will be discarded. Once the maximum committed bandwidth has been entered, portions of this capacity can be tagged for traffic with DSCP 46 (voice), DSCP 34 (video), and DSCP 26 (signaling).
An enterprise site may produce traffic in excess of the committed bandwidth of an external network link, but the ISP/carrier typically ignores excess traffic regardless of its type. Therefore, the enterprise edge router/firewall must be configured to drop low priority outbound traffic so that the ISP/carrier does not intermittently discard voice/video media stream packets.
4.8 Layer 2 WAN interconnection
Large enterprise networks frequently rely on Layer 2 MPLS or Metro-Ethernet WAN networks to interconnect Layer 3 networks. To ensure that the end-to-end network path performance (Section 4) are adhered to, several conditions must be met at the ingress and egress border of these networks:
- Traffic class and priority matching – Ensure that the number of traffic classes and CoS values with the guidelines provided in Section 4.4.
- Traffic shaping – Ensure that the maximum Layer 3 network bandwidth produced for each traffic class does not exceed the WAN link capacity. This can be accomplished by traffic shaping provided that the average bandwidth does not exceed the provisioned WAN capacity.
If the Traffic Class and Priority Matching condition cannot be met, then some Layer 3 DSCP values must be mapped to a higher CoS value.
5. Bandwidth and network capacity assessment
Two methods can be used to determine the bandwidth produced by traffic on LAN and WAN links and the capacity required to carry unified communication traffic.
The preferred and most accurate method is to determine the peak traffic load from logs or network data extracted from a still deployed legacy voice/video system. Alternatively, a bandwidth and capacity calculation procedure can be used (Bandwidth and network capacity assessment).
6. Network readiness assessment
The end-to-end path QoS requirements stated in Section 2 can be validated by performing a Network Readiness Assessment, which determines the quality of the LAN and the Service Provider network. Two types of Network Readiness assessments can be performed to validate the ability of a network path to support unified communication services:
- Snapshot Network Readiness Assessments - These assessments provide an impression of network capacity and quality for each direction of VoIP and Video traffic between a test site and the unified communication cloud over a time interval of a few minutes. Two test tools are provided:
- Comprehensive Network Readiness Assessment - In this case, a probe is installed at the local customer site. By running this probe over a longer time interval (e.g., a full business week), a much better impression of the end-to-end quality and intermediate network hop quality in both directions of the call is obtained. Detailed and targeted network improvement recommendations can be provided based on the results of this type of assessment.
The first type of assessment can be performed by the enterprise but provides minimal insight into the end-to-end QoS over time. The second type of network assessment, which is recommended to minimize the likelihood of user-perceived QoS issues, requires the involvement of RingCentral Professional Services.