About the LSAM Project

L arge

S cale

A ctive

M iddleware

The LSAM Proxy Cache uses multicast push based on interest groups,
to reduce server and network load, and increase client performance.

Index to this FAQ:

LSAM Definition

The LSAM project is developing the middleware infrastructure to support scalable distributed information services. Current implementations of such services rely on individual components, such as Web servers, WAIS servers, and host clients. Some resource sharing is provided via distributed indexing systems, e.g., Harvest, or manually configured proxy caches. The goal of LSAM is to develop middleware to support large-scale deployment of distributed information services with effective economies of scale.

LSAM's focus is to provide information services with:

The LSAM project is currently integrating the components of its earlier research into a self-organizing multicast cache system, called the LSAM proxy. The LSAM Proxyuses multicast push based on interest groups, to reduce server and network load, and increase client performance.

Middleware Definition

We define middleware as:

Distributed services that:

There are other definitions which have been used in the past, at other workshops or meetings, such as:

a service, API, and protocol (one or all three) for OS-independent distributed shared resource management and integration

One key aspect, to us, is that middleware is NOT better described as any of the following:

Assumptions of the Proxy design

The LSAM proxy relies on a few assumptions:

Idle bandwidth is an opportunity, because it provides a communication resource that others are not using. Assuming the network provider does not charge for using this (otherwise) idle capacity, it is in everyone's best interest to use it. That use can avoid resource contention in the future, and provide better service too. The key issue of idle bandwidth is to ensure that it does not interfere with other, foreground traffic. Current Internet research is already developing techniques to address the issue of differentiated traffic classes, although the notion of background capacity presents its own particular challenges.

Distributed client hot-spot traffic describes the convergence of the distributed web user community on sets of pages, where these sets vary over time. For example, in early January, the Superbowl web pages become popular. Later in Jan (of certain years), the Olympics web pages would become popular. When news events arise, their associated web pages also become popular. This popularity causes hot-spots in web traffic, resulting in very localized loads (both server and network), yielding poor performance for a distributed set of clients. Such effects have been noticed in our own regional network, e.g., when JPL's pages for the Mars landing became popular. Local caches disperse this load somewhat, but only where clients share a cache. The dispersed set of caches themselves still cause these hot-spots to occur.

NOTE - LSAM is not designed to optimize all web cache access, but is rather focused on the domain of distributed client hot-spot web traffic, for several reasons:

An important result of these assumptions is that LSAM is not designed to address all web cache traffic, or even a majority thereof. We see a taxonomy of caching, in which LSAM plays a part:

The combination of these caches together is expected to provide the highest benefit, both as fastest response, and as lowest overall network and server resource utilization.

About response time

Response time is a key parameter of distributed interaction. There is no real difference between Netscape and Wordperfect - both act like applications to the user. The only difference is in reaction latency. There are several ways to reduce latency, all of which consume some resources - recomputing (processing), resending (bandwidth), and caching (storage) are all used.

Further, interactive response for web traffic indicate that very high bandwidth is required, or that interactivity is not possible in some cases. This is the motivation for a push-based model, where push is anticipative.

The LSAM Proxy

The LSAM Proxy is deployed near both clients and servers. Near the client, the proxy acts as an intelligent cache, allowing multicast channels to preload it with relevant pages. Near the server, the proxy acts as an intelligent pump, managing multicast groups and detecting page affinities, to multicast related information to a set of interested client caches.

Overall, the system is based on two levels of multicast channels. These channels are the core of the system; all other features are designed to enhance and support the operation of these channels.

Features of the LSAM Proxy architecture

LSAM home ISI home
Page maintainer: the LSAM project

Last modified: Thu Feb 18 12:49:04 PST 1999
Copyright © 1996 by USC/ISI