Why You Need to Measure Delay, Jitter and Packet Loss on Data Networks

Why You Need to Measure Delay, Jitter and Packet Loss on Data Networks

With the emergence of new applications such as voice and video on data networks, it is becoming increasingly important for network managers to accurately predict the impact of these new applications on the network. Not long ago, you could allocate bandwidth to applications and allow them to adapt to the bursty nature of traffic flows. Unfortunately, that’s no longer true because today applications such as voice and video are more susceptible to changes in the transmission characteristics of data networks. Therefore, network managers must be completely aware of network characteristics such as delay, jitter, and packet loss, and how these characteristics affect applications.

Why You Need to Measure Delay, Jitter and Packet Loss

To meet today’s business priorities and ensure user satisfaction and usage, IT groups and service providers are moving toward availability and performance commitments by IP application service levels or IP service-level agreements (SLAs).

Prior to deploying an IP service, network managers must first determine how well the network is working, second, deploy the service, such as voice over IP (VoIP), and finally, verify that the service levels are working correctly—which is required to optimize the service deployment. IP SLAs can help meet life-cycle requirements for managing IP services. To ensure the successful implementation of VoIP applications, you first need to understand current traffic characteristics of the network. Measuring jitter, delay, and packet loss and verifying classes of
service (CoS) before deployment of new applications can aid in the correct redesign and configuration of traffic prioritization and buffering parameters in data network equipment.

This article discusses methods for measuring delay, jitter, and packet loss on data networks using features in the Cisco IOS® Software and Cisco routers.

Delay is the time it takes voice to travel from one point to another in the network. You can measure delay in one direction or round trip. One-way delay calculations require added infrastructure such as Network Time Protocol (NTP) and clock synchronization and reference clocks. NTP is deployed to synchronize router clocks and also when global positioning system (GPS) or another trusted reference time is needed in the network. Accuracy of clocks and clock drift affect the accuracy of one-way delay measurements. VoIP can typically tolerate delays of up to approximately 150 ms one way before the quality of a call is unacceptable to most users.

Jitter is the variation in delay over time from point to point. If the delay of transmissions varies too widely in a VoIP call, the call quality is greatly degraded. The
amount of jitter that is tolerable on the network is affected by the depth of jitter buffer on the network equipment in the voice path. When more jitter buffer is available, the network is more able to reduce the effects of the jitter for the benefit of users, but a buffer that is too big increases the overall gap between two packets. One-way jitter measurement is possible and does not require clock synchronization between the measurement routers.

Packet loss severely degrades voice applications and occurs when packets along the data path are lost. Measuring Network Performance Key capabilities in the Cisco IOS Software can help
you determine baseline values for VoIP application performance on the data network. The ability to gather data in real time and on demand makes it feasible for IT groups and service providers to create or verify SLAs for IP applications; baseline values can then be used to substantiate an IP SLA for VoIP.

Cisco IOS Service Assurance Agent (SAA) technology is a component of an IP SLA solution and the Round Trip Time Monitor (RTTMON) MIB, which enable the testing and collection of delay, jitter, and packet loss measurement statistics. Active monitoring with traffic generation is used for edge-to-edge measurements in the network to monitor the network
performance. You can use the CiscoWorks Internetwork Performance Monitor (IPM) network management

Is Your Network Ready for Voice?

Measuring Delay, Jitter, and Packet Loss for Voice-Enabled Data Networks Your success or failure in deploying new voice technologies will depend greatly on your ability to understand the traffic characteristics of the network and then applying your knowledge to engineer the appropriate network configurations to control those characteristics.

TECH TIPS & TRAINING

Application or the IOS command-line interface (CLI) to configure and retrieve data from the RTTMON MIB, or choose from a wide selection of Cisco ecosystem partners and public domain software to configure and retrieve the data. In addition, the CiscoWorks IPM features are now also available in the WAN Performance Utility (WPU) module of CiscoWorks IP Telephony Environment Monitor (ITEM) network management software.

Deploying Delay/Jitter Agent Routers

You can measure delay, jitter, and packet loss by deploying almost any Cisco IOS device, from a
Cisco 800 Series Router on up. Two deployment scenarios are possible: You can either purchase dedicated routers for SLA measurements or use current routers within the network. Place the routers in a campus network along with hosts to provide statistics for end-to-end connections.
It is not practical to measure every possible voice path in the network, so place the dedicated routers in typical host locations to provide a statistical sampling of typical voice paths.
In the case of VoIP deployments using traditional phones connected to Cisco routers using FXS station ports, the router to which the phones are connected also serves as the delay/jitter measurement device. Once deployed, the operation collects statistics and populates Simple Network Management Protocol (SNMP) MIB tables in the probe router. You can then access the data either through the CiscoWorks IPM, or through simple SNMP polling tools and other third-party applications. Additionally, after baseline values have been established, you can configure operations to send alerts to a network management system (NMS) station if thresholds
for delay, jitter, and packet loss are exceeded.

Simulating a Voice Call

One of the strengths of using Cisco IOS SAA as the testing mechanism is that you can simulate a voice call. In Cisco IOS Software Release 12.3(4)T and later, you can configure the VoIP codec directly in the CLI and simulate a voice call. This release also includes voice quality estimates, Mean Opinion Scores (MOS), and Planning Impairment Factor (PIF) scores. Earlier versions of the Cisco IOS Software enable you to estimate a VoIP codec using the correct packet size, spacing, and interval for the measurement data and enter the appropriate parameters.

The CoS can be set on data or VoIP tests, which allows you to verify how well QoS is working in the network. Examples of how to simulate a voice call are shown below.

With Cisco IOS Software Release 12.3(4)T or later, you can use the VoIP jitter operation to simulate a test call:

rtr 1
type jitter dest-ipaddr 10.1.1.2 dest-port 14384 codec g711alaw
rtr schedule 1 start-time now

With earlier IOS releases before 12.3(4)T you can use the rtp/udp even port numbers in the range of 16384 to 32766. The user then approximates 64 kbit/s, and the packet size is 200 bytes {(160 bytes of payload + 40 bytes for IP/UDP/RTP (uncompressed) }. You can simulate that type of traffic by setting up the jitter operation as shown below.

The jitter operation accomplishes the following:

• Send the request to rtp/udp port number 14384
• Send 172 byte packets (160 payload + 12 byte RTP header size) + 28 bytes (IP + UDP)
• Send 3000 packets for each frequency cycle
• Send every packet 20 milliseconds apart for a duration of 60 seconds and sleep 10 seconds before starting the next frequency cycle

The parameters in the example above give you 64 kbit/s for the 60-second test period.

((3000 datagrams * 160 bytes per datagram)/ 60 seconds))* 8 bits per byte = 64 kbit/s

The configuration on the router would look like this:

rtr 1
type jitter dest-ipaddr 10.1.1.2 dest-port 14384 numpackets 3000 request-data-size 172**
frequency 70
rtr schedule 1 start-time now

Note that IP+UDP is not considered in the requestdata-size, because the router internally adds them to the size automatically.

Delay/Jitter Probe Deployment Example

The two routers below would simulate voice calls of 64 kbit/s every 60 seconds and record delay, jitter, and packet loss in both directions. Note that the delay calculations are round-trip times and must be divided by two to arrive at the amount of one-way delay unless NTP is implemented for one-way delay measurements.

router1# rtr responder rtr 1 type jitter dest-ipaddr 10.1.2.1 dest-port 14384 codec g711alaw
tos 160 frequency 60 rtr schedule 1 start-time now

router2# rtr responder rtr 1 type jitter dest-ipaddr 10.1.1.1 dest-port 14385 codec g711alaw
tos 160 frequency 60 rtr schedule 1 start-time now

Command-Line Data Examples

To view the results you can use the IOS show command at the command line for the jitter operation. Additionally, you can use the command-line data for real-time monitoring and troubleshooting of delay, jitter, and packet loss. For an example of the CLI output, refer to cisco.com/packet/163_4b1.

Monitoring Thresholds

You can use the CLI, CiscoWorks IPM, or the WPU in CiscoWorks ITEM to configure features and monitor data. You can use this data to manage IP SLAs that have been created for VoIP. After you have determined baseline values, you can reconfigure the jitter operations to monitor the network. When predetermined delay and jitter service-level thresholds are reached or exceeded, NMS stations will be alerted.

After you have established baseline values through the initial data collection, you can monitor the delay, jitter, and packet loss levels in the network with the embedded alarm features of Cisco IOS SAA.

The Cisco IOS SAA threshold command sets the rising threshold (hysteresis) that generates a reaction event and stores history information for the operation. Cisco IOS SAA can measure and create thresholds for round-trip time delay, average jitter, connectivity loss, one-way packet loss, jitter, and delay.

Sample Service Assurance Threshold Configuration

router1# rtr 100 rtr reaction-configuration 100 threshold-falling 50 threshold-type immediate action trapOnly

Understanding the traffic characteristics of the network before you deploy new advanced applications is the key to successful implementations. Delay, jitter, and packet loss greatly affect VoIP applications. Your success or failure in deploying new voice technologies will depend greatly on your ability to understand the traffic characteristics of the network and then applying your knowledge to engineer the appropriate network configurations to control
those characteristics.

---Do you want to share you views?? Just leave a comment here. you can also drop an email on mail@amarjit.info