Technology Metrics You Can't Ignore

Updated: August 20, 2012

There's an old saying that what you want to improve , you first must measure . Network performance can always stand improvement to reduce costs , increase productivity and postpone expensive hardware upgrades . Here are some of the most important network-performance metrics, what they mean, how they can be measured and how to improve them.

A framework for network-performance metrics has been codified in the IETF's (Internet Engineering Task Force) IPPM (IP Performance Metrics) Working Group . Detailed definitions of these and other performance metrics can be found on the RFC (Request for Comments) page.

One-Way Delay

OWD (one-way delay) is the time it takes for each packet to reach its destination. See the IPPM definition of OWD in RFC 2679 .

The link-specific portion of OWD consists of two subcomponents:

• Propagation delay: The time it takes a packet to travel from one sending end of the link to the receiving end. On simple links, propagation delay is the product of the link's physical length and the medium's propagation speed. Propagation speeds for copper and fiber optic links are about the same, roughly two-thirds of the speed of light.

• Serialization delay: The time it takes for a packet to be converted into serial transmission units (i. e., bits). It is the packet size multiplied by the link capacity in bits per second.

Some types of links may introduce addition delays to OWD, due to practices such as collision avoidance or retransmission of damaged packets.

Within a network node such as a router , a packet may experience forwarding delay — the time it takes for the node to read forwarding-related packet information. Queuing delay also occurs when a packet has to wait for an output port to become available.

OWD from point A to point B can be measured by sending time-stamped packets from point A to point B, and recording the receipt time at point B. The clocks at both points must be synchronized to a standard reference such as UTC (Universal Time Coordinated) using techniques such as NTP (Network Time Protocol).

Improving OWD is partly a matter of a good network design minimizing the physical distance that packets must travel. Node delays can be reduced by choosing nodes with fast-forwarding algorithms and sufficient capacity for peak data bursts to minimize queuing delays, and by decreasing the number of nodes in the network.

Round-Trip Time

RTT (round-trip time) is the OWD from point A to point B and back again, plus the time it takes for point B to respond. RTT is the lower bound for a packet to be acknowledged. For windows-based transport protocols such as TCP, RTT influences the maximum throughput that can be achieved. RTT also directly influences the responsiveness of interactive applications such as audio and video transmissions.

RTT is often measured with tools such ping and fping , which send ICMP (Internet Control Message Protocol) Echo requests to a destination and measure the time it takes to get a response.

The same techniques used to improve OWD work for RTT. Also, increasing the processing power of the receiving node improves RTT, as does optimizing point B's responding software.

Jitter

Jitter describes the difference between actual packet arrival times and theoretical arrival times based upon ideal circumstances. Sources of jitter include contention between multiple streams of packets (traffic congestion) and contention for processing resources on network nodes.

Jitter can be measured using the same tools used to measure OWD. It is particularly important in real-time applications such as audio- and video-conferencing systems. Such systems usually employ a jitter buffer to minimize jitter's adverse effects. Packets are held in a jitter buffer until it is their turn to be played out, smoothing the jitter effect and keeping delay constant.

Packet Loss

Packet loss is the probability that a packet will be lost in transit from source to destination. There are two main ways by which packets get lost:

• Congestion: Packets are held in nodes' buffers when traffic is high, and these buffers have finite capacity. When a buffer gets full, some packets must be dropped or erased. Buffer overflow may be a chronic problem on an underprovisioned network, or an occasional problem that arises only during peak traffic times.

• Errors: Packets may become corrupted during transmission due to noisy lines or other defects. Such corrupted packets are usually detected at the receiving end by a checksum algorithm, which then discards corrupted packets.

Lost packets require retransmission, which degrades effective throughput. In real-time applications, retransmission makes no sense because retransmitted audio or video packets would arrive out of order. Corrupted packets are therefore discarded, and the result is loss of information at the receiving end — with static in sound or video presentations.

Packet loss can be measured by sending a set of packets to a destination and measuring the percentage of packets that are lost during transmission. Routers and other network nodes also contain counters which keep track of dropped packets.

Congestion-induced packet loss can be minimized by upgrading network nodes' buffers to accommodate peak traffic. Large buffers, however, can degrade OWD and RTT.

QoS (quality of service) tools such as DiffServ or IntServ can protect some subsets of traffic against packet loss, but only at the expense of increased packet loss for other subsets of traffic.

Packet Reordering

IP does not guarantee that packets will arrive in the same order in which they were sent. Out-of-order packets may occur because packets take different routes across the network, or because larger packets are overtaken by smaller ones.

Reordering can have severe impacts on networks that do not use a transport protocol such as TCP or STCP. Recent TCP implementations, such as SACK (Selective Acknowledgments), enable robust performance even in the face of reordering.

Packet reordering can be measured by sending a stream of packets and comparing their orders at sending and receiving ends. Two methods of quantifying packet reordering is described in RFCs 4737 and 5236 .

Packet reordering can be minimized by reducing parallelism in networks, or by using network nodes that keep packets belonging to the same stream on the same path.

Tools for Measuring Performance Metrics

There are a great many software suites that measure these and other performance metrics. Most can display performance metrics in baseline and actual measurement graphs, making it easier to compare real-time to long-term performance. Some of these suites are offered by Hyperic Inc. , GroundWork Open Source , Zenoss Inc. , Likewise and Qlusters Inc . Many are open-source software, free to download. Some offer enhanced support and features at additional charge.