Email -- schwan@cc.gatech.edu, eisen@cc.gatech.edu

This research addresses the problems created by the increased distribution and heterogeneity of the hardware/software platforms on which teams of researchers will conduct future scientific collaborations. The assumptions that drive this work are that on the one hand, it is difficult to constrain the future hardware and software systems such teams will use, especially given the diverse scientific tasks they will be carrying out, and that on the other hand, effective real-time collaboration demands that team members be able to interact with each other and with remote resources as if they were co-located. Two problems arise:

1. Heterogeneous underlying operating systems and software platforms create interoperability problems for the scientific simulations, their input data, and their outputs via which and their team members collaborate.
2. Heterogeneous underlying hardware and networks make it difficult to guarantee the timely transport of data and execution of software required for seamless remote collaboration.

While we are pursuing solutions to Problem 1 in other research, this funded effort focuses on innovative solutions to Problem 2, that is, the provision of Quality of Service support in middleware. Specifically, we will provide middleware-level functionality that permits end users and applications to move data with the timeliness they require, despite dynamic changes in underlying platform resources. To meet this goal, our specific focus will be the timely visualization of large-scale data on heterogeneous clients and across heterogeneous networks. For instance, it should be feasible for an end user operating via a DSL-connected home PC to collaborate with another end user operating on a lab-resident high end graphics machine directly connected to a cluster-based data server. Making this work requires more than just network-level QoS support; end users must either understand and explicitly manage their applications' communications, or the middleware they are using must provide such support.

The research we propose differs from previous work in our pursuit of an `open systems' approach for realizing QoS functionality for future high performance computing platforms. Specifically, our goal is to substantially enhance the support that middleware provides for runtime resource management. Toward this end, given that end users provide application-specific descriptions of their needs and the resource tradeoffs that are admissible, the proposed IQ-ECho middleware will offer the Quality of Service interfaces and mechanisms -- hence the `Q' in `IQ-ECho' -- via which (1) such needs and tradeoffs are made known to underlying resource management (at the OS or network levels) and (2) information about platform resources is made known to applications. In contrast to previous work on QoS in middleware, such as BBN's Quo system, our approach takes advantage of the `open' nature of many of the current platforms used in high performance computing, such as Linux-based Beowulf clusters or the programmable network interfaces used in the ASAN project funded by DOE at Georgia Tech (Profs. Yalamanchili and Schwan, PIs). Specifically, rather than asking end users to state their QoS needs with attribute-value pairs as in Quo, for example, or with the payoff or utility functions used in our own prior work, we propose to simply let an application `program' the underlying `open' platform. Such programming has two goals: (1) to help the network or operating system manage resources in a manner meaningful to applications, and (2) to have system levels export to applications resource information that is comprehensible and meaningful.

Toward these ends, the IQ-ECho middleware will support client-specific (or more generally, receiver-specific) data transport, sampling, and transformation, by permitting applications to create logical communication channels with associated filter functions, using the derived channel concept developed in our earlier work. These functions may be dynamically defined and run by the data receivers, but receivers can also `push' them into the address spaces of data senders and/or even into underlying operating system kernels or networks. Thus, filter functions extend collaborators' functionality, in a fashion meaningful to their applications.

Year 1

• Task 1 – Integrate the concept of performance attributes into the ECho middleware
• Task 2 – Select and implement sample application/visualization
• Task 3 – Identify and create instrumentation for network performance attributes

Year 2

• Task 1 -- Evaluate and tune middleware/performance attribute behavior with microbenchmarks
• Task 2 -- Generalize application to respond to and control performance attributes
• Task 3 -- Extend/create configurable network protocols (e.g. configurable reliable UDP)

Year 3

• Task 1 – Integrate ECho-IQ with TBD access grid software
• Task 2 – Demonstrate benefits in general access grid environment

• Task 3 – Prepare ECho-IQ for general release