Object-Oriented QoS for C2 Adaptivity and Evolvability
(Position Paper)

Introduction

The DoD's requirements and expectations for US military capabilities into the next century require very aggressive innovation. In the future DoD will be faced with scenarios involving more missions using smaller forces, and will need to rapidly adapt to new threats. As a result, future C2 systems will be required to be much more adaptable at runtime to unforeseen circumstances and be able to evolve over time to perform new missions. Software is already a critical part of today's C2 systems, and will necessarily be even more important in tomorrow's because it is malleable, and thus has the potential to allow the system to change to meet unanticipated future requirements.

Issues in Adaptivity and Evolvability for Next-Generation C2 Systems

In our view, middleware systems must go beyond today's state of the art to enable C2 systems to meet future challenges. We consider the following points essential for this to happen:

• C2 systems will be constructed with distributed object technology, so it is natural and beneficial to describe and provide security in object terms ("who can access this plan?") rather than in terms of hosts or networks. Middleware will thus be needed to bridge the gap between lower-level security mechanisms and the object-oriented C2 systems.
• C2 systems need ways to integrate different implementations of a given subsystem, each of which uses different security mechanisms and which are employed under different conditions/modes. C2 systems must be able to deploy the most appropriate implementation which uses the best tradeoffs for current conditions. The middleware must be flexible enough to be extensible for future conditions or new security mechanisms, because some may not be discovered or developed for years after the system has been deployed.
• C2 systems need a way to integrate security with other "non-functional" requirements such as availability, real-time, performance, etc. Requirements other than security are important, too! To support this, we believe that a generalized abstraction of quality of service (QoS) is important, and have developed this in the QuO project (see below). The notion of QoS generally held by researchers and practitioners involves mainly comms and performance issues and assumes a multimedia setting across only a LAN (or at most a MAN), without any adaptivity. Our view is that QoS should encompass all of the "non-functional" aspects of a client-object interaction that the application developer must regulate to make the C2 application more predictable and adaptable. These aspects include security, availability, performance, etc.
• End users and system administrators really know their usage requirements, not middleware developers, mechanism providers, or even C2 system developers. We thus must provide a way for the user and system administrators to make tradeoffs at runtime based on their current perceived requirements, not a hard-coded heuristic the system developer mandated years prior. This may include having different security modes, each of which meets the mandated minimal security level for the system, but which uses a different set of design tradeoffs.

Software engineering for systems as complex as C2 systems is inherently hard, harder still since security must be provided, and will be even harder if performance and availability and other aspects are to be adequately handled. We thus need to get a handle on how to organize these properties in a software engineering environment which C2 middleware must provide or else C2 systems will not be able to evolve to meet future threats.

Quality of Service for CORBA Objects

Overview

• QuO integrates knowledge of system properties over time, space, and source. In order to provide a clean way of reasoning about the system properties of the interactions between clients and objects, QuO employs the concept of a connection between a client and object, an encapsulation including the desired usage patterns and QoS requirements specified in the form of a contract. To help simplify the combinatorial problem of dealing with an N-dimensional QoS space in this contract, QuO supports first-class QoS regions, which designate regions of operation for the client-object connection. To help the application adapt to different system conditions, QuO supports multiple behaviors for a given functional interface, each bound to the QoS region for which it is best suited. Finally, QuO supports different commitment epochs, explicit times where different information about system properties is available to be bound.
• QuO reduces variance in system properties. Since all the information about system properties is spread over time, space, and source, QuO masks variance in system properties using layers of delegate objects in the client's address space. Each delegate layer embodies knowledge of system properties for one participant in the connection: the client; object; or CORBA Object Request Broker (ORB). Finally, system properties are encapsulated into first class objects which we call system condition objects.
• QuO makes embedded design decisions associated with an object implementation explicit, allowing the selection of different implementations in a given situation. Quality Description Language (QDL) includes sublanguages: a contract description language (CDL) to describe the contract between a client and an object in terms of usage and QoS; a structure description language (SDL) to expose the object's design decisions; and a resource description language (RDL) with which to implement a given object implementation. The preliminary implementation features an open implementation itself, where each delegate object has distinguished slots for system conditions, predicate engines to evaluate the QoS regions, etc. This will enable QuO to evolve over time. Finally, QuO's system condition objects can be used at different levels of granularity, which allows for their aggregation. For example, in the network performance domain a single system condition object which measures throughput could be bound to a single method invocation from one client, to any method invocation to a group of objects from multiple clients, or something in between.

QuO and Survivability

1. There will be a process to relate local properties to system-wide properties.
2. Critical properties of systems will be derived by ensuring robustness properties of their components.
3. Component interfaces will be augmented to include assumptions, guarantees, properties as well as functional spec.
4. Per-component cost/benefit tradeoffs.

The QuO architecture was developed in 1994 and early 1995 to meet these challenges, with the first emphasis on network performance with adaptivity. Pending QuO work will meet these challenges along the availability dimension in the following manner:

1. We are extending the existing QoS for Objects (QuO) technology developed at BBN to deal with availability, under a pending BAA 96-07 project to be managed by Dr. Gary Koob and teaming with the two groups mentioned below. We will use the Horus group communication substrate [vRBM96] developed by Prof. Ken Birman, Dr. Robbert van Renesse, and colleagues at Cornell University under DARPA sponsorship as part of the implementation, and modify Horus to better operate over a WAN. Finally, we will use existing techniques and tools for performability analysis developed by Prof. Bill Sanders and colleagues at the University of Illinois [SOQ+95] to do predictive and corroborative analysis, and extend these techniques to support group communication in synchrony with the development activity as a companion analysis and prediction capability to extend the work to unimplemented, non-measurable situations.
2. We will use a Horus group communication protocol stack derived from the application's end-to-end requirements specified using QuO and its companion modeling techniques.
3. QuO's CORBA-compliant API will augment the functional specification for a component (specified by IDL) from its current emphasis on network performance to include availability.
4. QuO's API allows different non-functional properties to be traded off based on the current operating environment, the existing resources, and the current mode of the application.

We hope to begin a similar endeavor with security properties in the near future, and other properties in medium term.

References

[ARPA95] ARPA, "Survivable Distributed Information Systems", 1995 ISAT Defensive Information Warfare Summer Study.

[BSZ96] David E. Bakken and Richard E. Schantz and John A. Zinky, QoS Issues for Wide-Area CORBA-Based Object Systems, in Proceedings of the Second International Workshop on Object-Oriented Real-Time Dependable Systems (WORDS 96), IEEE, Laguna Beach, California, February, 1996.

[SOQ+95] W. H. Sanders and W. D. Obal and M. A. Qureshi and F. K. Widjanarko, The ULTRASAN Modeling Environment, Performance Evaluation Journal, Special Issue on Tools for Performance Evaluation, vol. 1995. See also URL http://www.crhc.uiuc.edu.

[vRBM96] Robbert van Renesse and Kenneth P. Birman and Silvano Maffeis, Horus: A Flexible Group Communication System, Communications of the ACM, April 1996. See also URL http://www.cs.cornell.edu/Info/Projects/HORUS.

[ZBD97] John A. Zinky and David E. Bakken and Richard E. Schantz, Architectural Support for Quality of Service for CORBA Objects, Theory and Practice of Object Systems (TAPOS), January 1997, to appear. See also URL http://www.bbn.com/offerings/dcntn/dcntn.html.