Test metric tackles IPTV
By Richard A. Quinnell, Contributing Technical Editor -- Test & Measurement World, 10/1/2006
Originally designed as a file-sharing mechanism, the Internet Protocol (IP) has adapted to handle a wide variety of media. The latest market demand calls for the Internet to support on-demand video and television services (IPTV), posing significant challenges for test engineers who must evaluate the performance of networks and network equipment. To provide insight into the Internet’s ability to handle video, the industry has developed a new metric: the Media Delivery Index (MDI).
Two major factors combine to make video traffic a challenge for an IP network. The first is its bandwidth demand. A single video stream requires an average bandwidth of several megabits per second in order to provide the image quality that consumers expect. To be commercially viable, IPTV systems must be able to support hundreds to thousands of these streams simultaneously.
The second factor is the complexity of the video data stream. Video compression algorithms remove both spatial and temporal redundancy, resulting in a data stream that can be very sensitive to minor errors. Unlike audio, where errors do little more than create a brief noise glitch, a data error in a compressed video stream can affect many frames in the reconstructed image.
 |
|
The MDI metric seeks to characterize timing problems that interfere with reliable IP television delivery, such as jitter and out-of-sequence packet delivery, that are caused by the use of buffer queues at network nodes. Courtesy of IneoQuest Technologies. |
The combination of these factors results in a data stream that is both demanding and relatively intolerant of dropped or delayed packets. The key to avoiding such packet problems is to provide buffering queues at each router and switch in the network (figure) to smooth the instantaneous bandwidth demands into a sustainable average demand. The buffers hold the packets for a small amount of time, and network Quality of Service (QoS) policies dictate how packets are removed from the queues and sent out over the network.Queues create problems
Unfortunately, queues are finite resources and can easily fill, even if the downstream bandwidth is more than adequate to handle the incoming data. If too many packets arrive simultaneously at a router, for instance, its queue may fill even if the interpacket spacing is wide enough to allow the queue to empty between bursts. If the queue is large enough to hold such simultaneous arrivals, then the packets passing through it can suffer significant delays as they wait for the queue to empty. Further, the outgoing packets will become clumped into bursts, which can cause overflows at the next node’s queue.
The delays caused by using large queues can also result in out-of-sequence packet arrivals at the destination when successive packets take differing paths through the network. The video decoder at the destination can re-sequence packets by holding packets in its own internal queue to await late arrivals, but that queue also has its limits. If that queue empties to the point where the late packet should have been placed, that late packet will be dropped. If the decoder makes no attempt to re-sequence packets, then it drops all out-of-sequence packets.
The keys to providing reliable video data streams, then, are to control the “burstiness” and the delays of packets through the network. Unfortunately, traditional network metrics such as the real-time protocol (RTP) provide only average values for jitter (the variation in packet delivery times) and packet loss rate. They do not provide enough insight into where and how problems occur.
MDI measures network performanceTo address this need for greater insight, Cisco Systems and IneoQuest Technologies have proposed to the Internet Engineering Task Force (IETF) the Media Delivery Index (MDI) metric, published in April 2006 as IETF RFC 4445 (Ref. 1). The MDI has two components: the Delay Factor (DF) and the Media Loss Rate (MLR), expressed as the number DF:MDR. These measurements may be made for each video data stream at any point in the network, and they provide an indicator of the network’s effectiveness at handling real-time streaming data at that point for a given video decoder.
The Delay Factor (DF) measures the imbalance between the rate of video data arrival at a node and the nominal departure rate (the drain rate) over some specified interval. At each packet arrival, the metric calculates the virtual buffer depth being used. After the desired measurement time interval, the metric then takes the difference between the minimum and maximum virtual buffer depths and divides that by the drain rate. The result is an indicator of how long, in milliseconds, the data must be buffered at that node in order to prevent packet loss. The DF also gives a hint of the minimum buffer size that will be needed at the next downstream node.
The MLR is simply a measure of the number of lost—and in some cases out-of-sequence—video data packets per second at the node. It is a convenient format for specifying the packet loss rate at that point in the system. Out-of-sequence packets are counted as losses if the system’s video decoder does not provide packet re-sequencing.
Use MDI for evaluationTaken together, the two MDI values provide useful insights into what is happening to a video data stream as it winds through the network. The Agilent Technologies white paper “Understanding MDI” points out that changes in the MLR value from one node to the next may be a sign of packet corruption or buffer overflows (Ref. 2). The paper notes that differences in the DF value between one node and another for a constant calculation interval can indicate local areas of traffic congestion or possibly misconfigured QoS flow specifications. These differences can provide an early warning of impending packet loss.
The MDI value can also be used to evaluate individual nodes, according to IneoQuest Technologies president Mark Todd. Comparing the DF at the input to a node to the DF at the output, Todd said, gives the node’s “footprint”—an indication of how much jitter the node injects into the data stream. He added that nodes with a smaller footprint are better suited to delivering video.
Because of video’s sensitivity to packet loss and jitter, the MDI values thus obtained provide a useful real-time monitor of delivered video quality. It is not a perfect monitor, though. As Spirent Communications points out in its white paper “MPQM versus Media Delivery Index,” the perceived video quality at the receiving end strongly depends on which packets have been lost (Ref. 3). Thus, the MDI value may report video stream problems that the user cannot see. To obtain a measure of perceived video quality, a metric such as the MPQM (Moving Pictures Quality Metric) may be necessary.
The MDI metric has the advantage, Todd explained, in that it is relatively easy to calculate compared to the MPQM, which requires significant computational resources to return a value. MDI can be readily scaled to monitor hundreds of video streams simultaneously as an indicator of network performance, and it promises to provide a useful tool for the real-time monitoring and troubleshooting of an entire IPTV system.
The MDI metric is only a proposal, not a standard, but it already has support within the industry. IneoQuest Technologies, for example, offers the Singulus GT1 network tap and the IQMediaMonitor and IQMediaAnalyzer tools for collecting and interpreting MDI metrics from network nodes. Tektronix has reported integrating the Singulus GT1 with its MTM 400 MPEG transport stream monitor to evaluate systems using the MDI metric. Agilent Technologies also supports the concept, incorporating MDI measurement into its N2X test platforms.
As the demand for IP video grows, metrics such as MDI will become increasingly important to service providers as well as to equipment developers. Using such measurements along with test methodologies that exercise IPTV devices and routers under realistic deployment conditions will help test engineers unravel the mystery of IP video flow and lead to better systems and greater end-user satisfaction.
| References |
|
