Object Service Architecture

Network Monitor Service

Project Summary

Gil Hansen
Object Services and Consulting, Inc.
September 15, 1998

Executive Summary

Performance is one of a collection of overall systemic properties that pervade all parts of a system's design.  In large distributed systems, many decisions are made at design time based on the need for improved performance, but the tools for instrumenting a system for performance measurement at run time and for using this information to adaptively configure systems are often missing or idiosyncratic.  The OSA/Network Monitor Service project provides one of the missing ingredients to make large systems performance-aware and bandwidth-adaptive, namely, a generic wrapper that can be used with WAN or LAN Web accesses to record network performance data and trends.  This data can later be used in other OSA/* projects (e.g., OSA/Query Augmentor and OSA/Annotations) to provide those projects with the performance metadata they will need to become bandwidth-adaptive.

Problem Statement

Certain decisions made by applications and middleware services require knowing about the current and historical performance conditions of the underlying communication network.  For example, in selecting the best site to process a query, a query service needs to know if the source node is active and the expected traffic on links at specific times of the day.  To date most applications above the network level are not bandwidth-adaptive, that is, they are insensitive to or unaware of the quality of service (QoS) of the network they operate on. A prerequisite to making applications bandwidth-adaptive is to provide them network topology, historical trend, and current condition performance metadata, but this data is not generally available.


The near-term objective of this project was to build a Personal Network Monitor Service (pNMS) for the Web that captures network performance metadata based on URL accesses.  A browser issues a GET operation on a URL as usual, but a side effect, if the service is enabled, is to collect network access data on the route of the access through the network and time delays at each hop.  We wanted to determine: The long term objective was to provide application and middleware services with network historical trend and current condition performance metadata so they may be aware of the quality of service (QoS) of the network they operate on and thereby enable them to become bandwidth-adaptive. Ultimately, the objective was to provide a generic architectural framework that supports Web-based activities including the optimization of a distributed application; the monitoring of resources, performance, and QoS parameters; resource management; and the management of QoS.


Ideally, the Internet would be subdivided into monitored domains or realms, and a Network Monitor Service (NMS) would supply current and historical performance conditions. But this information is not generally available.  In this project, as an alternative, we explored a local personal NMS (pNMS), which can act as a poor man's NMS. pNMS would unobtrusively monitor user network accesses and record performance information in a local metadata repository (MDR). As a user accesses information using URLs in a browser, an interceptor captures the URL and information about the path taken through the Internet (e.g., nodes visited, transit times between nodes). Over time, the nodes and links of the portion of the Internet of interest to the user are mapped and a picture emerges of node and link availability and responsiveness from the viewpoint of the user. To enlarge the mapped area, a monitor extension could autonomously and periodically ping Internet nodes and record performance data in the MDR. A poor man's NMS for a domain (collection of users, e.g., in an organization or with similar interests, for instance, collaborators) would pool performance metadata gathered by local NMSs and provide a broader coverage of current and historical conditions. One means of a domain NMS forming a collective view is to systematically visit each local site in the domain and analyze its pNMS MDR. Upon return, the gathered information would be used to update the domain NMS's MDR. Alternatively, each local pNMS could periodically transmit its MDR to the domain NMS.

In this project, monitoring the user and pinging the Internet was handled by a network monitor service, which handles service requests by clients for network conditions. It is transparent to the user whether an NMS probes the pNMS, a domain NMS, or a federation of NMSs.  Two interfaces will be provided.  One is the pNMS service API interface that programs can use to ask about network weather conditions.  The other is a human pNMS GUI for viewing historical weather conditions about the mapped portion of the Internet.

pNMS is a scalable service. As the Internet expands, pNMSs can be added to new nodes in a domain. A spider for a domain NMS would now have more local sites to visit, or there could be multiple spiders concurrently gathering information from disjoint portions of the domain and their results combined upon return to form a collective view. There could even be one Internet NMS that gathers weather information from the domain NMSs. Thus, NMSs are naturally hierarchical and scale as links and nodes are added. Domain NMSs also decentralize the gathering and usage of weather information. Weather information need not be routed to a central NMS for processing. Instead spiders can roam a domain visiting local pNMS to form a collective view of the domain, or roam domains visiting domain NMSs to form a collective view of the Internet.

Limitations of Related Work

There already exist a variety of network monitoring tools and network management schemes and Internet and TCP/IP measurement tools.  These include: Most QoS work has focused on providing end-to-end network-level QoS (e.g., IETF RSVP) and not top-to-bottom application to comm-layer QoS. For instance, currently Internet search engines do not take network performance data into account. While performance data will not improve the quality of the query result, it can affect the quality of the query service.


Preliminary investigative work for this project was completed, namely, an Internet Tools Survey section on Quality of Service.  We identified enabling technology (see below) for use in the project.

Fundamental infrastructure and functionality has been implemented. The weather service was integrated with the Intermediary Architecture that uses W3C's Jigsaw proxy server. The URL of unique remote sites accessed are captured and passed to a concurrent performance monitor application which generates round-trip times to each site using Ping and stores the information in the pNMS metadata repository (MDR), a PSE object database. Also, the effective bandwidth to each site (duration of download/total size of download) is calculated. [NOTE: The duration includes the time for the browser to determine whether to use a cached version of the resource (assuming one exists). It must query the server to determine the date the resource was last modified, and if the server is busy this will add to the duration for those uncached portions.]

A Historical View GUI allows performance metadata for a particular URL to be filtered and viewed. Data can be presented in traditional tabular form in which each column can be sorted causing the rows to be reordered or the raw data for each entry dumped in a prescribed format.

The weather service is not ready for use by others because 1) an API for accessing historical data for a remote host hasn't been defined; 2) there are no mechanisms for providing performance trend data; 3) network performance tools yielding relevant metrics have not been identified or incorporated; 4) performance metadata is not collected from multiple MDRs and used to form a composite view. Basically, only the underlying infrastructure has been implemented.

The MDR may be queried using the OSA Natural Language Interface. This was demonstrated by transforming the PSE database into an Access database and constructing a description of the legal queries.

Enabling Technology

Lessons Learned

Next Steps

These are some of the potential next steps for this project.  More work is needed in many areas.


We cannot make object services architecture  performance-aware if we do not have a means of measuring OSA performance.  pNMS by itself is a relatively simple service.  Some interesting aspects of pNMS are: These results are aligned with our ultimate goal of providing a generic architectural framework that supports Web-based activities which includes the optimization of a distributed application, the monitoring of resources, performance, and QoS parameters, resource management, and the management of QoS.

This research is sponsored by the Defense Advanced Research Projects Agency and managed by the U.S. Army Research Laboratory under contract DAAL01-95-C-0112. The views and conclusions contained in this document are those of the authors and should not be interpreted as necessarily representing the official policies, either expressed or implied of the Defense Advanced Research Projects Agency, U.S. Army Research Laboratory, or the United States Government.

© Copyright 1997, 1998 Object Services and Consulting, Inc. Permission is granted to copy this document provided this copyright statement is retained in all copies. Disclaimer: OBJS does not warrant the accuracy or completeness of the information in this survey.

Last revised: September 15, 1998.  Send comments to Gil Hansen.