| Problem Statement |
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:
| Solution Approach |
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.
| Specific Research Goals |
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.
| Project Documents |
| Publications |
| Presentations |
