DFuse and Media Broker System support for sensor-based

DFuse and Media. Broker: System support for sensor-based distributed computing Kishore Ramachandran (http: //www. cc. gatech. edu/~rama) College of Computing Georgia Tech Colleagues: Rajnish Kumar, Bikash Agarwalla, Junsuk Shin, David Hilley, Dave Lillethun, Jin Nakazawa, Bin Liu, Xiang Song, Nova Ahmed, Seth Horrigan, Matt Wolenetz, Arnab Paul, Sameer Adhikari, Ilya Bagrak, Martin Modahl, Phil Hutto

Computing/Communication Continuum Sensor Network HPC resources High connectivity Low connectivity / Wireless Cameras, sensor nodes High Performance Computing (HPC) resources Ambient Computing Infrastructure

What does this enable? n Application context l l l n distributed sensors with varying capabilities control loop involving sensors, actuators rapid response time at computational perception speeds Sample applications l l l Video based surveillance Transportation Emergency Response i Collaborative search and rescue i Evacuation management l “Aware” Environments

Application Characteristics n n n n Physically distributed heterogeneous devices Interfacing and integrating with the physical environment Diverse stream types (low to high BW) Diverse computation, communication and power capabilities (from embedded sensors to clusters) Stream fusion/transformation, with loadable code Resource scarcities Dynamic join/leave of application components

Key Requirements Middleware l l l Programming infrastructure Distributed data fusion Stream data management Network Level l l Protocol stack Energy efficient routing Ambient HPC resources l Grid • Stampede • DFuse • Media. Broker Sensor. Stack Streamline

Stampede (TPDS 2003) n n Distributed programming system covering the continuum Temporal stream data transport Multilingual (C, C++, Java) program components sharing data abstractions Multiple platforms (x 86 -Linux, ARM-Linux, x 86 -Windows, x 86 -Solaris, Alpha-Tru 64) • put(ts, item) thread • get(ts, item) • consume(ts) Channel • many to many connections • time sequenced data • correlation of streams • automatic GC

Key Requirements Middleware l l l Programming infrastructure Distributed data fusion Stream data management Network Level l l Protocol stack Energy efficient routing Ambient HPC resources l Grid • Stampede • DFuse • Media. Broker Sensor. Stack Streamline

DFuse (ACM Sen. Sys 2003) n Future Sensor Networks l l n Today’s handhelds, gateways Ubiquitous high-bw sensors Collage Filter Cameras Challenges l l Overlaying the application onto the physical network Programming abstraction for data fusion Fusion Channel (a ‘Virtual Sensor’) Producers f() . . . (sensors or other fusion channels) Consumers (actuators or other fusion channels) Sink

Fusion ( Arg[ ]) Filter Cameras Collage Sink {. . Cost Function } Fusion Module Placement Module Resource Monitor, Routing Layer Interface Operating System Hardware DFuse functions: 1. Placement of fusion and relay points 2. Plumbing as required 3. Dynamic migration of fusion points

Status of DFuse n Fusion and placement modules implemented on top of Stampede l l n A prototype i. PAQ farm (simulating future sensor network) runs DFuse Stampede and DFuse available for downloads MSSN, a simulator for sensor networks middleware design guidance (Base. Nets’ 04, IJNM’ 05, Wolenetz’s thesis) l Available for downloads

Key Requirements Middleware l l l Programming infrastructure Distributed data fusion Stream data management Network Level l l Protocol stack Energy efficient routing Ambient HPC resources l Grid • Stampede • DFuse • Media. Broker Sensor. Stack Streamline

Media. Broker n An architecture for stream management l l A clearing house for sensors and actuators in a given space Stream registry, discovery, plumbing, sharing, Dynamic connection of sources (producers) and sinks (consumers) Dynamic injection, and safe execution of transformation code i Feature extraction, fusion l Dynamic sharing of transformations and streams

l Elements i Type server: stores data types, relationships, and transformation code i Transformation engine: allow safe execution of injected code on cluster nodes i Scheduler: manages workload, and allows prioritizing transformation requests i Data brokers: manages connections between producers and consumers Producer Consumer Producer Transformation Engine Data Broker Type Server Data Broker Transformation Engine Scheduler Transformation Engine Consumer Data Items Transformation Requests Transformation Code

What it enables n Dynamic instantiations and sharing of transformations

Media. Broker Status n Media. Broker V. 1 l l l n A subset of the functionalities Application example: Family intercom IEEE Per. Com 2004, PMC 2005 Media. Broker++ l l Currently under development Event. Web built on top

Key Requirements Middleware l l l Programming infrastructure Distributed data fusion Stream data management Network Level l l Protocol stack Energy efficient routing Ambient HPC resources l Grid • Stampede • DFuse • Media. Broker Sensor. Stack Streamline

Sensor. Stack n Adaptability Vs. Stackability of protocol layers l Adaptability deals with cross-layer data i A must for wireless sensor networks l Stackability deals with cross-layer functionalities i A must for modular design n Principle behind Sensor. Stack l Decouple data from functionalities

Sensor. Stack without Cross-layering Support Fusion requirement Fusion layer Neighborhood Information, Topology Application Data periodicity, Size, delay tolerance Fusion data transmission requirement Flood routing MAC Data transmission requirement AODV routing Link quality information, Neighborhood status change, topology Time Sync Service Time synchronization accuracy, accuracy requirement

Information Exchange Service (IES) Design Goals: 1. 2. 3. 4. 5. Efficient use of limited memory Simplifying information sharing interface Extensibility Asynchronous delivery of the information Complex event notification

IES Design n Data management module Stackability by using standard data interface l Publish/subscribe based shared memory system l Fully-associative cache for performance n Event management module Adaptability by notifying when to adapt l Complex event notification l Reactive memory access

DRE: Data request event RSE: Rule satisfied event DAE: Data available event EMM: Event management module

Sensor. Stack with Cross-layering support Implemented in Tiny. OS and i. PAQ Linux Initial results (increasing application lifetime) very promising

Application Lifetime Improvement with Cross-layer Information DFuse performance without Cross-layer information DFuse performance with Cross-layer information for role-migration

Key Requirements Middleware l l l Programming infrastructure Distributed data fusion Stream data management Network Level l l Protocol stack Energy efficient routing Ambient HPC resources l Grid • Stampede • DFuse • Media. Broker Sensor. Stack Streamline

Grid Infrastructure Media. Broker DFuse Stampede Sensor. Stack

Streamline (MMNC 2006) Scheduling problem n Input: l l n Output: l n Computation and communication requirements of various stages of a coarse-grain dataflow graph Application-specified constraints Current resource (processing and bandwidth) availability Resource specific constraints Placement of the stages of the pipeline on available HPC resources Performance criteria: l latency and throughput of the application

Streamline Scheduler S 0 S 2 S 1 S 3 Stage Prioritization {S 2 S 0 S 1 S 3} R 0 R 3 R 1 Resource Filtering R 2 {S 2 {R 0 R 2 R 3}} Resource Selection n n {S 2 R 0} Expects to maximize throughput by assigning best resource to most needy stage Additional policies concerning resources, applications, and local schedulers can be incorporated in the cost of a particular assignment

Streamline System Architecture n Results l l Outperforms condor by an order of magnitude for both compute and communication bound kernels, particularly under non-uniform load conditions Performs close to Simulated Annealing but at considerably low scheduling time (by a factor of 1000)

Streaming Grid n n n Streamline scheduler integrated into Globus toolkit Example of a mock traffic monitoring app as a service composition using Web Services Blue boxes are the Streaming Grid services

Demo

Demo Output (live if stars are aligned!) http: //www. cc. gatech. edu/~bikash/sgrid/trafficapp/ trafficapp. html n What is the takeaway? l l l Several technologies working together Service composition, Streamline scheduling, Web Services, Globus toolkit to process the video stream and show the output in the browser Streaming grid instantiates, connect, manages the streaming app

Computing/Communication Continuum Sensor Network HPC resources High connectivity Low connectivity / Wireless Cameras, sensor nodes High Performance Computing (HPC) resources Ambient Computing Infrastructure

Conclusions n Media. Broker l n DFuse l n distributed programming environment Sensor. Stack l n data fusion architecture Stampede l n stream transformation and typed transport engine Information Exchange Service for crosslayer support Streamline l Scheduling support for streaming apps on grid Media. Broker DFuse Stampede Sensor. Stack Streamline

Ongoing Work n n Programming tools Adaptive resource management l n Marrying grid computing and ubiquitous computing Wireless networking considerations l l l sensorstack energy efficient protocols mobility considerations

Web Links n n http: //www. cc. gatech. edu/~rama/stampede http: //www. cc. gatech. edu/~rama/up http: //www. cercs. gatech. edu/

Applause!!!

Sensor Networks n Current Sensor Network Nodes l l n Limited capabilities (Mica-2) habitat monitoring, vineyard monitoring… Recent trends l i. Motes 8 x radio, 4 x CPU, power++ l Telos motes >3 x radio, similar CPU & power n Future Sensor Network Nodes l l Today’s handhelds, gateways Ubiquitous high-bw sensors Source: CACM #47 -6 “The platforms enabling wireless sensor networks”, Hill, Horton, Kling, Krishnamurthy, 2004.

HPC resources Unix / Linux / XP cluster

Overlaying the fusion graph uncompress collage filter Fusion Applications : need hierarchical fusion support

Family Intercom n n A client tracking system used for Icombo selection ‘Colocated’ clients can perform mixing for N -way conferencing Clients connected via Media. Broker Type attributes include audio rate and buffer specs

Fusion Module Structure Management Producers Plumbing Issues Consumers . . .

Fusion Module Computation Management Dynamic embedding of user-specified fusion function Correlation and aggregation of input streams Fusion channel migration . . . f 1() f 2()

Fusion Module Computation Management Dynamic embedding of user-specified fusion function Correlation and aggregation of input streams Fusion channel migration Memory Management f 2(). . . f 1() f()

Fusion Module Error and Status management Failure / Latency hiding f 2(). . . f 1() f()

Placement Module User inputs the task graph S 1 S 2 Collage Filter S 3 Sources And, a cost function. Sink (Display)

Simple Solution ? n Why not push the fusion points towards its sources ? l. Data sources may be lying all around l. Fusion points may cause data expansionis dynamic l. Network

DFuse: Placement Module’s Algorithm n Three phases: 1. Naïve role assignment l Deploy task graph into the network l Start app at a designated root node and delegate task graph subtree roles to richest neighbors recursively 2. Optimization l Given anticipated application behavior (attributes in the task graph), perform rapid local decisions to adjust which node performs which role. l Decisions guided by application-provided cost-function 3. Maintenance l Monitor actual application behavior and perform less frequent optimizations given application-provided costfunction

Example Cost Function n MT 1 (Minimize Transmission Cost 1) Source 2 Kbps n 1 2 Kbps Source n 2 f() 1 Kbps Sink 2 Kbps • CMT 1 ( n 2, f ) = 9 kbps CMT 1 ( n 1, f ) = 6 kbps

DFuse: Cost Functions n MT 1 (Minimize Transmission Cost 1) Used in intuitive illustration slides l m input data sources (fan-in) l n output data consumers (fan-out) n MPV (Minimize Power Variance) l Attempts to keep the power of network nodes at similar levels. n MTP (Minimize Ratio of Transmission Cost to Power) l Attempts to keep the time for how long nodes can run a fusion function similar. n MT 2 (Minimize Transmission Cost 2) l Like MT 1, but allows role transfer when node power is below a threshold. l c(k, f) = cost of node k to perform role f t(x) = transmission rate of data source x hop. Count(i, k) = network hops between nodes i and k power(k) = remaining power at node k

Prototype DFuse Implementation n Goal l l n n Investigate utility of Fusion Point Migration will increase application lifetime, for constant Qo. S Hypothesis Implementation l l l n Fusion Module: ARM Stampede port Simulated placement module Interface for coupling, transmission monitoring Simple camera sources, fusion functions and sink Collage Filter

n Experimental Setup l l l 12 i. PAQ 3870 s in a “familiar 0. 6. 1” Linux based DStampede 802. 11 b “farm”. Only directly adjacent i. PAQs in the figure below are considered mutually reachable in 1 hop. Placement module run as a simulation of the distributed algorithm coupled to the farm via an extended fusion module interface Power usage is modeled to be linear to the number of application-level bytes transmitted across a farm hop (simple model)

Prototype DFuse Results: Transmission Cost over Time

Prototype DFuse Results: Variance, Role Transfers, Lifetime MPV vs MT 2 4 x less variance Migrations++ 70% lifetime MTP good variance good lifetime

Pervasive Computing with Media. Broker n Family Intercom and Sign Post l l l Being developed at Georgia Tech’s Aware Home Replacing a legacy hardware mixing system with a much more scalable system Integration with existing RFID and Vision based tracking system called Sign Post to enable rapid call dispatching and mobility-aware communication