Middleware Services for Context Sensitive Adaptation

1
Middleware Services for Context Sensitive
Adaptation

• Distributed System Middleware Group
• School of Information and Computer Science
• University of California, Irvine

2
Example Crisis Response
Context Collection
Recently funded large NSF ITR Responding to
the Unexpected, 12.5 million
3
Two Significant Issues

• Context information collection
• How to collect and manage context information
  (environment awareness) given
• Varying timeliness, accuracy, reliability
  requirements
• Changing Network conditions
• Heterogeneous data sources (sensors, routers,
  hosts)
• Dissemination of time-sensitive information to
  mobile groups
• Heterogeneous receivers
• Varying security and timeliness requirements
• Diverse device capabilities (power, memory)
• Information consistency in mobile groups
• The above in the presence of approximate location

4
Context Sensitive Middleware Services
Resource/Service Discovery in Grids/P2P
Networks (HPDC 2002,HiPC 2002, HiPC 2003)
QoS-based Resource Provisioning (ACM MMSJ 2003)
Quality-aware Query Processing (SPIE Imaging
2004, ACM SIGMOD Record 2004)
Power-aware Middleware (ICDCS 2003, ACM MM
2003, MWCN 2003)
Adaptive Communication (DOA02, ICAR03, AINS03)
5
Our work in Context Information Collection
QoS-based Resource Provisioning (ACM MMSJ
2003) Resource/Service Discovery in Grids/P2P
Networks (HPDC 2002,HiPC 2002,HiPC
2003) Quality-aware Query Processing (ACM SIGMOD
Record 2004) Power-aware Middleware (ICDCS 2003,
ACM MM 2003) Adaptive Communication (DOA02,
ICAR03, AINS03)
6
Information Collection Challenges

• Continuous stream of fast changing source data
• Diverse user requirements in terms of data
  accuracy and service timeliness
• Effective utilization of underlying computation,
  communication and storage resources
• Competing goals of
• Timeliness
• Accuracy
• Cost-effectiveness

7
Addressing cost-accuracy-timeliness tradeoffs

• Characterize the problem of providing timeliness/
  accuracy/cost tradeoffs in terms of Quality of
  Service (QoS), Quality of Data (QoD) and Cost
• Design a family of algorithms to support QoS and
  QoD, study the interaction between the
  algorithms, explore a judicious composition of
  the policies

8
Components of an Information Collection Framework
Information Source
Information Mediator
Information Consumer
source
consumer
source update request
consumer request

source
DS
DS
DS
consumer

source
9
Request Model
10
QoS Characterization
timeliness satisfaction deadline is met
QoS
accuracy satisfaction answer precision
requirement is higher answer fidelity is
1
11
QoS Characterization
timeliness satisfaction deadline is met
QoS
accuracy satisfaction answer precision
requirement is higher answer fidelity is
1
12
QoD Characterization
13
Problem Statement

• Given a set of sources Ss1,,sl and an Input
  instance I , which is a collection of m source
  update requests and n consumer requests
  ISR?CRsr1,,srmcr1,,crn, our goal is to
• Increase QoS
• Increase QoD
• Decrease Cost

14
Joint optimization of QoS, QoD and Cost

• Dynamicity
• Highly dynamic system and network condition
• Unpredictable application workload
• Frequently changing information sources
• Inter-relationship between QoS and QoD is not
  straightforward ?QoD ? ?QoS
• Prioritize source update requests
• ? QoD ? ? deadline miss ratio ? ?QoS missing
  opportunities
• Prioritize consumer requests
• ? QoS ? stale data ? ? QoD making wrong
  decisions

?
15
Our Approach

• Frame the tradeoffs as two sub-problems
• Manipulate QoS via a scheduling algorithm,
  assuming DS is well maintained (QoD)
• Adjust QoD via a DS maintenance algorithm,
  assuming an efficient scheduling algorithm is
  applied (QoS)

16
Design of the Information Mediator
Information Source
Information Mediator
Information Consumer
source
consumer
source


DS
consumer
source
17
Design of the Scheduling Algorithm

• Issues
• Decide on an ordering of the incoming source
  update requests
• The most recent update will be processed first
• Decide on a relative ordering of source update
  and consumer requests

18
Timeliness-Accuracy Balanced Scheduling (TABS)

• Assignment absolute deadline

• Apply Earliest-Deadline-First

• TABS schedulability
• Given a set of np periodic requests with
  processor utilization UP , a TB server with
  processor utilization UAP , the whole set of task
  is schedulable if UPUAPlt1.

19
Minimized Cost Directory Service Maintenance (MC)

• Analyze cost involved in the collection process
• Range adjustment
• Consumer-initiated update shrink the range
• Source-initiated update curve fitting

mw gt mw-1 increase range size
source value
mw lt mw-1 decrease range size
slope mw-1
fitted curve
time
w-1
w
monitoring window
20
Policies Studied
Timeliness-Accuracy Balanced Scheduling
TABS
First Come First Serve
FCFS
Consumer request First
CF
scheduling policies
Source update request First
SF
SU
Split Update
Real-time Information collection
OD
On Demand update
MC
Minimized Cost
SS
System Snapshot based
DS maintenance policies
SI
Static Interval based
TR
Throttle based
21
Experiments

• Performance metrics
• QoS, QoD, Cost (the number of messages exchanged)
• Efficiency of System EoS (QoS? QoD/Cost)
• Experiments
• Evaluation of all the possible policy combination
  in terms of the overall EoS
• Evaluation of system heterogeneity in terms of
  source capabilities and deadline variations
• Evaluation of benefits by adding intelligence
  into each sub-component of the mediator

22
EoS Comparison of All Policy Combinations

• TABS keeps a good balance between source update
  requests and consumer requests gt good QoS, QoD
• MC maintains the DS reasonably accurate while
  minimizing the cost

23
Performance Analysis of the best policy
combination
TABSMC provides higher QoD and also
significantly reduces the number of probes for
consumer requests
24
Benefits of Intelligent Policies
TABSMC
TABSSS
FCFSSS

• The EoS is improved as more intelligence is added
  to each component
• TABS ensure fairness among the requests
• MC decreases the DS maintenance overhead

25
Integrating Messaging and Monitoring

• Why?
• Exploit cross layer information for improved
  adaptation
• Knowledge of environmental parameters to trigger
  adaptive communication
• Knowledge of application needs to tailor
  collection process
• How?
• Identification of interaction parameters
• Shared abstractions

(IEEE Networks, Special issue on Middleware,
January 2004)
26
Adaptive Secure Group Communication in Mobile
Environments(work in progress)

• Sebastian Gutierrez- Nolasco
• Nalini Venkatasubramanian
• University of California, Irvine

Carolyn Talcott SRI International
Mark-Oliver Stehr University of
Illinois, Urbana-Champaign
27
From Peer-to-Peer to Dynamic Peer Groups

• What we have done
• Adaptive messaging
• Protocol composition
• Protocol- Service Composition
• Semantic Model for Adaptive Communication
• Based on the Russian dolls model
• Adaptive communication support for mobile
  autonomous robots
• Customize quality of video capture based on
  connectivity
• Extending to dynamic peer groups (SRI-UIUC-UCI)
• When and how often the information is needed?
• At what level of security, by what time
• Who and where are the receivers?
• Receiver power/resource profiles, approximate
  location
• How to disseminate the information efficiently?

28
Group Communication SystemsState of the Art

• Fault tolerance (Spread)
• Message delivery to groups with different levels
  of
• Reliability
• Reliable/FIFO/best-effort
• Ordering
• Causally/totally(agreed)/safe
• Dynamic membership
• Members can belong to several groups
  simultaneously
• Members can join/leave at any time
• Support for network partitions/merges
• Fault tolerance Security (Secure Spread)
• Secure Group communication
• Key management via contributory agreement

29
Spread Architecture

• Spread
• Ring protocol for local communication
• Hop protocol for non-local communication
• Provides extended virtual synchrony (EVS)
• Flush Spread
• Provides virtual synchrony (synchronization
  barrier)
• Cliques
• Implements key agreement protocols
• Secure Spread
• Uses Flush Spread to exchange Cliques messages
• Optimization for cascaded membership changes

30
Spread Example
31
New Challenges

• Highly dynamic membership changes
• Temporary changes due to connectivity
  fluctuations
• Voluntary changes due to application demands
• Current group rekey and membership change
  mechanisms block messages (at the application
  level) while in progress
• Large scale group support (100ltsizelt10,000)
• Non-uniform security and fault tolerance levels
• Mobile environments
• Minimal resource usage
• Bandwidth / security related computation
• Low latency rekeying/efficient key storage
• Interoperation among multiple transmission media
  (WLAN, Cellular, Satellite)
• Location/mobility

32
Transmission Range Effects
33
Addressing the New Challenges

• Continuous delivery of time-sensitive information
  demands no delays due to rekey or membership
  change
• Requires relaxed group semantics
• EVS Asynchronous (non-blocking)
• Better performance
• More efficient rekeying protocol
• Limit the number of computations required in each
  round
• Increase concurrency
• Integration
• EVS allows messages to float in the network while
  a membership change is in progress
• Multiple rekeys can overlap in time

34
More Efficient Rekeying

• Solution proposed by Yasinsac et al
• Round 1
• Members broadcast their DH public number
• Round 2
• Coordinator broadcast sufficient information, so
  members can compute contributory group key
• Eliminates sequential nature of GDH-style
  protocols
• We need formal specification
• Protocol correctness
• Make the assumptions explicit

35
Integration

• Solution proposed by Amir,Tsudik
• Tag every message with key_id
• What key was used to encrypt the message
• Members need to keep a list of old keys
• We need formal semantics
• Correctness
• Reason about interactions
• Generalization

36

Complications

• List of old keys may grow indefinitely
• When can we safely remove an old key ?
• There is no message floating in the environment
  encrypted with that particular key, and
• no member is using that particular key as the
  current key to encrypt messages
• Conservative partial solution
• Asynchronous snapshot to calculate residual
  messages
• Distributed over time and space
• Similar solutions for distributed termination
  detection and garbage collection

37
Further Aspects of Spread to Generalize

• Extend API with a notion of location
• Generalize current protocols to support large
  groups and mobile environments
• Ring protocol ? generalize sequential virtual
  token ring to a concurrent broadcasting scheme
• Hop protocol ? integrate handoff, mobility,
  broadcast cluster routing and overlapping
• Dynamic protocol adaptation on the basis of
• Network topology and capabilities (multiple
  channels, bandwidth,etc)
• Security levels
• Real-time constraints

38
Tying back to information collection

• Use various kinds of information gathered by the
  information collection framework
• Device information
• Power
• Connectivity (disconnectivity, barriers, caching,
  etc)
• Device location (approximate)
• Application characterization
• Environment information
• Density of nodes (in a region or sector)
• Communication availability
• (Logical) group characterization
• Spatial distribution
• Functional distribution (Requirements and how
  these are satisfied)

39
Our Integrated Architecture