Quality of Service: Key Concepts and Testing Needs (par EXFO)
- Thierno Diallo, Product Specialist, Transport and Datacom Business Unit
With the increasing demand for advanced voice and video services, the traditional best-effort delivery model is no longer adequate to attract and retain premium service customers, who are essential to profitable carrier services. As network traffic increases, events such as congestion and data priority become an issue and can seriously affect traffic flows and delivery. Service providers must guarantee a predetermined level of service, regardless of traffic levels. To do so, a set of mechanisms known as quality of service (QoS) is used to prioritize data and guarantee performance to support customer service-level agreements (SLAs).
The objective of this article is to introduce various concepts related to QoS and the testing needs for such mechanisms.
Quality of Service Drivers
Interconnected networks rely on devices such as switches and routers to forward traffic via links of different rates (e.g., 10/100/1000BaseT). As packets are forwarded to the next hop, they are queued in outgoing buffers of the used port until transmission is ready to occur. However, the links are sometimes saturated when too much data uses the same link to reach the next hop. These periods of congestion are usually due to the bursty nature of traffic in interconnected networks and sometimes to the restricted capacity of the link versus the amount of traffic that needs to use it. In such cases, network congestion occurs and packet loss, latency-inducing buffering or packet jitter become inevitable.
The emergence of triple-play services, a combined offering of voice, video and data, is a major driver in the establishment of QoS in networks. As carriers trend toward these new services, they must ensure that their network can handle and prioritize these data flows to properly service them. Voice and video packets are notoriously sensitive to packet jitter and packet loss, so they must be treated accordingly. With proper QoS mechanisms, carriers can ensure that voice and video packets are recognized and prioritized.
Different levels of service are offered via the QoS mechanisms. With proper configuration, QoS can ensure that specific flows match the SLAs negotiated with customers. Carriers can therefore establish pricing structures based on different priority classes (i.e., platinum, gold, silver and bronze services) while maintaining a best-effort service for other non-critical services.
Why Test Quality of Service?
QoS is very important for both service providers and their customers. As mentioned previously, when carriers and service providers offer a service, they must guarantee a certain level of quality. The quality of that service depends on the pre-determined service contract or SLA. For example, some customers may have critical traffic and be willing to invest more to ensure that their traffic remains the highest priority on the network. Other customers may have less-critical traffic and therefore do not require uninterruptible, 24-hour service. Regardless of the agreement, failure to respect the QoS requirements of the customer contract often results in damage compensation by the service provider. For this reason, it is vital to properly test QoS, ensuring that SLAs are met under normal and congestion conditions.
Network Events that Affect Quality
QoS aims to control the following network events:
1. Bandwidth
Bandwidth refers to the data rate that can be used by a particular flow at a given time. Bandwidth is usually dependent on the line rate of the link, which means that there is a limited amount of bandwidth available for all flows and that they must share this bandwidth. When flows require more bandwidth than is available, QoS mechanisms are used to prioritize and provide availability to higher-priority flows while lower-priority flows are either queued or discarded.
2. Latency
Latency is a measurement of the time delay between the transmission and the reception of a packet. Typically, this is a round-trip measurement, meaning that the calculation measures both the near-end to far-end and the far-end to near-end directions simultaneously. This measurement is critical for voice applications, in which too much latency can affect call quality, leading to the perception of echoes, incoherent conversation or even dropped calls.
3. Jitter
Jitter is a measurement of the variations in the time delay between packet deliveries. As packets travel through a network to their destination, they are often queued and sent in bursts to the next hop. There may be prioritization at random moments also resulting in packets being sent at random rates. Packets are therefore received at irregular intervals. The direct consequence of this jitter is stress on the receiving buffers of the end nodes where buffers can be overused or underused when there are large swings of jitter. Video applications are especially sensitive to jitter as set-top boxes (STB) use and display video packets at regular intervals. Their buffers are designed to store a certain quantity of video packets that are then processed and displayed at a regular interval to provide a smooth and error-free image and sound quality to the end user. Too much jitter will affect the quality of experience (QoE) since packets arrive at different rates; those arriving at a fast rate will cause the buffers to overfill, leading to packet loss, while packets arriving at a slow rate will cause buffers to empty, leading to still images or no sound.

Figure 1. Graphical illustration of jitter effects
4. Packet loss
Packet loss is the loss of a packet of data. Packets can be lost for a number of reasons such as errors during the transmission or network congestion. Errors due to a physical phenomenon can occur during the transmission of the frame and will result in packets being discarded by networking devices such as switches and routers, based on frame check sequence (FCS) field comparison. Network congestion will also cause packets to be discarded, as networking devices must drop packets in order not to saturate a link in congestion conditions.
The Basics of QoS
QoS implementation can be summarized in three stages:
1. Classification
Classification is the first stage of a QoS implementation. It is a process by which incoming packets are identified and prioritized based on specific trigger characteristics. At this stage, packets are classified by flows, where a flow refers to a group of packets sharing the same attribute defined by specific triggers. These triggers can include:
- Layer 1 information such as incoming ports
- Layer 2 information such as VLAN ID or VLAN P-bit user-priority fields
- Layer 2.5 multiprotocol label switching (MPLS) information such as MPLS label or EXP/COS bits
- Layer 3 information such as IPv4 type of service (ToS) or differentiated services code points (DSCP), IPv6 traffic class and flow label fields
- Deep inspection for specific protocols such as transport control protocol (TCP)
- A combination of different trigger points such as specific VLAN and specific IPv4 DSCP
2. Shaping and policing
Shaping and policing are stages where flows are manipulated in order to conform to the desired bandwidth and burst requirements. Policing will create a bandwidth ceiling where packets from a flow that has superseded its allocated bandwidth will be discarded. Shaping, on the other hand, regulates the number of consecutive packets from the same flow that can be transmitted and buffers packets exceeding the burst size requirements to allow other flows to use the link. Shaping creates a better overall use of the link but may lead to transmission delay due to the buffering process.
3. Scheduling
The scheduling stage determines how a packet from a flow exits the QoS device. Its process queues packet and schedules when packets can exit the device according to their priority. Typically, scheduling functions are only used during congestion periods.

Figure 2. Graphical illustration of each QoS stage
QoS Devices
Different devices are used to implement QoS on a network. Devices such as switches and routers are typically used to perform QoS, as they handle traffic based on Layer 2 or Layer 3 information. A new class of device, the Ethernet demarcation device, provides dedicated QoS implementations in small units that can be installed at the edge of the customer network. These devices can inspect packets and enforce QoS policies without the constraints of performing extensive routing and switching functions.

Figure 3. QoS device implementation
Testing needs
Testing a network’s QoS mechanism requires specific tools in order to simulate real-life scenarios, including multistream traffic generation and monitoring, per-flow analysis and measurement of QoS controlled parameters.
Multistream capabilities
Testing using a single test stream is appropriate to ensure that a flow cannot exceed a specific bandwidth rate. However, the true use of QoS lies in its ability to handle multiple flows simultaneously and in diverse situations. Any QoS testing must be performed with a certain number of flows in order to stress the QoS implementing device to scenarios that are as close as possible to real-life implementations.
Per-flow analysis
A global picture is not the ideal tool for QoS testing, as results do not guarantee that parameters are properly enforced per flow. Per-flow analysis provides the ability to ensure that QoS profiles are properly enforced and helps determine the performance that can be attained for each flow under congestion conditions.
QoS statistics
The ideal test tool should measure bandwidth, jitter, latency and packet loss, as these characteristics are usually controlled in QoS implementations. Testing should also provide service-affecting statistics such as out-of-sequence counts and any errors in the packets such as checksum errors.
Conclusion
Testing a network for QoS can seem like a daunting task, but with the proper tools, network operators can qualify and ensure that they meet the services that they sell to their customers. EXFO proposes different solutions to help test and troubleshoot networks with QoS implementations. For more information on the various testing scenarios, please contact us.
Infractive :
+33 –(0)1 75 49 81 30
contact[at]infractive.fr