Philip K. McKinley

1
Adaptive Middleware for Heterogeneous Collaborativ
e Computing

• Philip K. McKinley
• Software Engineering and Network Systems
  Laboratory
• Department of Computer Science and Engineering
• Michigan State University

2
Outline

• SENS Lab and Communications Research Group
• Summary of prior research activities
• Issues in anytime, anywhere, anyhow computing
• Ongoing Projects
• Pavilion web-based collaborative toolkit
• RAPIDware adaptive middleware framework
• Meridian automated development of distributed
  applications
• Summary

3
MSU SENS Laboratory

• The Software Engineering and Network Systems
  Laboratory supports research in
• software engineering
• distributed computing
• network protocols and real-time systems
• fault tolerance and security
• formal methods, code generation
• compilation/analysis of concurrent systems
• Six faculty members and their students
• Research sponsored by NSF, DARPA, DOE, NASA, EPA,
  and several industrial partners

4
Communications Research Group

• A research group within the SENS Laboratory
• Much of our research addresses the design and
  performance of multiparty applications,
  protocols, and services. Prior research
• Parallel processing
• collective communication in MPPs and NOWs
• Distributed Computing
• reliable multicast in Linux kernel and in NT
• Networking
• hardware-based flooding in ATM networks
• efficient leader election, routing protocols

5
Motivations for Current Work

• Anytime, anywhere data access and communication
  is quickly becoming reality, due to
• development of world-wide web
• large scale deployment of wireless services
• advances in handheld/wearable computers
• One class of applications that will likely
  benefit from this infrastructure is collaborative
  computing systems
• Examples CSCW, remote instruction, factory
  management, medical diagnosis, command and
  control
• Users will access services through a variety of
  network connections and computing devices

6
Example Scenario

• Remote collaboration among researchers

Same technology will also be used for everyday
collaboration among family members, etc.
7
Pavilion Project

• A Java-based middleware framework for
  web-oriented collaborative applications
• By default, provides collaborative browsing
• More importantly, supports development of new
  applications by reusing/extending components
• Reliable Multicast Protocol (WBRM)
• Web Browser Interfaces
• Leadership Protocol
• Extensible HTTP Proxy
• Plug-ins for thin clients
• etc...

8
Default Pavilion Operation
9
WBRM Protocol Architecture
Packets
In-order Resources
Resend Non-data
Re-ordered Resources
NAKs
Resend Data
RTT info
Echo messages
10
WBRM Performance

• Over 8Mbps throughput on 10Mbps Ethernet and
  around 50Mbps on 100Mbps Ethernet, depending on
  processors
• Performance approaches that of our Linux kernel
  protocol, H-RMC, with much less development effort

11
WBRM on 100 Mbps Ethernet

• Performance approaches that of our Linux kernel
  protocol, H-RMC, with much less development effort

12
Pavilion Proxy Servers

• Proxies can be used to provide transparent
  services to collaborative web-based applications
• Local proxies execute on client's local host and
  are typically used to enhance application
  functionality
• Remote proxies execute on other systems and
  enhance performance by tailoring data streams to
  match client capabilities
• A key design principle in Pavilion (and follow-on
  RAPIDware project) is to provide such services in
  the form of data- and application-specific
  plug-ins

13
Building Applications with Pavilion

• Pavilion may be extended by implementing
  application-specific plug-ins (loaders, filters,
  etc) for various proxies.
• Plug-ins used to perform the following tasks
• Distill data stream to reduce bandwidth
  consumption or client processing overhead
• Modify the web resources according to
  application-specific needs
• Wrap the resource in another file that is
  returned to the browser (used to load associated
  applet). Such applets can communicate with other
  participants via local Pavilion worker threads.

14
HTTP Plug-in Operation
Notify users
Browser Interface
Multicast to users
HTTPProxy
Request starts here
Filter
Loader
Filter
Browser Address Space
Application Address Space
15
Example VGuide

• VGuide is a Pavilion-based synchronous virtual
  reality tool
• leader selects (arbitrary) VRML world and guides
  other participants through that world
• Uses/extends several Pavilion components
• reliable multicast protocol to distribute VRML
  file and associated applets
• proxy server plug-ins to intercept file and
  wrap it in an html file containing an
  application-specific applet
• applets and worker threads to monitors viewpoint
  changes and multicast them to other group members

16
VGuide Demonstration
17
VGuide Component Overview
Leader Browser
Client Browser

• VRML plug-in to Http proxy wraps VRML file in
  html file with embedded applet
• Http proxy distributes VRML file and associated
  applet
• Applet uses External Authoring Interface (EAI) to
  access the VRML world
• Applet forwards viewpoint updates to VRML thread
  using socket
• VRML thread sends viewpoint updates to other
  participants using IP multicast

EAI Applet
EAI Applet
socket
socket
VRML Thread
VRML Thread
IP Multicast
Browser Interface
Browser Interface
VRML Plug-in
Http proxy
Http proxy
Reliable Multicast
18
Handling VRML Requests

• Requests for VRML files are intercepted by the
  proxy and passed to a plug-in
• As required by EAI, the monitoring thread must
  run in the same address space as the VRML browser
• HTML wrapper used to embed VRML file and applet
  into browser address space

EaiApplet
ltHTMLgt ltHEADgt ltTITLEgt VGuide lt/TITLEgt lt/HEADgt ltEMB
ED . SRC"world.wrl"gt ltAPPLET code"EaiApplet.cla
ss" . gt lt/APPLETgt lt/BODYgt lt/HTMLgt
19
VGuide Initialization Steps
Web Browser
Web Browser
Vrml.htm EaiApplet.class world.wrl
Vrml.htm EaiApplet.class world.wrl
Local Disk
Local Disk
Http//localhost1111/ltvrml.htm, world.wrl,
EaiApplet.classgt
Http//localhost1111/vrml.htm
EaiApplet
EaiApplet
Http///world.wrl
Main
Proxy
VRML Plug-in
Proxy
Retrieve .wrl file
VrmlThread
VrmlThread
Web Server
Pavilion (leader)
Pavilion (client)
20
Platform Heterogeneity

• The time needed to read/modify object in a VRML
  word varies on each machine.
• Time to modify an object depends highly on video
  adapter performance
• Time to read an object depends on CPU speed.
• Presence of heterogeneous participants could lead
  to high jitter and buffer overflow.
• Updates filtered by proxies for slow clients in
  order to improve performance

21
Jitter Results

• Jitter measured over 500 consecutive viewpoint
  updates
• On slow receivers (upper figure), jitter is
  higher (50 ms avg) because viewpoints accumulate
  at the receivers buffer.
• On fast receivers (lower figure), jitter is lower
  (0.33 ms avg) because receiver can keep up with
  sender.
• Recent tests show we can obtain low jitter (near
  zero) in both cases by having proxy discard
  viewpoints that arrive too close together.

22
Pocket Pavilion Subproject

• Goals
• To design a web-based application that extends
  collaborative browsing to wireless handheld
  computing platforms running Windows CE
• To demonstrate reuse of Pavilion components in
  supporting heterogeneous clients
• To evaluate the performance of using a wired
  proxy on behalf of wireless clients
• Key issue accommodating limitations of handheld
  PCs and the Windows CE environment

23
Handheld/Palm-Sized PCs

• No disk, only ROM and RAM
• Can be connected to a desktop to synchronize data
• Run PalmOS, Windows CE, ...

24
HP 620LX/660LX Handheld PC

• 75MHz RISC processors (Hitachi SH-3)
• Display
• 256-color LCD
• 640240 pixels on screen
• 32MB/16MB RAM
• Card Slots
• One PC card type II card slot
• One CompactFlash type I card slot
• Ports
• One RS-232C serial port
• One IrDA port
• Battery
• Rechargeable Lithium-Ion Battery
• CR2032 coin-cell backup battery
• Windows CE 2.0

25
Windows CE

• Modular, real-time OS for embedded and dedicated
  systems
• Written in C
• Delays are bounded
• Many modules are optional

26
Windows CE Characteristics

• Limitations
• At most 32 processes can be running concurrently
• Pocket IE supports only HTML and embedded images
• Supports only a subset of Win32 API
• Version 2.0 does not support IP multicast
• No DDE support, COM is only partially supported
• Programming Environments
• Visual C, Visual Basic and Visual J
• Third-party support for Basic and C
• All of the above use cross-compilers

27
Experimental Configuration
28
Implementation Issues

• Programming Language
• Pocket Pavilion Client Visual C
• All other parts of Pavilion are written in Java
• Inter-process Communication
• No DDE support
• COM not supported for Pocket Internet Explorer
  (PIE)
• Hence, we use native windows messaging for
  communication between the PP client and PIE
• IP Multicast support
• Windows CE 2.0 supports a subset of WinSock 1.1
  (no IP multicast support)
• Hence, we use unicast channels for communication
  between the proxy and the H/PCs
• Proxy performs data caching services in order to
  improve performance

29
Pocket Pavilion Operation
30
Performance small files
31
Sample Performance
32
Performance large files
33
Performance Near Cell Periphery
34
RAPIDware Project

• Extends Pavilion by addressing automatic
  instantiation and adaptation of the middleware
  layer
• Key objectives
• Automatically accommodate heterogeneity of among
  computing devices and network connections
• Adapt to failures, changes in channel quality,
  etc.
• Provide support for reuse of middleware
  components
• Offer a unified methodology for three types of
  adaptation communication services, user
  interfaces, fault tolerance
• Observers monitor system and detect changes
• Responders handle such events by instantiating
  new components or changing their behavior

35
Adaptive Component Interaction
36
Pavilion/RAPIDware Subprojects

• VGuide is a synchronous collaborative virtual
  reality tool
• Pocket Pavilion extends multicast-based
  collaborative browsing to wireless handheld PCs
• Proxy-based adaptive forward error correction for
  video/audio streaming, as well as reliable
  multicasting,

37
Subproject Adaptive FEC for Reliable
Multicasting on WLANs

• Forward Error Correction (FEC) can be introduced
  at a WLAN proxy to mitigate potentially high
  packet loss rates
• Losses among multiple receivers in WLANs are
  often uncorrelated, since they depend on the
  distance from the access point and environmental
  conditions
• Objective experimentally evaluate effectiveness
  of proxy-based FEC on multicast data streams in
  WLANs, and explore how to adapt FEC to changing
  conditions
• Proxy runs two instances of protocol, one tuned
  for wired network, and one tuned for wireless
  network

38
Experimental Environment

• Computing Platforms
• SMP Workstations/PCs (Sun, Dell), Laptops (Dell
  Latitudes), Handhelds (HP 620, 660)
• Networks
• Switched Ethernet and Fast Ethernet
• Three WLANS Lucent WaveLAN (2 Mbps), Proxim
  RangeLAN2 (1.6 Mbps), Cisco/Aironet WLAN (11 Mbps)

39
WLAN Loss Characteristics

• Traces in our testbed showed that, while large
  burst errors can occur, many burst errors are
  very short (usually 1 packet)

40
Receiver Throughputs without Proxy and with Proxy
41
(n,k) Block Erasure Codes

• Divide data (audio) stream into groups of k
  packets
• For each group, send k data packets and n-k
  parity packets
• Receipt of any k packets enables reconstruction
  of data

42
FEC Proxy Design

• Reuses several classes from WBRM protocol
• Adaptive components operate as plug-in modules

43
Proactive Parity Transmission

• In the presence of high losses, it usually takes
  multiple NAKs (and hence RTTs) to correct losses
  in a group since the correction packets
  themselves are susceptible to losses
• Sending immediate redundant information along
  with the data and NAK responses may help in
  solving this problem
• Can adjust proactive rate a proportionally to
  loss rate
• Experiments show that throughput is less affected
  by an over-estimate of the proactive parameter
  than by an under-estimate

44
Adaptive FEC Parameters

• a - Proactive percentage
• amin Minimum value of a
• ainc Amount by which a is increased based on
  the feedback information from receivers
• M scale factor used to increment a
• adec Amount by which a is decreased based on
  the feedback information from receivers
• W Number of groups after which a is decreased
• G FEC group identifier
• LC Number of packets lost in a group G
  (obtained from NAKs)

45
Results for Fixed a
46
The Adaptive Algorithm

• Initially a amin
• While transmitting a group of k packets, the
  proxy also immediately sends ka parity packets
• In response to a NAK of the form (G, LC), the
  proxy
• sends LC(1a) parity packets
• sets ainc M LC/k
• sets a a ainc
• If there are no NAKs for a period of W groups,
• set a a - adec

47
Evaluation of the Adaptive FEC Algorithm

• Based on our observations, ainc needs to be
  sufficiently large to reduce further NAKs and
  increase throughput
• We can afford a larger value of M as opposed to a
  smaller value that under-estimates the value of a
• But a large M may result in reduced bandwidth
  efficiency through unnecessary traffic
• To control losses, some of our tests use
  emulation. Others use experimentation on our
  testbed.

48
If W is too low...
M3, W3, loss20
M2, W3, loss20
49
Changing the value of M
M3, W10, loss20
M2, W10, loss20
M4, W10, loss20
50
Results with M3, W10
5 loss
10 loss
20 loss
51
Sample Results (Emulation)
5 loss
10 loss
20 loss
52
Accommodating Burst Losses

• Many losses in wireless networks occur in bursts
• The bursts seem to be clustered around adjacent
  groups for short periods
• A desirable decrement function would be one that
  starts decreasing slowly and then decreases
  rapidly over time
• We use an adec 2i 0.02 as the decrement
  function after W (10) groups where i (number
  of consecutive groups without NAKs) / W

53
Sample Results (Experimental)
adec0.02
adec2i(0.02)
adec2i(0.02) lower bound 1
54
Throughput Results

• Emulated loss rate varied up to 0.20
• Compared no FEC, static FEC, adaptive FEC

55
Subproject Mobile Composable Filters

• Questions
• can we apply mobile agent concepts to
  instantiation and population of proxies?
• Can we dynamically insert filters into running
  communication streams without disruption?
• Goal identify and evaluate glue mechanisms
  needed for dynamic construction of lightweight
  proxies in which components are created,
  migrated, composed as necessary to accommodate
  heterogeneous and dynamic environments
• Example proxy services FEC, filtering, web
  clipping

56
Proxy Framework

• Mobile Composable Filters enable proxy filters to
  be uploaded and dynamically inserted into
  (running) data streams

57
The Classes

• To facilitate the making and breaking of data
  flow inside the Proxy Container two new classes
  were created
• DetachableInputStream
• DetachableOutputStream
• These streams have all the methods available in
  PipedInputStream and PipedOutputStream classes of
  the Java2 API.
• They also have additional methods that allow us
  to handle diverse data streams.
• The ControlThread communicates with a
  ControlManager and implements the proxy
  management.
• The ControlManager class serves to control the
  proxy framework remotely. It can be easily
  integrated to a browser.

58
DIS/DOS Interaction

• Similar to other Java I/O streams, except that
  they can be paused, reconnected, restarted

59
Filter Configuration
Filter Code
DIS
DOS

• The DIS and DOS are setup by the ControlThread.
• The developer writes filter code that gets its
  input form the DIS and sends output to the DOS.
• Otherwise, no restrictions on the developer.
• All filter writers extend the Filter interface
  and also use the setDIS and setDOS methods that
  define the DIS and DOS to the filter

60
Remote Code Control

• A Control Manager provides an interface to the
  system and interacts with a Control Thread on the
  proxy
• The current framework uses simple serialization
  to enable filters to be remotely instantiated on
  a proxy
• The Control Thread has methods to handle the
  following tasks
• Indexed filter insertion and removal
• Remote filter reception
• Generation of a map of the current system
• A cache of available filters, based on a custom
  FilterContainer class

61
Screen Shot of Control Manager
62
Current Status
Web Location
Control Manager
Internet
Mobile Device
F4
Wireless link
Local Proxy Host

PROXY
Control Thread
Socket Thread I/P
Socket Thread O/P
F1
F2
F3
F4
63
Current Status

• Presently, we are refactoring various Pavilion
  proxy filters to work within the new framework
• Example FEC insertion in video streams

64
Meridian

• Large multi-investigator project supported by NSF
  grant
• Goal Develop an end-to-end, integrated set of
  tools that automate the development and
  maintenance of interactive distributed
  applications
• Case studies from several industrial partners
  involving on-board control, web-based
  collaboration, mobile telecommunications

65
Interactive Distributed Applications
Interact with users processing/data distributed
across network.

• Examples
• On-board driver/pilot navigation systems.
• Computer-supported collaborative work
  environments.
• Distributed interactive simulation.

66
Characteristics of IDAs

• Interactivity
• Must interact with one or more human users.
• Design requires prototyping and experimentation.
• Concurrency
• Comprise levels of communicating, concurrent
  components.
• Analysis requires formal reasoning.
• Reuse
• IDAs built primarily from reusable components.
• E.g., comm. protocols, resource managers, data
  displays.
• Design involves selecting/specializing components.

67
Research goals

• Improve quality of IDAs.
• Better IDAs (reliable, maintainable, extensible).
• Better development (faster, cheaper).
• Advance state of automated software-engineering
  (ASE) practice.
• Incorporate ASE techniques into mainstream
  development.
• Apply various formal methods in a new domain.
• Identify end-to-end automation techniques that
  take advantage of multiple phases of development.

68
Practical goals

• To have techniques adopted in practice
• Must complement existing design methods and
  notations.
• Otherwise, acceptance must overcome stiff
  economic hurdles.
• Implications
• Designers should not reformulate designs in a
  formal notation.
• Designers should not have to view the output of a
  formal analysis tool.
• We chose (UML) for representing IDA designs.

69
Meridian Methodology

• Developers create UML models of system
  components, based on requirements, using Model
  Editor, which also produces formal specifications
• Formal specifications analyzed for correctness,
  temporal consistency, deadlock freedom, race
  conditions, etc
• OO code synthesized from specifications, inserted
  into reuse framework
• Code input to emulators/simulators for
  performance testing
• Continuous feedback in terms of original
  requirements

70
Meridian Vision
Refined Specifications
Design Processing
Specifications
Specification Analysis
Testing/ Simulation
Model Editing
Code
Requirements
Feedback
User
Test Cases
71
Enabling Technologies

• Formal representations throughout development
  process
• facilitates requirements analysis and
  traceability,
• enables reasoning about concurrency properties,
  and
• supports reuse.
• Visualization insulates designers from formal
  representations.
• Code generation/selection synthesizes systems
  from models.
• Simulation/prototyping tests non-functional
  requirements
• (e.g., usability, responsiveness, etc.)

72
Model Editor

• Supports editing of UML models.
• Incorporates reusable IDA models.
• Generates formal representations of the models
• Supports automated analysis of graphical models

73
Reuse Environment

• Supports browsing/selection from reuse
  repositories.
• Component-based
• Index components by formal specs
• Search and retrieve based on specs

74
Tool suite (contd)

• Temporal Analyzer
• Augments UML models with temporal constraints.
• Graphical spec of timing constraints
• Design Processor
• Automatically refines UML models.
• Generates code and selects reusable components
• Adapts components to satisfy interface
  constraints
• Checks consistency between refinements

75
Emulation/Simulation of Synthesized Components

• MX simulator supports emulation of code identical
  to that used in experiments, via a socket-level
  system call interface
• Provides both C and Java APIs

Process Thread Placement Module
Application Code
Host/Network Configuration File
Network Module (Routing Domains, Wired/Wireless
Channels, Routers, Wireless Access Points, etc.)
76
Case studies

• Web-based multiparty applications
• WebClass/Pavilion web-based collaborative
  environment
• NetMapper network management utility.
• On-board control systems
• Automotive applications (e.g., cruise control,
  steering)
• Fault protection system (NASA/JPL).
• Wireless telecommunication services
• Emergency telecomm services implemented over a
  digital radio infra-structure.

77
Overview of talk

• Interactive distributed applications (IDAs).
• Goals and vision.
• Proposed research.
• Validation and contributions.

78
Validation and deliverables

• Validation through extensive case studies.
• Each case study comprises two parts
• Definition existing application guides tool
  development and repository population.
• Validation test framework on a different
  application.
• Deliverables in three increments
• Core suite of tools validated on Web-based
  multi-party apps.
• Incorporate on-board--control domain.
• Incorporate wireless-telecom domain.

79
Meridian Contributions

• Automates end-to-end development of IDAs
• Extends visual development to encompass formal
  reasoning.
• Supports reuse at many levels of abstraction
  using a common notation UML
• Integrates formal analysis and testing/simulation.
  
• Enables tracing of requirements from diagrams to
  code
• Facilitates evolution of software to accommodate
  new technologies
• Holds promise of Internet-Speed development.

80
Summary

• Pavilion (present) focuses on communication
  protocols for interconnecting heterogeneous
  mobile nodes and on reuse of collaborative
  components
• RAPIDware (short term) seeks to develop a
  unified methodology for design of adaptive
  middleware and automate its operation
• Meridian (long term) seeks to automate many
  aspects of the development of interactive
  distributed applications in order to improve
  their quality and maintainability

81
Related Work

• Groupware Toolkits
• JETS, Promondia, TANGO, Habanero, DISCIPLE,
  MultiTel, and others
• Adaptive Middleware Frameworks
• Rover, TAO, MCF, DaCapo, Odyssey, QuO,
  Mobiware, Remulac, Sync, MOST, Limbo, ...
• Configurable Proxies
• Transend, MPA, Mobiware, Alpine, Active Names,
• FEC for multicast
• RMDP protocol (Rizzo and Vicisano, 1998
• NP (Nonnenmacher et al., 1998)
• ECSRM (Gemmell, et al. 1998)

82
Related Work (FEC Multicast)

• RMDP protocol (Rizzo and Vicisano, 1998)
• hybrid FECARQ with parameters set according to
  network type
• expansion factor D is similar to a, except that a
  applies to all transmissions
• adaptation handled by changing (n,k) values
• NP (Nonnenmacher et al., 1998)
• integrated FECARQ protocols, targeting
  Internet-wide applications
• minimizes number of parity packets sent, at
  expense of latency
• pipelining to improve throughput, as does
  W-WBRM
• ECSRM (Gemmell, et al. 1998)
• FEC and global NAK suppression for Internet
  telepresentations
• no adaptation to changing conditions

83
Ongoing/Future Work

• Studies of FEC applied to live audio streams (ACM
  MM00) and video streams (IEEE MNS01)
• Design of interfaces for composable proxy filters
  (IEEE WNMC01)
• Further study of the various parameters in the
  adaptive FEC algorithm through experimentation
• Development of a simulator, MX, to study
  performance of communication protocols in
  wireless and other environments
• Study of extensions and scalability of the proxy
  through simulation

84
Further Information

• Project descriptions, including related papers
  and technical reports, are available at
• Email address mckinley_at_cse.msu.edu
• This research was supported in part by National
  Science Foundation grants DUE-9551180,
  CCR-9503838 CDA-9617310, NCR-9706285, and
  CCR-9912407, and EIA-0000433.

http//www.cse.msu.edu/mckinley