Overview

The provisioning of multimedia data over the best-effort Internet still remains a challenging service scenario. Peer-to-peer file sharing applications such as Gnutella, Kazaa, Chord, and Pastry have addressed the issue of storing large amounts of (mainly multimedia) data in a largely decentralized way also trying to provide online content preview facilities for downloaded data, e.g. Kazaa. These solutions have further increased the widened interest in multimedia data sharing over the Internet, up to the current scenarios where these applications produce most Internet traffic. The problem is more complex for Video on Demand (VoD) streaming applications with near real-time requirements. In fact, high latency and loss rates of the best-effort Internet make it difficult to stream video without introducing large playback delays.

MUM proposes an application layer approach to QoS management. In particular, we do not make any strong assumption about the mechanisms available at transport and network layer, rather the infrastructure hides these details at the application level and does its best to honor Service Level Agreements (SLA). If any QoS oriented architecture is present at lower layers, e.g. Internet IntServ or DiffServ, MUM exploits it, otherwise in most common situations it manages the resources at the application layer by adopting:

1. Dual preemptive-reactive approach: the actual best-effort Internet architecture requires infrastructures capable not only of resource booking at service configuration time, but also of monitoring and adjusting service provisioning at runtime.
2. Application dependent-independent approach: the infrastructure should be both system- and application-aware, i.e. capable of gathering all possible QoS-related information both from underling operating system and network levels and from application specific components (such as Real Time Control Protocol).

Architecture

The architecture following the MUM approach is layered in two levels, see MUM overview. At the mechanisms layer there are Resource Monitors and Brokers, at the facilities layer there is the Resource Manager that encapsulates monitoring strategies to emit at the application layer meaningful warnings about actual resource conditions. Finally, at the application layer, i.e. atop the facilities layer we developed the QoS Manager. More information about single components are given in the next section.

Design and Implementation

Design

The architecture is based on four main components:

• the Resource Broker;
• the Monitor;
• the Resource Manager;
• the QoS Manager.

The Resource Broker is an application level resource broker that let you negotiate and book the desired resources for all those applications running atop our middleware infrastructure. Naturally, other applications, that access directly system resources may interfere with MUM-based ones, therefore acting at the middleware layer we try to achieve best possible results, although it is not possible to have certain behavior as our middleware runs atop actual Internet best-effort architecture. There is one resource broker per resource and per node.
All above issues motivated the introduction of Monitor components. These components get information about actual QoS conditions both by monitoring system resources and by gathering application specific QoS feedbacks. For instance, in a VoD service you may employ two system condition monitors to monitor actual bandwidth and CPU availability while use an application specific monitor to obtain a feedback about actual transmission condition by using specific application-level protocols such as RealTime Control Protocol (RTCP). There is one resource monitor per resource and per node, while one application monitor per application component.
The Resource Manager combines node monitoring information and emits warnings to registered applications. There is one resource manager per node.
The QoS manager combines resource manager warnings and application-dependent monitoring information, and triggers service reconfiguration when needed. Naturally this component is service specific and there is one QoS manager per service.

Implementation Hints

The monitoring information are gathered by using standard solutions, e.g. we actually use Simple Network Management Protocol (SNMP) and RTP/RTCP to get resource usage and application level feedbacks by interrogating single nodes and the employed multimedia transmission library, i.e. Sun Java Media Framework (JMF).