Support for Run-Time Adaptation in RAPIDware

1. Support for Run-Time Adaptation in RAPIDware Philip K. McKinley Software Engineering and Networking Systems Laboratory Department of Computer Science and Engineering Michigan State University (http://www.cse.msu.edu/sens)

2. Presentation Overview • MSU SENS Laboratory • RAPIDware Project Overview • MetaSockets and Experiments • Adaptive CORBA Template (ACT) • Conclusions

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 • Research sponsored by NSF, ONR, DARPA, DOE, NASA, EPA, and several industrial partners

4. SENS Personnel • Betty Cheng - software engineering, formal methods, object-oriented development • Laura Dillon - formal methods for concurrent systems, real-time systems • Phil McKinley - distributed computing, network protocols, adaptive middleware • Kurt Stirewalt - software analysis, interactive systems, model checking • Sandeep Kulkarni - fault tolerance, security • ~30 graduate research assistants

5. Mobile Computing Testbed • Multiple-cell WLAN • Various Wireless LANs • WLAN analyzers • Mobile computers • Dell laptops (Windows, Linux) • iPAQ handhelds(Familiar Linux, Blackdown Java) • Xybernaut MA-V wearables (Windows)

6. RAPIDware Project • Funded by U.S Office of Naval Research • Adaptable Software / Critical Infrastructure Protection • Outgrowth of Presidential Decision Directive 63 (May ’98) • Goal: Software (middleware) that can adapt to: • Changing environmental conditions • Hardware and software component failures • Possible security threats or violations • Heterogeneous platforms • Dynamic user requirements • RAPIDware involves: • 5 SENS faculty members and 10 graduate assistants • Middleware for “Internet Speed” development and evolution of applications must support: • Multiple dimensions of adaptability • Autonomous execution of middleware components • Dynamic composition of middleware services • “Principled” methods (compiler/language support, code generation, reflection, run-time checks, etc) needed to help ensure reliability, correctness, reusability, security

7. RAPIDware Goal... • Enable users to communicate seamlessly and securely across a diverse, dynamic, and evolving mobile computing and communication infrastructure. • Target domain is multimedia collaborative computing systems • military command and control • management of industrial installations • crisis management systems • computer supported cooperative work • Example: Enabling systems to operate through failures and attacks in network-centric battlefield.

8. Motivations Highly variable wireless channels, changing topology, frequent disconnections

9. Motivations Interaction with sensor networks

10. Motivations Military Operations in Urban Terrain (MOUT)

11. Motivations Collaboration among disparate platforms and networks

12. Key Challenges • Realizing tradeoffs among different cross-cutting concerns: • Quality of service • Platform characteristics • Security policies • Energy consumption • Fault tolerance • Adaptation of legacy code, separation of concerns • Safe adaptation of software (including dynamic composition) of software

13. Adaptive Middleware • Adaptive middleware can manage nonfunctional aspects of the system in coordinated fashion: • actively monitor the system, execute security policies • provide fault tolerance for specified components • adapt to changing environmental conditions • manage energy consumption in battery-powered devices • insulate the application from device/network differences • “Always On” systems • E.g., command and control, many critical infrastructure systems • require dynamic adaptation in ways not envisioned during development.

15. Separating Adaptive Behavior Host computer (wired workstation) Host computer (wireless laptop) Host computer (wireless palmtop) APPLICATION LAYER Application Application Application Adaptive Logic -- decision makers, event handlers, component loaders “core” middleware components MIDDLEWARE LAYER Proxy node (e.g., desktop) data paths observers responders NETWORK LAYER

16. RAPIDware Subprojects • Programming language abstractions for adaptation • Support for adaptation in legacy applications • Dynamic software composition • Safeness • Efficiency • Fault tolerance • Security • Adaptive group key management • Adaptive overlay networks

17. Domain-Services Tailored to a specific class of distributed applications Common-Services Functionality such as fault tolerance, security, load balancing and transactions Distribution Programming-language abstraction Host-Infrastructure Platform abstraction Applications Domain-Specific Middleware Services Common Middleware Services Middleware Layers Distribution Middleware Host-Infrastructure Middleware Operating Systems and Protocols System Platform Hardware Devices Middleware Layers • Schmidt decomposed middleware into four layers: Schmidt’s Middleware layers [2]

18. Part 1: MetaSockets • Adaptive Java (AJ): • An extension to Java that provides language constructs and compiler support for developing adaptive software. • MetaSockets: • An adaptable communication component developed in AJ • Can be used directly by applications or by higher-level middleware layers

19. Adaptive Java Background • Based on computational reflection • Adaptable Component Model: • Component: the basic building block that can be equated to adaptable classes (composed of invocations). • Meta-Object Protocol: a set of meta-level primitives (refractions and transmutations).

20. Adaptive Java Background (cont.) • Three-Dimensional Interfaces: • Invocations: normal component imperative operations. • Refractions: operations for inspecting components. • Transmutations: operations for modifying components. • Component Absorption and Metafication: AJ MetaMulticastSocket refraction base-level method replaced invocation base-level invocation transmutation insertFilter() receive() send() send() send() close() getStatus() joinGroup() close() close() leaveGroup() removeFilter() Java MulticastSocket AJ SendMSocket Base Component

21. MetaSockets • Provide low-level, adaptable communication • Example of host-infrastructure middleware

22. MetaSocket Internal Architecture MetaSendMSocket Internal Architecture: MetaRecvMSocket Internal Architecture: getStatus() getStatus() FP LP get() put() put() get() Fltr Fltr put() get() Filter Pipeline Filter Pipeline LP FP put() get() receive() joinGroup() leaveGroup() close() send() close() MT MT joinGroup() close() close() receive() send() SS RS insertFilter() removeFilter() insertFilter() removeFilter() invocation FP: firstPacketBuffer Fltr: Filter dependency refraction LP: lastPacketBuffer SS: SendMSocket packet flow direction thread transmutation MT: MetaSocketThread RS: RecvMSocket

23. MetaSocket Absorption Code public component SendMSocket absorbs java.net.MulticastSocket { /* constructor */ public SendMSocket(...) { setBase(new java.net.MulticastSocket(...)); } /* invocations */public invocation void send(...){ base.send(...); }public invocation void close(){ base.close(); } }

24. MetaSocket Metafication Code public component MetaSendMSocket metafy SendMSocket { /* constructor */ public MetaSendMSocket(SendMSocket sendMSocket) {setBase(sendMSocket); } /* invocation that "replaces" the send() invocation in SendMSocket */ public invocation void send(...) { ... firstPacketBuffer.put(packet); ... } /* refractions */ public refraction byte[] getStatus() { return filterPipeline.getStatus(); } /* transmutations */ public transmutation void insertFilter(int position, Filter filter) { ... filterPipeline.add(position, filter); ... } public transmutation Filter removeFilter(int position) { ... return filterPipeline.remove(position); } /* private fields */ private java.util.Vector filterPipeline = new java.util.Vector(); PacketBuffer firstPacketBuffer = new PacketBuffer(); }

25. . . . MetaSocket Evaluation • Audio Streaming Application (ASA) • MetaSocket is used instead of MulticastSocket • Live audio stream from a desktop to multiple iPAQs • Physical experiment configuration: Audio Stream Wireless Receivers Access Point Wired Sender

26. Audio Streaming to iPAQ Microphone Sampling Speaker Playing Java Sound New Defined Java Sound Method FEC Encoder FEC Decoder Recorder Player MetaSocket MetaSocket Java Socket Java Socket JVM JVM JNI C Sound Routine Sound Driver Linux Socket Linux Socket Sound Driver Operating System Operating System Wireless Channel Audio Stream Audio Stream

27. WLAN Error Characteristics • Most burst errors are very short • Small packets help to isolate errors • Well suited to use of block-based FEC

28. Block Erasure Code Operation • Wireless networks produce dynamic and location dependent packet loss because of signal strength, interference, antenna alignment. • 802.11b MAC layer does not provide link-level acknowledgement for multicast frames. • FEC can be used to improving reliability by introducing redundancy into the data channel.

29. Forward Error Correction Filters • MetaFECEncoder: a component in AJ that absorbs a FECEncoder class. • MetaFECDEcoder: a component in AJ that absorbs a FECDecoder class. getSrcPacketBuffer() getDstPacketBuffer() getNK() getSrcPacketBuffer() getDstPacketBuffer() getNK() FilterMismatchEvent FECMismatchNKEvent FE FD` start() stop() start() stop() setSrcPacketBuffer() setDstPacketBuffer() setNK() setSrcPacketBuffer() setDstPacketBuffer() setNK() (a) MetaFECEncoder (b) MetaFECDecoder dependency refraction invocation FE: FECEncoder FD: FECDecoder event propagation path transmutation thread

30. Performance (Emulated Losses) • FEC Filters inserted automatically at time 8, when loss rate exceeds 30%. • FEC Filters removed automatically at time 45, when loss rate drops below 10%. • Inserted again at time 60. • Removed again at time 80.

31. Performance (Real Trace) • Insert threshold: 10% • Remove threshold: 1%

32. Energy Management Baselining • Multimeter connected to iPAQs • Audio/video/data streams across wireless LAN • Measure energy usage, vary FEC parameters

33. Effect of FEC Parameters • Reception of parity packets (plus decoding) is major consumer of energy • Reference point: system shutdown at 860 mV

34. Software measurements… • Dynamically measure remaining battery life during earlier experiment • Periodically read from /proc/hal/battery

35. Exploiting Power-Save Mode • Periodically turn off WNIC for x * 100 ms • Does not affect loss rate, even for audio streaming • Major reduction in energy consumption

36. Part 2: ACT • MetaSockets provide a mechanism for low-level monitoring and adapting of communication streams. • How can we support adaptation that is “closer” to the application? • Adding new adaptive functionality to an extant application is complicated when: • the source code of the application is unavailable. • the source code is available but modifying it directly is undesirable. • the application is required to run continuously and cannot be easily taken off-line for upgrade.

37. CORBA Overview • Common Object Request Broker Architecture. • Distributed object framework by OMG. • Supports heterogeneous hardware devices, operating systems, network protocols, and programming languages. CORBA architecture [3].

38. Client Application Server Application Applications Client Servant Domain-Services Common-Services Stub Skeleton Distribution Client-Request Interceptor Server-Request Interceptor Client ORB Server ORB Host-Infrastructure System Platform Network request flow reply flow CORBA Portable Interceptors

39. Adaptive CORBA Template Adaptive CORBA Java Framework Adaptive CORBA C++ Framework Extended QuO Framework Adaptive CORBA Template (ACT) • Supports “unanticipated” adaptation in CORBA applications. • Enables dynamic improvements to CORBA applications in response to changes their requirements • Provides a generic model for constructing and enhancing adaptive CORBA frameworks.

40. Client Application Server Application Client Applications Servant Domain-Services Client ACT Core Server ACT Core Common-Services Client GI Server GI Distribution Client ORB Server ORB Host-Infrastructure System Platform Network GI: generic interceptor request flow reply flow ACT-Ready Flow

41. to/from the common-services middleware Client ACT Core Proxy Dynamic Interceptors Decision Maker Rule-Based Interceptor Event Mediator Client Generic Interceptor Client ORB to/from the host-infra. middleware request flow reply flow ACT Core Components

42. QuO (Quality Objects) Project • Long-running project at BBN • Quality Objects – add quality-of-service to remote method calls • Contracts to enforce quality-of-service • Clients use wrappers (delegates) to interact with QuO services • Qoskets – code for wrapper and associated QuO functionality • Requires modification of application code

43. Client Application Server Application Applications Client Servant Domain-Services Client Wrapper Server Wrapper Common-Services Contract SCs SCs Contract Client QuO Core Server QuO Core Distribution Client ORB Server ORB Host-Infrastructure System Platform Network request flow reply flow SCs: sytem conditions Typical QuO Operation

44. Client Application Server Application Client Applications Servant Domain-Services Client Wrapper Client- QuO Core Server- QuO Core Server Wrapper Common-Services Client ACT Core Server ACT Core Client GI Server GI Distribution Client ORB Server ORB Host-Infrastructure System Platform Network GI: generic interceptor request flow reply flow Extending QuO with ACT

45. Case Study: Surveillance App. • Using QuO “UserAdapt” qosket for dynamic adaptation

46. Surveillance Application • Choosing small images to save some bandwidth

47. Surveillance Application • Dynamic weaving of “UserAdaptFrameRate” qosket

48. Surveillance Application (5) • Choosing slow frame rate using the new qosket

49. ACT + QuO Evaluation • Evaluating the ACT overhead • Small overhead • Negligible performance effect

50. Physical Environment