Quality of Service in IN-home digital networks Alina Albu 7 November 2003

Contents Presentation: “ Cooperative Run-time Management of Adaptive Applications and Distributed Resources ” ACM MM 2002

Definitions Local resource management: ensures the allocation of local resources according to an application’s requirements, Global resource management: ensures that resources are allocated along the entire path of a distributed application’s data communications, Application adaptation: enables an application to better deal with resource limitations and with unforeseen variations in resource availabilities.

Problem statement Cooperative run-time management aims to combine the local and global management of distributed resources with the run-time adaptation of an application.

Solution approach, Q-fabric Q-fabric = a Linux kernel-level service with which multiple distributed resource managers and an application’s adaptations can be dynamically integrated into a single QoS control path. Integration is dynamic in that applications and resource managers can choose to join or leave such co-operations at any time. This is achieved by using Q-channels as the fabric’s control infrastructure, which is a kernel-level event service that follows the publish/subscribe paradigm. With Q-channels, applications and resources are managed via the exchange of monitoring and steering events.

Solution approach, Q-fabric Specifically: (a) resource managers exchange events within a host and between hosts to monitor resource availability and to coordinate the allocation of resources to applications. (b) Applications use the same event path for their control communications (i.e., for adaptation), as exemplified by a video server announcing the use of a different encoding scheme to its clients. (c) Finally, applications and resource managers communicate with each other via events to exchange monitoring information or to request adaptations in resource allocations or in application behavior. Event-based communications.In all such actions, the only interface between all communicating entities is that of an pair, i.e., resource managers and applications submit well-defined events and react to the arrival of an event with a certain well-defined action.

Q-channels, Events Note that a Q-channel is not a centralized unit, but is distributed among all participating hosts, i.e., all hosts communicate directly with each other (e.g., via socket connections) and channel information (e.g., lists of participating publishers and subscribers) is replicated at each host. The Q-fabric’s operations are based on the exchange of events, which trigger the execution of some action (e.g., monitoring, adaptation, etc.). Event exchange is anonymous, so that local and remote resource managers and applications can interact freely, without having to be aware of each others locations or of the number of applications or resource managers involved. In this way, Q-fabric addresses the highly heterogeneous and dynamic computing platforms on which future multimedia applications will run. The events interchanged via the Q-fabric coupling distributed entities are variable-length data structures. New events can be defined at run-time – by applications and resource managers – using an event registry (not yet implemented). Events (represented by pairs) have the following effect: a source submits an event, which is received by one or more event sinks. An event sink executes the corresponding action, that is, function, in response to the event.

How it works Consider the scenario of one or more resource managers embedded in the Linux kernel (for resources such as CPUs, network connections, disks) and a number of applications sharing these resources. Cooperation implies not only that applications need a way to specify their resource needs, but also, that they can customize the resource management to their specific requirements, monitor their resource allocations, and control both the adaptation of such resource management and of their own implementations. The Q-fabric is implemented to provide appropriate ‘connections’ across all cooperating entities, including the resource managers and the applications on all participating hosts. Specifically, applications specify their QoS requirements via events, which are received by the underlying resource managers at all participating hosts. If admission control succeeds, resources are allocated to the application. During operation, resource managers again use events to monitor the achieved quality of service and adjust their resource allocations. At the same time, applications monitor the achieved quality of service and adapt themselves or request different resource allocations from the resource managers.

Cooperation via Q-channels Event communication is performed via Q-channels, which connect resource managers and applications with the purpose of exchanging control information. A Q-channel is created whenever an application initiates an interaction (i.e., initiates communication) with another application, such as a client requesting a service from a server. Applications share control information to ensure optimal performance or to adapt to heterogeneous system environments. On the other hand, resource manager cooperation is required to achieve end to end QoS management. This approach distinguishes itself from previous approaches by combining these two control paths into one: a kernel-based event channel connects kernel-based resource managers and user-level applications, allowing them to coordinate their resource management and adaptations.

Resource managers A resource manager’s task is to distribute one or more system resources among a number of competing applications according to some resource management policy. The figure below shows the structure of a resource manager. First, a monitor entity keeps track of changes in resource allocations and stores this information in a statistics data structure, and submits a monitoring event to the Q-channel. Second, an adaptor entity receives such monitoring events and uses these events together with the stored QoS requirements of applications and the statistics data structure to decide if: (a) local resource allocations should be adjusted and (b) remote resource allocations or applications require adaptation, that is, a quality event has to be issued.

Resource managers

Practical application of Q-fabric The multimedia applications addressed by Q-fabric are those that are subject to dynamic variations in underlying resources and in current user needs. Examples include adhoc-networked PDAs operating in dynamically changing contexts, and embedded computers in mobile platforms like cars and airplanes that interact to exchange time-critical information. The application studied in this paper is a videoconferencing tool (vic) operating on both handheld and desktop machines, connected via wireless and wired communication links. The QoS issue arising for this application is the control of the end to end delay of image transfer and the control of the jitter of image arrival and display at the client. The figure below shows the experimental setup used in this paper, with two machines running vic, where the first one is used as a video source (server-vic) and the second as a video sink (client-vic). Both hosts use a CPU resource manager (managing a round-robin scheduler), and the vic server also uses a network resource manager (managing a DWCS packet scheduler).

Practical application of Q-fabric

Resource management and application adaptations are based on pairs. Events are used to describe certain system states or significant occurrences. They distinguish between monitoring and quality events, where monitoring events are issued by monitor functions and carry system state such as current CPU load, network bandwidth, and average buffer lengths. This event is received and handled by the adaptor function that analyzes the received information, compares received QoS with desired QoS and possibly issues quality events. Quality events are intended for system adaptation: an adaptor function is invoked upon arrival of a quality event, which then decides how and where to adapt an application or to adjust resource allocations.

Conclusions The Q-fabric architecture addresses issues in cooperation in multiple ways: (a) it gives each application the ability to control the resource monitoring, management, and adaptations performed on its behalf. (b) these actions may be tuned continuously, by monitoring management effectiveness and altering management behavior through run-time modification of selected parameters. (c) all such actions are performed within a uniform framework that binds application and resource managers into a single integrated and distributed QoS management system. Main contribution of the Q-fabric is that it allows applications to directly interact with other applications as well with distributed resource managers, in order to cooperatively manage the quality of service experienced by end users.

Conclusions What problems does it solve? The issues addressed by Qfabric services concern the limitations experienced in current systems for cooperative resource management and application adaptation, which are due to: (a) the specific interfaces defined between applications and resource managers (b) the limited interactions permitted between distributed resource managers. (c) cooperation is particularly difficult when resource management actions are performed at kernel-level. (d) in large-scale multimedia applications, the coordination of a large number of distributed resource managers for heterogeneous resources and the adaptation of all instances of an application can be overwhelming in complexity.

Conclusions Earlier research principally considered adaptations performed at application- level. More recent contributions include multi-resource solutions, using libraries and/or additional servers for distributed adaptation and resource management. Cooperation between application-level adaptations and system-level resource management is implemented as middleware or as point solutions for specific resources like computer networks). Other work, such as OMEGA or QuO introduce general QoS architectures to address the end-to-end management of QoS.