Context Adaptation of Communication Stack: A Case Study of Morpheus

1
Context Adaptation of Communication Stack A Case
Study of Morpheus
COMPUTING DEPARTMENT

• Next Generation Middleware Group
• Rajiv Ramdhany
• r.ramdhany_at_lancaster.ac.uk
• Reading Group Presentation, 17th July 2006

2
Acknowledgements

• Slides covering the Morpheus middleware framework
  taken from Hugo Mirandas original presentation
  Context Adaptation of the Communication Stack,
  University of Lisbon.
• Some diagrams of Gridkits network overlays taken
  from Deep Middleware for the Divergent Grid
  paper

3
MotivationAdaptation in the communication stack

• Applications to run on wide range of
  heterogeneous devices
• Participant nodes on fixed, wireless
  infrastructured, adhoc networks
• to be able to design and deploy adaptive
  communication protocols that can be reconfigured
  according not only to the local context, but also
  to the context of the remaining remote
  participants.
• System context memory, power, ...
• Complex communication requirements e.g. in Group
  communication
• virtual synchrony,
• causal/total order,
• ...

4
MotivationExample

• Multicast
• No native multicast support and in WANs
• implement the multicast as a sequence of
  point-to-point messages
• Participants in LAN
• Usage of IP multicast gt better performance
• Infrastructured networks
• Fixed nodes act as replicators to save resources
  on mobile nodes
• Large scale network with high node density
• Use epidemic protocols to implement multicast
• Encryption
• Service Discovery

5
MotivationAdaptation in the communication stack

• The most adequate configuration
• Depends on
• system context Bandwidth, available battery,
  route length, networking capabilties etc.
• Bias the configuration and operation of protocols
  that run at each device
• Context of other participants network interface,
  neighbours
• E.g. Use protocols that exploit resources of
  fixed nodes in an infrastructured network
• Changes at run-time.
• Some aspects of context information e.g. network
  error rate can be unforeseen
• Retransmissions for low error rates otherwise
  FEC
• Run-time adaptation mandatory
• Needs to be agreed at the distributed system
  level
• Need for collection of context at each node and
  dissemination of context information to all nodes
• Context information dissemination could obey some
  group communication semantics
• Virtual synchrony
• Total order

6
Design choices

• Granularity Defines the number of protocols
  affected at each reconfiguration
• The entire stack
• Simpler, applied to monolithic implementations
• A single protocol
• Modular design
• Accurate tuning of individual protocol in stack
• Reconfiguration harder
• Balance local optimisation criteria of each
  protocol with optimisation criteria of entire
  distributed system
• Separation Defines who decides the new
  configuration
• The compositional unit
• Adaptation code embedded in protocol code
• E.g. TCP adaptation to observed network behaviour
• Harder to reuse reconfiguration policies in
  another context
• Impossible to apply global optimisation policies
  e.g. exclude a protocol from stack
• An external entity
• Reconfiguration code executed in an external
  component

7
Morpheus

• Proposes to reconfigure each protocol
  individually
• fine-grained reconfiguration of protocol
  compositions
• Reconfigurations are decided externally to
  protocols by a dedicated component
• Easier to apply global optimisation policies
• Composed of
• A protocol composition framework
• A context capture and dissemination component
• A reconfiguration manager
• Protocols

8
MorpheusComponents Overview
9
MorpheusComponents Overview Appia

• Modular protocol composition and execution
  framework developed in Java
• Layers interact through exchange of events
• Events are typed
• Each layer defines
• ? - events required to provide a correct
  execution
• ? - events layer willing to receive
• ? events layer generates
• Event routing
• QoS stack of protocol layers offering a QoS
• Channel stack of sessions
• Protocols may participate in more than one
  communication channel
• One session shared by multiple channels
• Easy construction of compositions at run-time
• Channel specification may be passed in run-time
  using XML files
• Useful for loading configuration at specific node

10
MorpheusAppia Protocol composition I

• Vertical composition

• Multi-channel (vertical) composition

11
MorpheusAppia Protocol composition II
Application
Total Order
Group Communication
Events bypass protocol, event routing
TCP
Atomic Broadcast Channel
Group Communication Channel
12
MorpheusComponents Overview Cocaditem

• Context Capture and Dissemination System
• Distributed component, composed of
• context retrievers at all nodes of the system
• a topic-based publish-subscribe component
  responsible for disseminating the collected
  information to the interested parties.
• Current implementation vsync Appia channel
• group communication control channel is used to
  coordinate all instances
• Each node multicasts in the control channel the
  locally collected context information.

13
MorpheusComponents Overview Core

• Control and Reconfiguration distributed
  sub-system, composed of
• Control component
• monitors the state of the distributed application
  and for coordinating the reconfiguration
• A set of local modules
• locally deploy a new configuration of the
  communication protocols when needed.
• Core components also coordinate using a group
  communication control channel
• Core uses the same vsync channel as Cocaditem to
  instruct remaining group members
• Responsible for
• deciding configuration changes and installing
  them
• Will need to agree reconfiguration with remaining
  participants
• Current implementation ? coordinator based (cf.
  centralised configurator)

14
MorpheusReconfiguration

• The coordinator
• decides the new reconfiguration
• instructs all participants to trigger a view
  change on their data channels
• Channels become in a quiescent state due to
  view-synchronous properties of the group
  communication protocol suite
• disseminates the new configuration for each node
• XML description of the relevant channels is used.
• Nodes install the new configuration and resume
  normal operation

15
MorpheusAdaptive Protocols

• The reconfiguration units
• Architecture allows for independent development
• A semantic for specifying their properties to
  core will be defined
• What properties they provide
• Adequate context combination
• Requirements and conflicts

16
MorpheusAdaptive Protocols e.g. Mecho

• Multicast Echo the proof-of-concept
• an algorithm for a best-effort multicast service
• is executed at the base of the group
  communication protocol suite
• broad range of services including reliable
  view-synchronous multicast offered on top
• Original multicast protocol
• Non-adaptive implements multicast as a sequence
  of point-to-point messages
• may also use native multicast if available
• Adequate for infrastructured networks with wired
  nodes
• In hybrid network scenarios
• Different behaviour required
• Protocol stack is extended with Mecho
• Wireless nodes forward multicast messages to one
  wired node
• Wired nodes replicate the message to all members
  of the group
• Transparent for remaining protocols

17
Protocol StackHomogeneous devices
18
Protocol StackHeterogeneous devices
19
Evaluation

• Multi-user chat application
• Executed in IPAQs 5550
• 802.11b network
• Jeode Java run-time
• 40000 msgs at 10 msg/s
• Savings in the number of messages sent by mobile
  nodes are almost proportional to the number of
  participants
• adaptive protocol is able to prevent the increase
  in load of the mobile node
• at the expense of an increase in the number of
  messages of the fixed node)

20
MorpheusSummary

• Different implementations of the same protocol
  are more adequate for different execution
  conditions
• Examples
• Multicast
• Total Order
• The most adequate composition
• Can only be known in run-time
• Should be automatically installed after
  negotiation with remaining participants

21
Further developments Policy-driven protocol
stack adaptation

• language for the specification of adaptation
  policies for communication protocol stacks
• Policies are sets of adaptation rules that follow
  a event-condition-action syntax
• When and With keywords rely on context models for
  interaction with context monitor
• Do keyword relies on protocol adaptation model
• Actions described in Do keyword are framework
  dependent
• Policy Driven Adaptation for Protocol Stacks,
  L. Rosa, A. Lopes and L. Rodrigues, University of
  Lisbon

22
Morpheus vs. GridKits Open Overlays I

• Modular protocol composition and execution
• Both Ensemble-inspired
• Reflective approach with MOP
• Stacking of overlays
• Protocol layer can be replaced at run-time by
  reconnecting receptacles of upper layer
• Separation of concerns forward, control, state
• Inter-protocol communication via events
• Components implement IDeliver to receive event
  notifications
• Components register interest via EventReceive()
• No static or typed events

23
Morpheus vs. GridKits Open Overlays II

• No channel-awareness
• Only 1 channel in overlays
• Difficult to specify different protocol stacks
  for one application
• No global reconfiguration manager for
  communication
• Application or middleware above are the drivers
• Adaptation triggered by sensed context
  information??
• No distributed coordination of reconfiguration at
  nodes
• Policy specification
• event-condition-action rules

24
Questions

• Thank You!