Quality of Service

Quality of Service, or QoS, can be expressed using four groups of parameters [42]: Media Parameters represent the characteristics of the data being transferred.

Quantitative characteristics include the type of media (e.g. live audio, or still video) and the media format (e.g. MPEG-1, MJPEG). Qualitative

Conference Management Conference

Setup and Discovery SDP Conference Course Control SAP SIP HTTP SMTP RTSP RSVP Media Agents Audio and Video Shared Applications Distributed Control RTP and RTCP Reliable Multicast UDP UDP TCP UDP IP and IP Multicast

Integrated and Differentiated Services (QoS) Forwarding

Figure 2.2: Internet multimedia protocol stacks

(from [83])

characteristics represent the quality of a particular media, such as resolution, speed and colour depth for video.

Delivery Parameters or real-time performance requirements, include start time, end time, packet delay and delay-jitter.

Value Parameters attach a cost to a delivery based upon the expense of reserving resources, transfer and delivery of data and the cost of producing the media. Such costs are determined on a per-session basis and likely to vary through time as supply and demand bandwidth levels are balanced. Attaching a value helps regulate over-subscription to services; if there were no cost there would be no rationale to choose anything but the highest level of service.

Fault-Tolerance Parameters define different classes of service commitment, each of which can deliver traffic with a specified reliability and timeliness. While initial research provided QoS at specific layers of the network stack, there have since been many proposals for both specific and generic QoS architectures [12][80] which provide a complete framework for enabling QoS. When used for distributed multimedia, it is important that an architecture provides end-to-end guarantees, where it is the architecture which manages the QoS issues from application to application [12].

The Internet has traditionally provided best-effort delivery of data, in that there is no guarantee that any particular packet will arrive at a destination in order and in a timely manner, if at all. On a part of the network which is not

congested, data packets will not become queued at routing nodes along the link, packets will not be lost, and delays will be minimal. But multimedia data is often large, and when transfered over the network leads to congestion resulting in packet loss and delay, the very things real-time traffic are vulnerable to.

For such distributed multimedia, a better-than-best-effort service is required [83] which must be supported at all nodes along the route across the Internet. While no such scheme has yet been deployed on an Internet-wide scale, there are two main QoS proposals which deal with the problem in two different manners: Integrated Services - The Intserv architecture [32] is based on the idea of

marking each packet from a particular flow of data from application to application with a flow label, which routers can use to identify it. Each routing element is QoS aware and can offer various levels of service above best-effort: controlled delay, predicted delay, and guaranteed delay. Within this framework a reservation protocol, RSVP [33][145], is used to set up resources across the network. For a particular application (marked by its flow label) RSVP attempts to traverse the network requesting the required level of service from each routing node, repeating the traversal with

different requests until the destination is successfully reached. Each node is then honoured to reserve that level of service for the duration of that particular flow, and this requires routers to support complex state tables for each flow they handle. Due to this complexity, and the need for every node along the route to fully implement the architecture, Intserv and RSVP are not widely deployed across the Internet, although a flow label field exists in the header for the next generation Internet Protocol, IPv6 [54].

Differentiated Services - The Diffserv architecture [25] instead defines a relatively small number of traffic classes. Within the diffserv network routers then prioritise packets of higher classes to an agreed level of service,

so an application need merely request a particular traffic class. This leads to simpler routers which only examine the class of packet, rather than maintain knowledge of individual flows. Separate diffserv sub-networks can be managed with different internal QoS and billing policies, but at the junction with other networks packets can still easily be transferred by mapping to the traffic classes. Again, a traffic class field is present in the header for IPv6 [54].

While QoS architectures are essential in delivering distributed real-time

multimedia, it is important to remember that QoS needs not only to be met in measurable objective parameters, but also in terms of a user’s subjective

requirements [80]. Users’ needs must be translated into technical parameters [42] and the QoS measured in relation to a user’s perception [72]. There is a complex relationship between perception and understanding; for example, a user may overlook a poor quality (e.g. through low frame rate) element of a multimedia presentation if the conceptual core of the presentation remains intact.