The Quality Objects (QuO) middleware is a set of extensions to standard distributed object computing middleware that is used to control and adapt the quality of service in a number of distributed application environments, from wide-area to embedded distributed applications. This paper compares and contrasts the characteristics of key use cases and the variations in QuO implementations that have emerged to support them. We present these variations in the context of several actual applications being developed using the QuO middleware.

Several QoS provisioning mechanisms such as differentiated services (Diffserv) and integrated services (Intserv) have been recently devised and applied to bring quality of service (QoS) to the Internet. This paper studies end-end QoS performances of two QoS-demanding applications using different transport protocols. Both applications are tested in a real network environment, with end-end QoS provisioning by Intserv. They use QoSockets, a new extension of QoS specification and management to the Berkeley sockets. Their performance in terms of throughput, delay, jitter, and loss are measured under a number of test cases combining several factors: (1) single or multiple flows, with or without resource reservations; (2) normal, heavy, or overloaded scenarios; (3) uni- or bi-directional streams; and (4) TCP or UDP protocols. The experimental results show that the performance of two applications with the Intserv resource reservations are significantly improved, but not always guaranteed. It is also shown that UDP applications are able to get the requested QoS while TCP applications may not because of the nature of its bi-directional traffic flow. The paper provides detailed interpretation of the results and provides generic conclusions on application QoS.

Recent work in opening up distributed object systems to make them suitable for applications needing quality of service control has had the side effect of increasing the complexity in setting up, configuring, and initializing such applications. Configuration of distributed applications is more complicated than that of non-distributed applications, simply because of the heterogeneous and distributed nature of the application's components. CORBA and other distributed object middleware simplifies the configuration of distributed object applications, but hides much of the information and control necessary to achieve quality of service (QoS). We describe the techniques and tools that we have developed within our Quality Objects (QuO) framework for simplifying the configuration of distributed applications with QoS attributes. We describe a QuO configuration language, as well as the specific configuration needs of particular QoS properties-real-time, security, and dependability-and the support we provide for them.

The distributed resource controller (DRC) technology described in this paper provides a novel approach to interfacing applications with emerging network mechanisms to deliver quality of service (QoS) and controlling network resource utilization. DRC aims to unify network services (e.g., Diffserv, Intserv, and ATM) and application QoS provisioning by introducing a middleware system and a set of generic interfaces. DRC middleware is the core part that translates application requests for QoS delivery into respective access to underlying network systems in a manner that optimizes resource utilization and shelters applications from such a complexity. Applications can request QoS to the DRC middleware in two ways: either on-line using the DRC QoS API or off-line via the DRC utility. Application QoS requirements are specified in terms of two categories of parameters: traffic profile (quantitative) and user expectation (qualitative). DRC currently uses the CORBA-based object-oriented technology to develop a CORBA-based resource controller (CRC). The working CRC prototype built to manage the integrated services is also presented.

A common class of wide-area distributed applications remotely collect time-varying data and send it to consumers around the network. Some examples of these include network management, stock ticker data and event logs. The environment in which these applications must operate often dictates the schemes for disseminating the data between the writers and the readers. If the transport channel can be optimized to match the application's behavior patterns and the network resource constraints, sufficient improvements in application-level quality of service (QoS) can be achieved. The PASS (Piecewise Asynchronous Sample Service) system addresses this problem by using a flexible system of interconnected servers. PASS servers are distributed geographically around the network and are connected to readers and writers using the CORBA protocol. The forwarding policies used by the servers and the server interconnections can be customized for each application. Thus, PASS acts like an application-level multicast service with variable forwarding policies. PASS has been used to disseminate the up/down status of a large number of devices to a network management system. The PASS forwarding policy used very little network bandwidth while responding to failures in half a network round-trip time.

As networks and the use of communications within applications continue to grow and find more uses, so too does the demand for more control and manageability of various "system properties" through middleware. An important component supporting an integrated property architecture is the concept of an object gateway, which is a quality-of-service (QoS)-aware element transparently inserted at the transport layer between clients and objects to provide managed communication behavior for the particular property being supported. In this paper, we introduce the concept of a QoS-oriented gateway to integrate a variety of QoS enforcement and implementation mechanisms controlling the underlying distributed interactions. We discuss the functions performed by such a component in achieving the desired overall end-to-end QoS, and the design considerations underlying our current implementation. We conclude with experiences to date with two variations of the gateway: one controlling managed latency and throughput using bandwidth allocation, and one controlling dependability through the coordination of object replicas.

Distributed applications are difficult to build and maintain and are even more difficult when the applications are distributed over wide-area networks. Distributed Object Computing middleware has emerged to simplify the building of distributed applications by hiding implementation details behind functional interfaces. However, critical applications have non-functional requirements, such as real-time performance, dependability, or security, that are as important as the functional requirements, but are also hidden by the middleware. Because current distributed object middleware doesn't support these aspects of critical applications, application developers often find themselves bypassing the distributed object systems, effectively gaining little or no advantage from the middleware. We have developed Quality Objects (QuO), a framework for including Quality of Service (QoS) in distributed object applications. QuO supports the specification of QoS contracts between clients and service providers, runtime monitoring of contracts, and adaptation to changing system conditions. A crucial aspect of QuO is a suite of Quality Description Languages for describing states of QoS, system elements that need to be monitored to measure the current QoS, and notification and adaptation to trigger when the state of QoS in the system changes. This paper gives a brief overview of QuO and describes the syntax and semantics of CDL, the component of QDL for describing QoS contracts.

This paper describes an environment for visualizing packet traces that greatly simplifies troubleshooting protocol implementations. Network management centers routinely collect packet traces to tally traffic statistics and to troubleshoot protocol configuration and implementation problems. Previous efforts have focused on the reliable collection of traces and their statistical interpretation. Display of packet traces was restricted to a textual representation of the raw headers. Our prototype environment interprets the trace as a whole. It identifies conversations across protocol layers, simulates the services offered by lower layers, and hides the lower layer implementation detail from the representation of higher layer conversations. Our prototype offers over a dozen different types of diagrams for showing protocol interactions and uses linked highlighting to show the relationships between the objects in different diagrams.

The ARPANET routing metric was revised in July 1987, resulting in substantial performance improvements, especially in terms of user delay and effective network capacity. These revisions only affect the individual link costs (or metrics) on which the PSN (packet switching node) bases its routing decisions. They do not affect the SPF (“shortest path first”) algorithm employed to compute routes (installed in May 1979). The previous link metric was packet delay averaged over a ten second interval, which performed effectively under light-to-moderate traffic conditions. However, in heavily loaded networks it led to routing instabilities and wasted link and processor bandwidth.

An approach is proposed for extending the use of design models to the implementation and operational phases of the network development life cycle. A conceptual approach is offered for using executable models in the day-to-day operation of computer networks. Several strategies are given for integrating models into different development tasks. It is shown why these strategies are feasible. Characteristics of executable models that differ from those of traditional models are identified along with new technologies that reduce the cost of implementing and using executable models.>