You are here: Home Page » Magazine Articles » Guaranteeing quality

Guaranteeing quality

Nov 1, 2004 12:00 PM, BY BRAD GILMER

Figure 1. Carriers and vendors can use IP delay variation, IP loss distance and IP error rate to measure QoS for professional video transmission. Click here to see an enlarged diagram.

I have some bad news: The Internet is unreliable. It isn't just unreliable, it was designed to be that way. Internet Protocol (IP), the fundamental datagram transport protocol on the Internet, makes no guarantee that the information you send will ever get to its destination. Not only that, User Datagram Protocol (UDP), which carries quite a bit of Internet traffic (including many video applications), is also unreliable. Even Transmission Control Protocol (TCP) — which is supposed to take care of packets that are dropped, out of sequence or duplicated — is undependable. You might wonder how we have managed to get by all these years using this “best effort” method of delivery. The answer is that it's been good enough so far.

But, somewhere along the way, people began relying on the Internet to do things it was never intended to do reliably.

VoIP and professional video streaming have made the issue of quality of service (QoS) one of the top technical issues for service providers. A lot of good work has been done, and we are starting to see QoS solutions being deployed in the marketplace.

Several technical forums and standards bodies have been looking at the issue of QoS over wide-area networks (WANs). The ITU has developed a standard (ITU-T Recommendation Y.1541), that specifies a number of classes of service based on the needs of different applications. The Video Services Forum (VSF) has been working on establishing a set of QoS parameters focused on transporting real-time professional video across WANs. This work is based, in part, on the findings of the Pro-MPEG Forum's WAN group. Use the following parameters to establish QoS for professional video transmission over WANs.

Delay or latency (IPTD): Measures how long it takes packets to cross the network one way (transfer delay). The VSF recommends a maximum of 100ms of IPTD for professional video WAN applications.
Delay variation or jitter (IPDV): Measures difference in arrival time between packets. The VSF recommends a maximum of 50ms.
Loss distance (IPLD): Measures the minimum number of packets between lost packets. This is a critical recommendation for determining the characteristics of any error-correction schemes that may be employed. The VSF recommends a minimum of 50, based on Internet Engineering Task Force (IETF) 3357 and the Pro-MPEG Forum Code of Practice number 3.
Loss period (IPLP): Measures the number of consecutive packets lost in a row. This is another critical recommendation for determining the characteristics of any error-correction schemes that may be employed. The VSF recommends a maximum of five, based on IETF 3357 and the Pro-MPEG Forum Code of Practice number 3.
Packet corruption (IPER): Measures the error rate — the number of packets received that have errors over a given period of time. The VSF recommends a maximum of 1 × 10^-4 per ITU-T Y.1541 Class 0.
Packet loss (IPLR): Measures the ratio of lost packets to received packets over a given period of time. The VSF recommends a maximum of 1 × 10^-3 per ITU-T Y.1541 Class 0.
Spurious packet (SIPR): Measures packets received for which a corresponding transmitting packet was not created. The VSF recommends a maximum of 1 × 10^-3 spurious packets per second.
Availability: Measures uptime, expressed as network events per hour. There has been a lot of discussion regarding this parameter. Ultimately, availability translates into service-level agreements (contracts) between WAN service providers and their customers. The VSF has said that useful service quality categories for professional video with delivered bit rates from 1- to 400Mb/s would be: <.003 network event per hour, <.01 network event per hour, <.1 network event per hour and <1 network event per hour.

Figure 2. Concepts such as IP loss ratio, spurious packets and availability are also useful in determining the quality of service a network provides. Click here to see an enlarged diagram.

A network event is defined as a single occurrence of packet(s) loss in the network.

While work is ongoing, it is encouraging that the industry is reaching a consensus regarding the parameters and measurements that should be used to establish QoS for delivery of video over WANs.

Given a set of parameters, network engineers need a technical framework within which they can implement a given QoS. While exact details of QoS frameworks vary, these frameworks share some common elements:

Signaling and admission control: Controls the amount of traffic that is allowed to enter the network.
Shaping: Provides a way to smooth out the bursty nature of traffic.
Policing: Involves enforcing policies and dropping traffic from the network if it does not conform to rules established to guarantee the QoS on the network.
Routing: Allows the network designer to establish routes that will guarantee a particular level of QoS and then mark packets so that they are sent across those routes.
Scheduling: Used to ensure that high-priority traffic is passed through the network correctly while still allowing “mouse traffic” such as e-mail to get through.
Buffer management: Provides techniques for metering traffic as it passes through routers on the Internet, keeping routes uncongested, and provides techniques for dropping low-priority traffic when buffers are in danger of being overloaded.
Traffic monitoring and feedback: Provides network engineers with a way to monitor network activity.

While it is true that the core Internet may be unreliable, it's evident that several groups have done significant work to establish techniques, measurements and frameworks to establish the quality of service necessary to deliver real-time video over IP.

Brad Gilmer is the executive director of the Video Services Forum, executive director of the AAF Association, and president of Gilmer & Associates.

Send questions and comments to: brad_gilmer@primediabusiness.com