Next: Conclusions
Up: CANS: Composable, Adaptive Network
Previous: Case Study
Related Work and Discussion
CANS shares its goals with many recent efforts that have looked at
injecting adaptation functionality into the network. Instead of
describing each separately, we group related efforts to put our work
in perspective.
Adaptation functionality can be introduced only at the end-points or
could be distributed on intermediate nodes. Odyssey [15],
Rover [12] and InfoPyramid [14] are examples of
systems that support end point adaptation. Each system provides only
minimal support for composing adaptation activities across multiple
nodes, and consequently may not be flexible enough to cope with
changes in intermediate links. Efforts targeting adaptation at
intermediate nodes in the network can themselves be viewed in terms of
two issues: whether adaptation functionality is
application-transparent or application-aware, and whether the
functionality is introduced at the network level or the application
level.
Systems such as transformer tunnels [16], protocol
boosters [13] are examples of application-transparent
adaptation efforts that work at the network level. Such systems can
cope with localized changes in network conditions but cannot adapt to
behaviors that differ widely from the norm. Moreover, their
transparency hinders composability of multiple adaptations. More
general are programmable network infrastructures, such as
COMET [3], which supports flow-based adaptation, and Active
Networks [17,19], which permit special code
to be executed for each packet at each visited network element. While
these approaches provide an extremely general adaptation mechanism,
significant change to existing infrastructure is required for their
deployment.
Similar functionality can also be supported at the application level.
The cluster-based proxies in BARWAN/Daedalus [6],
TACC [7], and MultiSpace [9] are examples of
systems where application-transparent adaptation happens in
intermediate nodes (typically a small number) in the network.
Active Services [1] extends these systems to a distributed
setting by permitting a client application to explicitly start one or
more services on its behalf that can transform the data it receives
from an end service. A different perspective is offered by systems
such as Conductor [20], which automatically deploy
multiple application-transparent adaptors along the data path between
applications and end services. Although such systems retain backward
compatibility with existing applications, the lack of application
input limits their flexibility. Furthermore, such systems rely upon
self-describing properties of data streams, a condition that may or
may not hold given increasingly proprietary content.
More general are systems such as Ninja [8],
PIMA [2], and Portolano [5], which
permit construction of programmable ubiquitous access systems from
networked services and transformational components. CANS also provides
application-level support for injecting application-aware
functionality into the network, but differs from the above systems in
its focus on infrastructural support required for dynamic adaptation.
CANS has been most heavily influenced by the Conductor design and
shares several features with the Ninja infrastructure.
Conductor [20] provides an application-transparent
adaptation framework that permits the introduction of arbitrary
adaptors in the data path between applications and end services.
Applications are integrated into the framework by modifying the
kernel to trap calls that create and use TCP sockets. CANS
borrows the idea of transparent stream-based adaptation from
Conductor but differs in applying it to application-aware
adaptation in a larger context that involves multiple services
contributing to the data path; consequently, we require
infrastructural support for downloading component code,
instantiating the components, and ensuring compatibility. Also
different is the degree of support provided by the infrastructure
for reconfiguring existing paths, specifically the notion of
semantics-preserving adaptation that spans multiple drivers, and
general support for dynamic run-time composition of components.
Ninja [8] is a general architecture for building robust
internet-scale systems and services consisting of three components:
services, units, and paths. We restrict our attention to how paths are
constructed in Ninja since that is the closest to our objective.
Several CANS concepts find close matches in the Ninja design: our
service-driver distinction is closely related to Ninja's
service-operator distinction and both systems share ideas such as
type-based composition and dynamic service adaptation. Despite these
high-level similarities, the systems differ significantly in the
details. Unlike Ninja, the CANS infrastructure provides support for
(1) efficient composition of multiple drivers within the same physical
host, (2) planning algorithms that consider route characteristics in
addition to bridging type incompatibilities, (3) dynamic and
distributed event-driven adaptation on existing paths, and (4) support
for semantics-preserving adaptations that span multiple drivers; Ninja
requires applications to provide their own mechanisms to ensure
semantics such as guaranteed or in-order data delivery. On the flip
side, it must be noted that unlike Ninja, CANS currently provides
little support for scalability.
Next: Conclusions
Up: CANS: Composable, Adaptive Network
Previous: Case Study
Weisong Shi
2001-01-08