Supporting Quality of Service for Internet Multimedia Applications

Supporting Quality of Service for Internet Multimedia Applications

Yew-Hock Ang
DOI: 10.4018/978-1-60566-026-4.ch577
(Individual Chapters)
No Current Special Offers


The Internet has gone from near-invisibility to near-ubiquity and penetrated into every aspect of society in the past decades (Department of Commerce, 1998). The application scenarios have also changed dramatically, and now demand a more sophisticated service model from the network. In the early 1990s, there was a large-scale experiment in sending digitized voice and video across the Internet through a packetswitched infrastructure (Braden, Clark, & Shenker, 1994). These highly-visible experiments have depended upon three enabling technologies: (1) Many modern workstations now come equipped with built-in multimedia hardware, (2) IP multicasting, which was not yet generally available in commercial routers, and (3) Highly-sophisticated digital audio and video applications have been developed. It became clear from these experiments that an important technical element of the Internet is still missing: multimedia, which dominate increasing proportion of today’s data traffic, are not well supported on the Internet.
Chapter Preview

Principles For Supporting Multimedia Qos

To support multimedia applications, the Internet service models must address the issue of quality of service that relates to the characteristics of multimedia data. These data characteristics are: (a) media type, (b) data synchrony, and (c) data persistency. The media type identifies the multimedia as one of image, video, audio, or text. Network services should be aware of different error susceptibilities of media types. For example, video data are handled by a QoS-aware network with a higher packet loss rate or treated with higher drop precedence than for error-sensitive audio data. Data synchrony defines the temporal synchronization of real-time data, such as interframe delay in video streams. A QoS-aware network must forward real-time data packets with higher priority than for non real-time data packets. Data persistency describes the transient nature of “live” data. Live data are not stored or buffered at its source; hence they are nonpersistent and are not retransmitted when received in error.

To be sensitive to QoS requirements of multimedia applications, a QoS-aware network must be designed according to the following four service principles and implemented with a corresponding set of traffic management/handling mechanisms:

Key Terms in this Chapter

MPLS Label: A label which is carried in a packet header, and which represents the packet’s FEC.

Multifield: IP header multifield defines the 5-tuplet fields in the IP header, comprising of the source and destination addresses, source and destination port numbers, and the protocol type.

Token Bucket: A particular form of traffic specification consisting of a “token rate” r and a “bucket size” b. Essentially, the r parameter specifies the continually sustainable data rate, while the b parameter specifies the extent to which the data rate can exceed the sustainable level for short periods of time.

TSpec: Traffic Specification containing descriptions of traffic characteristic such as packet arrival peak rate and burst rate.

RSVP: The Internet standard protocol: Resource ReSerVation Protocol (RSVP).

RSpec: A Service Request Specification is a specification of the quality of service a flow desires from a network element. The service request specification is highly specific to a particular service; for example, it might contain information about bandwidth allocated to the flow, maximum delays, or packet loss rate.

Service Level Agreement (SLA): A service contract between a customer and a service provider that specifies the forwarding service a customer should receive.

Label Switched Path (LSP): The path through one or more LSRs at one level of the hierarchy followed by a packets in a particular FEC.

QoS: Quality of service refers to the suitability of a packet delivery service for the needs of a particular application, as defined by parameters such as achieved bandwidth, packet delay, and packet loss rates.

Per-Hop-Behavior (PHB): The externally observable forwarding behavior applied at a DS-compliant node to a DS behavior aggregate.

DSCP: A specific value of the DiffServ codepoint portion of DS field (same as in IPv4 header TOS field or the IPv6 Traffic Class field) used to select a PHB.

Traffic Conditioning Agreement (TCA): An agreement specifying classifier rules and any corresponding traffic profiles and metering, marking, discarding or shaping rules which are to apply to the traffic streams.

Complete Chapter List

Search this Book: