Co-operative Adaptation Between End Points
Peter Reiher, Richard Guy, Kevin Eustice, Vincent Ferreria, Mark Yarvis
University of California, Los Angeles
ABSTRACT
Open architecture systems present many challenges for system and application
designers. Problems such as selecting adaptations, reliability, and security are
overly complicated in traditional adaptation paradigms. Frequently, network
applications operate peer to peer – where it is in the best interest of both parties to
communicate. This model can be exploited to our benefit in open architectures. By
shifting adaptation models towards co-operative adaptation along endpoints, hard
problems can be simplified; at the same time, we can still maintain desired
flexibility.
1.
INTRODUCTION
Open architecture systems typically assume one of two models of deployment
in their designs. Some systems assume a single point of adaptation, such as proxies.
A slight variant is systems that perform adaptation on both sides of a single
troublesome link. The common alternative is an architecture that assumes
widespread deployment of adaptation capabilities. While perhaps not every node is
capable of running adaptive code, potentially any router, end machine, gateway,
server, firewall, or other machine could be configured to adapt data streams. Such
architectures must take many complex possibilities into account in their design, since
the system must work properly even for such complex cases.
The first model has the advantages of simplicity and easy deployment. As a
result, it is in wide use today. However, it can not meet all the needs of future
networks, as it provides a myopic view of the network and its problems. If both the
sender and receiver of the data stream use this model, they may perform redundant
adaptations (both compressing and decompressing the data stream, for example), or
may perform incompatible adaptations (the sender strips all color from a color video
stream, while the receiver tries to reduce from full color to a more limited palette). In
such a model, those two adaptable endpoints are completely unaware of each other’s
existence, and will do nothing to coordinate their activities.
The second model has the full power of generality, but with that power comes
a significant set of problems to solve to make the system practical. These problems
include difficult performance and security issues, as well as serious distributed
systems issues of coordination and reliability.
1
An intermediate approach between these two extremes has yet to be thoroughly
explored. Adaptation could be enabled where it is most easily deployed, at or near
the endpoints. Nodes at or near the endpoints could cooperate to provide a coherent
set of adaptations. This paper discusses the cooperative endpoint model in more
detail, covering areas of applicability, its practical advantages for solving certain hard
problems of distributed adaptation, and its limitations.
2.
THE COOPERATIVE ENDPOINT MODEL
An intermediate model offers many of the advantages of both of these existing
models. In this model, adaptation essentially occurs only at the endpoints of a pointto-point connection, but the adaptation at both endpoints is coordinated. If both the
sender and receiver need to reduce the amount of data being transmitted over their
connections to the larger network, the sender will compress before sending and the
receiver decompress after receiving. A redundant decompression/compression cycle
is avoided, and the overall network is less burdened with data transmission. If
security is required, end-to-end encryption can be used. If the data must be
customized for a PDA receiver, the customization (and probable reduction in data
size) can be performed at the sending node.
This model of adaptation has several advantages. First, many of the more
troublesome links and nodes in the networks are close to the edges of the network,
anyway. Dial up lines, wireless LAN links, serial lines, and other links of limited
capability are not typically used to hook up backbone routers. While this observation
is not universally true (satellite links can connect backbone routers, for example, and
they have troublesome characteristics), it does cover many cases.
A second advantage is that the end points are under control of (possibly
distinct) parties that have a vested interest in the adaptation occurring. Both sender
and receiver presumably want the data transmission to occur in the best fashion
possible, and are willing to take reasonable measures to achieve that goal. Further,
these sites have the best knowledge of the purpose of the transmission, and are thus
best able to weigh the costs and benefits of performing adaptation.
A third advantage is that this model decreases the security risks associated with
performing adaptations in the middle of the network. The only parties involved in
adaptation are those who want to participate in the transmission, and who thus
understand the security risks. Further, they are end nodes, and their corruption will
have much more limited effects than corruption of a backbone router or ISP point of
presence.
2
Router
Router
ISP
Dial-up host
Wireless Bridge
Figure 1. A typical scenario for endpoint adaptation.
A fourth advantage is that this model decreases concerns about the scalability
of adaptive systems. A backbone router that provides adaptive services faces many
scalability concerns, including providing adaptive capabilities for large numbers of
flows simultaneously, maintaining many different pieces of adaptation code, and
ensuring the secure operation of large numbers of different adaptation modules. In
this model, on the other hand, the end nodes need only concern themselves with
traffic that they initiate. They can limit the modules they use to those suitable for the
kinds of data they handle. The security scaling problem is bounded, since there are
controllably few modules to run and controllably few partners who must be
authenticated.
A fifth advantage of this model is that several hard problems for general
network open architectures become simpler. For example, in the general case where
any node in the network can potentially adapt a data flow, there are significant
problems of reliability. Each point of adaptation becomes another potential point of
failure, and, to the extent that the adaptation was stateful or there was established
connectivity between adaptors on different nodes, the failure of one adaptor can lead
to a difficult problem in maintaining the connection. In a non-adaptive network, such
a failure merely causes packets to take a different route. In this new model, however,
adaptation only occurs near the end points. Usually, one can assume that failure of
one of those end points will lead to failure of the overall connection. Failures of
adaptors that do not crash adaptation nodes can be handled by relatively simple
recovery mechanisms, because the limitations of the system rule out complexities that
make recovery difficult.
The model can be slightly generalized without losing significant advantages.
Instead of assuming a single point of adaptation on each end, the model can
accommodate contiguous segments of adaptability on each end, with a “black box”
network providing no adaptability between the segments. For example, on one end a
user on a machine at his home might dial up a server, which communicates with a
local router, which in turn is connected to an ISP. The home machine, the server, and
the router are all in the same administrative domain, and can all reasonably provide
homogenous adaptive services. At the other end, a router may connect to a wireless
bridge, which sends the data over a wireless LAN to a portable computer. At this
end, the router, bridge, and portable computer can all run adaptation services.
However, the network in the middle does no adaptation. Figure 1 shows this
scenario, with the segments of adaptability shown in the circles at either end of the
connection.
3
Generally, the model allows an arbitrary number of adaptation locations at
each end of a connection, with a region between the adaptive ends where no
adaptation is possible. Each adaptive segment is assumed to be a single
administrative domain. Thus, the required software (both the middleware and the
actual adaptive modules) can be assumed to be deployed where necessary in the
segment, and any required security associations, certificates, or shared keys can be
arranged in a relatively straightforward manner. Further, all elements of the segment
are assumed to be willing to devote reasonable resources to adapting data flows that
originate or terminate at nodes in the segment. Each of the two segments, however,
is its own administrative domain, and thus the two segments do not share these
advantages between them.
3.
APPLICATIONS OF ENDPOINT ADAPTATION
A broad spectrum of existing and emerging applications can benefit from this
intermediate open architecture model.
These include human-to-human
communication services, streaming media services, network-based games, file
transfer, and smart appliance-enabled purchasing.
Human-to-human communication services range from Internet (voice)
telephony to instant messaging to video telephony to distributed whiteboarding. Each
of these has a characteristic reliance on an intermediate network outside the control
of the end users, but with network and computational resources at the “endpoint” subnetworks that are (or easily could be) under at least some control of the end users.
Each of these services also could benefit from one or more adaptations: sessionoriented, encryption-based privacy and integrity enforcement; multi-path routing for
improved performance and/or security; forward-error correction for mobile wireless
end users; lossy compression for bandwidth-constrained links; and format conversion
from audio-to-text and vice-versa to compensate for extreme bandwidth limitations.
These adaptations may be required at a given endpoint or across the WAN between
the endpoints.
Streaming audio and video services such as the existing RealPlayer and
RealJukebox products from RealNetworks.com already employ a proprietary form of
endpoint adaptation: the endpoints negotiate an appropriate degree of resolution for
the data to be streamed, relative to current assessments of network quality of service.
Our model would provide a standard framework in which to make not just the
conventional arrangements for adaptation, but additional adaptations not envisioned
by the service, or deliberately not deployed for development economy’s sake.
Network-based games such as Quake and Doom are often latency-sensitive,
and dynamic adaptation of resolution to compensate for limited bandwidth would
improve playability. This application-space is another opportunity for an open
4
architecture intermediate model to provide adaptations not originally built into the
game.
File transfer protocols like FTP and Gnutella [Gnutella] may require obvious
adaptations such as security and compression. In addition, format conversion may be
a useful candidate: the choice of whether and where to perform DOS-to-Unix line
break translation should be planned, rather than unilaterally decided by one endpoint
or the other. Similarly, on-the-fly human language translation requires planning and
decision making at the endpoints of the network connection, and not in the
intermediate internetwork.
Finally, the arena of network-enabled home appliances and the emerging
possibilities of automatic purchasing and re-supply of consumables raise issues of
network protocol incompatibility. For instance, Bluetooth-enabled [Bluetooth]
refrigerators may need to communicate via the Internet with the local grocery store,
despite the absence of IP protocol stacks on one of the endpoints. With our model,
negotiation of what protocol to use end-to-end, and appropriate protocol conversion
and tunneling, can be performed—even if the endpoints are unaware of each other’s
native protocols.
4.
PLANNING FOR ENDPOINT ADAPTATION
Open architectures present a spectrum of planning problem domains. Proxy
architectures are at one end of the spectrum, providing local decision making without
any coordination with other points of adaptation that might be present. Active
networks and other multi-point adaptation architectures are at the other end of the
spectrum, requiring complex coordination between unrelated nodes that have
independent goals.
In general, planning for adaptation in open architectures consists of detecting
the conditions of the links over which data will travel and selecting a coherent set of
adaptors to deploy into the network. Inputs to this process include the protocol being
adapted, the properties of the links over which data will flow (bandwidth, latency,
security, etc), the resources available at the potential points of adaptation (CPU
cycles, storage space, etc), and the set of available adaptations. In the most complex
case, where adaptation can occur at many points throughout the network, choosing an
appropriate set of adaptors can be difficult. The solution space is large, and the
planning process must complete quickly so that user data can flow without undue
delay.
In addition, distributed planning requires an exchange of planning
information. A simple algorithm would gather the input data from all nodes at one
point, perform planning, and distribute a plan to the participants. Since the
information exchange between nodes involved in planning competes for the same
resources as user data, the planning algorithm itself must conserve bandwidth.
5
The endpoint adaptation model has some useful characteristics that simplify
the planning process. First, since each adaptive segment is autonomous, it may make
sense for the bulk of the planning to occur locally to each segment. With half as
many nodes involved in each of two planning processes, the size of each planning
problem is reduced. In addition, by localizing the bulk of the planning activities,
cross-WAN traffic may be reduced.
Other features of the endpoint adaptation model further simplify the local
planning process. First, nodes within the adaptable segment at a given endpoint are
likely to be willing to work together for the common good of that endpoint. Less
negotiation may be needed between the initiating node and the other nodes to arrange
for supporting adaptation. Second, within a given adaptive segment, the number of
network deficiencies that typically occur and the number of available adaptors will be
small. Thus, the number of possible plans is reduced dramatically. Planning within
an adaptable segment may take less time and require less communication than does
planning among the same number of unrelated nodes.
The endpoint adaptation model may also simplify coordination between
adaptive segments. The two segments at either end of a connection share a common
goal: successful communication. Unlike an independent node in the core of the
network, a node within one segment should be willing to support the requirements of
either segment. This willingness to cooperate may again reduce the amount of intersegment communication needed to negotiate proper adaptations. In addition,
communication patterns contain a certain amount of locality. Two communicating
nodes have probably communicated before and will likely do so again. Thus,
planning for a session between two adaptive segments might only require the
selection of the same set of adaptations used in some previous session between the
same adaptive segments.
Planning between two adaptive segments cannot be entirely independent,
however: any adaptation required for transmission across the WAN, which can be
thought of as a single link between the edges of two adaptive segments, may require
coordination between segments. For instance, if the WAN provides insufficient
security, encryption should be provided within one adaptive segment and decryption
within the other.
Similarly, if the WAN provides insufficient bandwidth,
compression and decompression may be required between the two segments. Actions
taken by one adaptive segment may also be incompatible with the conditions in
another. For instance, low bandwidth in one adaptive segment may be interpreted by
the other adaptive segment as high WAN latency. If the later segment chooses to
overcome this problem via prefetching, the problem will worsen.
Additional coordination may also be desired between adaptive segments to
remove any redundancy in the adaptations provided by each. For instance, if each
adaptive segment includes a 56 Kbps modem link, compression may be desired
across each link. However, it is more efficient to compress before the low-bandwidth
link in one adaptive segment and decompress after the low-bandwidth link in the
6
other than to perform this operation twice, once within each segment. Even if only
one low-bandwidth link exists, it can be argued that compressing data as early as
possible in the transmission path can save bandwidth across many links. Therefore, it
may be mutually beneficial for one adaptive segment to compress on behalf of
another adaptive segment.
Planning in the endpoint adaptation model might consist of two phases. First,
each adaptive segment can perform initial planning independently. The information
required for planning within that segment (node and link resources, available
adaptors, etc) can be exchanged in some manner and a “local” plan can be
formulated. Because of the limited number of nodes, problems, and adaptors, a
brute-force evaluation of all plans in the planning space may be possible. Or perhaps
the problem characteristics may be matched against a set of templates that describe a
predetermined set of solutions.
Figure 2. Initial localised planning within adaptive endpoints.
Consider the example in Figure 2. Each segment has a low bandwidth link and
considers the Internet to be insecure.
Each has selected a pair of
compression/decompression adaptors. Segment B has also chosen to encrypt and
segment A to decrypt, but they have chosen different encryption algorithms. A
variety of inter-segment coordination mechanisms are possible to optimize these
plans.
Two segments can obtain a coordinated plan by exchanging their independent
plans and implicitly expecting the other to make appropriate adjustments. For
instance, Segment A could send its plan to Segment B. Segment B might notice that
the encryption and decryption adaptors are incompatible and replace its decryption
adaptor to match the encryption adaptor suggested by Segment A. Segment B might
also notice the presence of redundant compression and choose to remove its
compressor. Segment B can send the resulting plan to Segment A. Segment A will
also notice the redundant use of adaptation and the unbalanced decompression in
Segment B’s plan. Segment A will adjust its plan by removing the decompression
7
adaptor. The two plans have been implicitly reconciled. Notice however, that this
process can fail. The two segments may be unable to agree upon a common
encryption algorithm.
Alternatively Segment A may not agree that
compression/decompression should be extended across the two segments.
Providing constraints along with a plan could increase the probability of
successful negotiation. For instance, Segment A might indicate that it will only
accept encryption with 128 bit keys or greater but that it is willing to extend
compression across the WAN. Such constraints can help prevent Segment B from
making incorrect assumptions about the changes Segment A will be willing to make
to its plan.
Explicit negotiations could also be used to coordinate planning between
segments. Segment A could send its plan to Segment B along with a request that
Segment B perform decryption. Segment B might accept this request and send its
own request to Segment A that decompression not be performed within Segment A.
If Segment A accepts Segment B’s request, an explicitly reconciled plan will be
reached.
In the above explicit reconciliation scheme, it is possible for one segment to
refuse the request of another segment. When this occurs, three actions are possible:
(1) fail the connection, (2) proceed without the desired optimization, or (3) try a
different request. Failure might be appropriate if the change is mandatory. For
instance, if the WAN is insecure but one segment is unwilling to provide encryption
or decryption, no data should flow. When requests merely provide optimization,
however, a plan with redundant actions may be better than no plan at all. Finally,
when time and complexity permit, a series of requests suggesting various different
approaches to optimization can be tried until one succeeds.
It is not yet clear what form of negotiation is best for the cooperative endpoint
model. However, it seems likely that the properties of this model will allow faster
planning with less inter-node communication.
5.
RELIABILITY FOR ENDPOINT ADAPTATION
Problems of reliability in general network open architectures increase greatly
due to the increased number of nodes and software components involved. Any
robust system must be able to maintain a connection between the end points in spite
of intermediate component failures. In adaptation systems, not only can a node fail in
whole, but each individual adaptation performed on a node can fail. Although the
endpoint model of adaptation does not reduce the types of failures, it provides us
with some simplifying assumptions during recovery.
Two steps are required to recover from a failed adapter. First, a set of
adaptations to run after the failure must be determined. Typical choices are the
8
original set of adaptations, a subset of the original adaptations, or a completely new
set of adaptations, including no adaptation at all. Secondly, the data flow must be
resumed at a suitable point to ensure correct functioning of adaptations and to
guarantee the semantics of the network service provided to the application (TCP
semantics, for instance).
The cost of planning adaptations in a general system is usually an expensive
task, so general systems try to resume data transfer as soon as possible without an
optimal plan. After adapter failure, most general systems either try to re-instantiate
the failed adapter or attempt to find a compatible subset of the already instantiated
adaptations to run, in hopes that a subset may solve enough of the network problems
to provide a reasonable network quality of service to applications. Then system can
amortize the re-planning and adaptation deployment costs over continuing data
transfer using the subset of adapters. Unfortunately, both of these schemes have
problems. It may not be possible to re-instantiate the failed adapter, as it may have
lost state necessary for correct operation. Additionally, determining a subset of
compatible adapters may be as complicated a computation as planning, and in many
situations a compatible and useful subset given the network conditions does not exist.
This situation can arise in situations where many adapters are composed together. In
Figure 3, Adapter AB receives data in type “A” and changes it to type “B”. If the
Adapter AB fails, all other adapters in the Figure are affected and can no longer run.
After a revised set of adapters has been chosen, the data flow must be resumed.
Retransmission from an intermediate point in the network is needed for two reasons.
Efficiency is the primary reason, we don’t want to retransmit from the sender as we
pay both latency and CPU costs for traversing many more nodes and running the
adaptations. Secondly, some stateful adapters may not have the ability to adapt the
same data twice. Therefore, retransmission may occur between adaptations on the
same node, requiring aggressive caching of data between adaptations and adaptation
nodes. Implementing retransmission between adapters requires addressing data with
a unit other than raw byte count [Yarvis00].
Failure of an intermediate adaptation node in a general system should not cause
connection failure. Simply routing around the failed is not enough because the
intermediate nodes now perform adaptation. All the adapters on the node have failed
as well, and one of the adapter recovery schemes above should be performed. The
selection of adaptations to run after node failure must also take into consideration a
possible change of network conditions as a result of the new data path, possibly
requiring a re-planning of adaptations.
9
Adapter AB
AB
Adapter BA
BC
Adapter BC
CB
BA
Adapter CB
Figure 3. Adapter dependency on previous adapters.
The endpoint model greatly simplifies recovery from both adapter and node
failure.
An endpoint network usually is not richly interconnected, and many times there
is only a single route from the host to the outside network. If any node on this path
should fail, it is safe to assume that any connection to and from the host would fail as
well. Adaptation nodes in the endpoint scheme are usually in this path, so their
failure can be considered an unrecoverable event. Therefore the only failure an
endpoint adaptation system should recover from is the failure of an adapter that does
not cause the whole adaptation node to fail.
After adapter failure, there may be some useful information on the node for use
in adapter recovery that would not be available if a whole node had failed in a
general system. First, the endpoint system knows exactly which adaptation has
failed. Secondly, there may be information still available on the node about progress
or state of the adapter.
These two pieces of information should make adapter re-instantiation much
easier for the system. If re-instantiation of the failed adapter is possible, then replanning is unnecessary. If re-instantiation is not possible, or the adapter repeatedly
fails, re-planning is required. Fortunately, the planning cost in a system with two
adaptation points is considerably less than in the general system with any number of
nodes.
The retransmission scheme may not benefit from the reduction in the number
of adaptation nodes, if we have to provide “exactly once and in-order” data
transmission semantics. The use of stateful adaptations that are instantiated on a perdata-segment basis requires us to begin retransmission between adaptations,
regardless of the adaptation system.
Difficult problems of reliability, such as retransmission after failure, still
remain an issue for endpoint adaptation systems. Despite these unavoidable
problems, the system should provide properties simplifying the types of failures and
aiding in recovery from these failures.
10
6.
SECURITY IN ENDPOINT ADAPTATION
Adaptation within open architecture systems presents challenging security
issues. Security must be maintained both at the adapting nodes, as well as end to end.
Popular adaptation models, such as proxy based adaptation and widely distributed
adaptation, are difficult to secure. End point adaptation simplifies the security
problems by offering flexibility of adapter selection, smaller boundaries, as well as
reducing the overall complexity of security negotiations.
6.1
Problems with Proxies
The proxy-based model is limited both from a scope of control perspective,
and from a flexibility standpoint. The proxy offers a single point of communication
for the client, one not necessarily under his or her control. Secure communications in
this framework requires negotiation with the proxy, possibly sharing insecure data
with the proxy. Work has been done to build indirect security via a proxy
architecture in which the proxy does not have access to plaintext information
[Fox96], however this solution requires the adoption of a single security architecture
(in this example, Kerberos [Kohl93]) and is not generally extensible.
If the proxy is trusted, and under the client’s control, security concerns
regarding proxy access to the data stream are mitigated. However, the proxy
architecture still limits the types of security adaptations that can be performed. Proxy
frameworks are typically designed to handle a single protocol, or set of protocols,
and make it difficult to add new security protocols, or encryption algorithms. When
communicating with foreign systems or agents, there is no coordination possible: you
either speak the correct algorithm or you do not, severely limiting the flexibility of
the system. These limitations make rapid deployment of new algorithms difficult –
requiring rewriting and replacement of the proxy infrastructure.
A third shortcoming with proxy approaches is the limitation in placement.
Proxies offer point-adaptation to a data stream. When used in a heterogeneous
network, multiple proxies may be required for secure communications. A typical
scenario might be a nomadic user with a wireless PDA attempting to access a web
page outside of her company. A proxy for the PDA would be required to secure any
data travelling wirelessly. This transmission would then require decryption to be
properly routed, and then an additional proxy would be required on the outside to
reencrypt and secure the link.
6.2
Drawbacks of Widely Distributed Adaptation
The other generally used approach, widespread distributed adaptation, offers
almost unlimited flexibility as to placement and choice of adaptations – this
flexibility however comes at the added cost of giving up control of the data flow to
11
outside nodes. When performing this form of distributed adaptation, adaptations are
placed into the network flow where they are needed. Most often, these nodes will be
outside of the control of the user. A decision must be made on whether or not to trust
the node – and if the node is trusted, how much it is trusted. Complete trust implies
that a node may have full access to the data stream – that is, the node may view and
alter the plaintext data. However, it’s likely that most nodes will not be completely
trusted.
A decision must then be made as to how to proceed if a node is not trusted, or
partially trusted. If a node is only partially trusted, it may only have access to a
portion of the data, or receive only encrypted data to work with. This limits the
adaptations that can be performed, but maintains a certain degree of security.
Clearly, trust management is a complex issue when nodes performing adaptations are
members of foreign domains over which the user has little or no control, and not
much is known.
6.3
Securing the End Point Adaptation Model
While both proxies and widely distributed adaptation have their disadvantages,
their advantages are compelling. If we can trust our proxies, or at least control them,
the client-proxy boundary is a very small system boundary to secure. Security can be
performed outside of our boundary exclusive of any interior security. Similarly,
widely distributed adaptation offers flexibility of adaptation and adaptation
placement. The obvious hybrid solution is end-point adaptation. A small local
cluster of nodes on either end of the data session provides our pool of nodes for
adaptation, keeping the area of adaptation well contained within a set boundary.
Simultaneously, there are multiple places for adaptation on either end, allowing
coordination among security adapters.
End point adaptation provides much needed flexibility, while keeping
adaptation within well-established boundaries. This model assumes that there is local
control over one adapting end, and the ability to negotiate with a remote end. A
useful security model that could be adopted would be to introduce a notion of user
and end domain authentication. The end point and the user both possess identifying
certificates, and through the use of both certificates, a user on the other end could be
sure that a data stream in fact initiated with a given user within a given end domain.
Within the domain, the user either has to trust the domain, or provide for security
within the domain through other means. Inter-domain adaptation however can be
secured through the use of authenticating and encrypting adaptations. If a data
stream requires a certain level of security, the user can specify in the negotiation
sequence. Since this scheme has significantly less complexity than the widespread
adaptation scheme, the negotiation is much simpler. If the receiving side will not
deploy the required security, the only remaining option is to abort the session.
12
End point adaptation offers significant simplification to hard security problems
by reducing the problem to a more manageable arena – local management of
adaptations and negotiation. The tradeoffs are clear – end point adaptation is less
flexible than widely distributed adaptation, and the security boundaries are a little
looser than a proxy system; however, for applications suited to end point adaptation,
the advantages make this scheme very attractive.
7.
CONCLUSIONS
Two models of open architecture systems have received attention recently,
single point adaptation systems, such as proxies, and widespread adaptation systems,
such as active networks. The first model offers simplicity and ease of deployment,
but may be too limited in capabilities to solve future network problems. While the
second model should be general enough to handle any situation, the deployment and
inherent complexities of the system limits its practicality.
As an increasing amount of network communication is peer to peer, an
adaptation paradigm derived from a user collaboration model is desirable. Cooperative endpoint adaptation offers many of the benefits of existing models, while
reducing the complexity of the overall system. It offers the ease of deployment and
practicality of single point systems while offering more flexibility through the cooperation of adaptation endpoints. Additionally, many of the hard problems of fully
general adaptive systems, such as planning, reliability, and security are greatly
simplified. Many of the benefits are derived from the reduction of adaptation nodes
in a connection, while other benefits are obtained from the unique properties of
deployment at the endpoints.
References
[Bluetooth] Bluetooth Specifications.
http://www.bluetooth.com/developer/specification/specification.asp
[Fox96] A. Fox, S. Gribble, “Security on the Move: Indirect Authentication
using Kerberos,” Proceedings of the 2nd ACM International Conference on Mobile
Computing and Networking (MobiCom ‘96), Rye, New York, November 10-12,
1996.
[Gnutella] Gnutella Specifications. http://gnutella.wego.com
[Kohl93] J. Kohl, C. Neuman, “The Kerberos Network Authentication Service
(V5),” Request for Comments (RFC) 1510, September 1993.
[Yarvis00] M. Yarvis, P. Reiher, G. Popek, “A Reliability Model for
Distributed Adaptation,” The Third IEEE Conference on Open Architectures and Network
Programming, Tel-Aviv, Israel, March 2000.
13