<%NUMBERING1%>.<%NUMBERING2%>.<%NUMBERING3%> PRTG Manual: Monitoring Quality of Service
PRTG can monitor the Quality of Service (QoS) in a network with dedicated QoS sensors, as well as Cisco IP service level agreement (SLA) and Cisco Class Based Quality of Service (CBQoS). Slight variations in network parameters like jitter, packet loss, or packet delay variation (PDV) usually have only little effect on Transmission Control Protocol (TCP) based services (for example, HTTP and Simple Mail Transfer Protocol (SMTP)). But for User Datagram Protocol (UDP) based services like Voice over IP (VoIP) and video streaming, a steady stream of data packets is crucial. The sound quality of a VoIP call drops noticeably when UDP packets are not received in time, or if packets are lost or in the wrong order.
As a rule of thumb for good quality of service (from a VoIP perspective), it is important to have low measurements for jitter (less than 20 to 50 ms) and PDV (less than 100 ms), and preferably zero measurements for packet loss, duplicated packets, or packets in wrong order.
The QoS sensors monitor the quality of a network connection by measuring the following parameters:
Jitter in ms according to RFC 3550
PDV in ms according to RFC 3393
Lost packets in %
Out-of-order packets in %
Duplicated packets in %
The QoS sensors measure the quality of service by sending UDP packets between two probes. This means that you can test any network connection in your network by placing a remote probe on (or near) each end of the connection and measuring the connection quality between them. This way, you can find network issues that can affect VoIP sound quality or cause video streaming issues.
You can also use the QoS (Quality of Service) Round Trip sensor without installing a remote probe at the connection endpoint. For details about the PRTG QoS Reflector, see the Knowledge Base: How can I monitor QoS round trips without using remote probes?
Monitoring Quality of Service with PRTG
The measurements for QoS monitoring are taken between two probes. So the first step is to place two PCs running a remote probe on (or near) both ends of the connection that you want to monitor. As an alternative, the local probe on the PRTG core server system can also be used as one end, or you can use the PRTG QoS Reflector (see the Knowledge Base) to bounce the packets when monitoring QoS roundtrips. If any firewalls, packet filters, or network address translation (NAT) systems are used, you must configure them as necessary so that the UDP packets can reach the target probe.
Create a new QoS sensor on a probe device, or, if you use the QoS (Quality of Service) Round Trip sensor, on any device. With the settings for the number and for the size of the packets, you can configure the test data stream. 1,000 packets of 172 bytes each is a good start, but if your applications use larger packets, you might want to enter other values here. Try to configure the test streams with parameters similar to that of the UDP services you are using across this connection.
Wikipedia describes IP SLA as a feature included in the Cisco IOS Software that can allow administrators the ability to Analyze IP Service Levels for IP applications and services. IP SLA uses active traffic-monitoring technology to monitor continuous traffic on the network. This is a reliable method in measuring over head network performance. IP SLA is mostly used to monitor the sound quality of VoIP traffic.
If you have not done so already, add a device that represents the Cisco target device. Then create a new Cisco IP SLA sensor on this device.
This feature is only available in the more expensive Cisco devices. If you do not have IP SLA-capable routers and switches, you can still get similar information with QoS sensors (see above) that do not require any special hardware.
PRTG monitors the following parameters: Impairment Calculated Planning Impairment Factor (ICPIF), Mean Opinion Score (MOS), Average Jitter, Packets Lost, Packets Out of Sequence, Packets Late, Average Round Trip Time (RTT), Domain Name System (DNS) RTT, TCP RTT, Transaction RTT.
Two of these parameters are especially interesting for VoIP: MOS and ICPIF.
SNMP Cisco CBQoS Sensor
Cisco CBQoS provides information about QoS of Cisco network devices that support the Modular QoS Command-Line Interface (MQC). With Class Based QoS, you can obtain monitoring data that includes summary counts and rates by traffic class before and after the enforcement of QoS policies, according to Cisco's CBQoS Management Information Base (MIB) definition.
PRTG determines CBQoS data via SNMP. The corresponding sensor is available as of PRTG 13.x.5. CBQoS is available in Cisco IOS by default as of version 12.4(4)T.
To monitor CBQoS, add a device to PRTG for the Cisco target device. Then create a new SNMP Cisco CBQoS sensor on this device.
Class Map: statistical data about class maps, such as pre-policy and post-policy packets and sizes, drop packets and size, as well as no-buffer drop packets
Match Statement: statistical data about match statement specific information, such as pre-policy packets and size
Queueing: statistical data about queuing actions, such as current and maximum queue depth, drop packets, and drop size
You can select the desired CBQoS entries that you want to monitor while creating the sensor. The available entries are specified with their particular connections, their descriptions, and class types.
Voice over IP
For MOS measurements, Cisco conducted a panel test where a wide range of listeners judged the quality of voice samples sent using particular codecs, on a scale of 1 (poor quality) to 5 (excellent quality). The Cisco device calculates the corresponding value for the network connection based on network parameter measurements like jitter and packet loss.
The Cisco IP SLA sensor reads out the MOS directly from the Cisco device. For the QoS (Quality of Service) One Way sensor and the QoS (Quality of Service) Round Trip sensor, PRTG calculates the MOS by itself. For details, see the Knowledge Base: How does PRTG calculate the MOS score for QoS sensors?
The values and their meanings are:
MOS
Quality
Expected Quality Impairment
5
Excellent
Imperceptible
4
Good
Perceptible, but not annoying
3
Fair
Slightly annoying
2
Poor
Annoying
1
Bad
Very annoying
The second interesting parameter ICPIF. is the sum of measured impairment factors minus a user-defined access Advantage Factor that is intended to represent the user's expectations, based on how the call was placed (for example, a mobile call versus a land-line call) (quoted from the Cisco website).
Upper Limit for ICPIF
VoIP Call Communication Quality
5
Very good
10
Good
20
Adequate
30
Limiting case
45
Exceptional limiting case
55
Customers likely to react strongly (complaints, change of network operator)
More
KNOWLEDGE BASE
How can I monitor QoS round trips without using remote probes?