Mr. Fusion A Programmable Voting and Data Fusion Middleware Subsystem with a Tunable Statistical Profiling Service

1. Mr. FusionA Programmable Voting andData Fusion Middleware Subsystem with a Tunable Statistical Profiling Service Prof. Dave Bakken Prof. Curtis Dyreson Andy Franz Radek Mista School of Electrical Engineering and Computer Science Washington State University Pullman, Wash. USA www.eecs.wsu.edu © 2002 Dave Bakken: Mr. Fusion

2. Prologue: DSN-2002 • Uncle Jay Wants You! • Late June, DC area • Fast Abstracts are Still Possible! • www.dsn.org © 2002 Dave Bakken: Mr. Fusion

3. Motivation • Voting: choosing/creating one reply from many • Collation and Data Fusion are more general than voting • Not necessarily replicated servers • Values not necessarily supposed to be identical • Seems to be a fundamental pattern in distributed systems • Defintions • Ballot: an input to voting or data fusion (e.g., replica’s reply) • Vote: choosing/creating one ballot from multiple • Fusion session: same as vote, but for more general data fusion © 2002 Dave Bakken: Mr. Fusion

4. What is Needed • Middleware support for voting and data fusion • Allow voting on any parameter or combination of them • Separate voting/fusion language for reuse, analyzability • Hooks to allow changing of algorithms at runtime • Manager to provide client transparency • Not byte-by-byte voting • Applies to more than voting: collation & data fusion • Intrusion detection: multiple different probes monitoring a host/LAN/domain • Combine inputs in flexible and adaptable way • Assign weights for application data fusion based on IDSs • Ad hoc mobile network protocols • Distributed sensor networks • Parallel neural nets to estimate power grid margins • Hierarchical resource monitoring and aggregation © 2002 Dave Bakken: Mr. Fusion

5. Outline of Presentation • Overview of voting, collation, and data fusion • Current middleware voting: limitations & their architectural implications • Mr Fusion • Fusion Virtual Machine • Fusion Status Serivce © 2002 Dave Bakken: Mr. Fusion

6. Limitations of Byte-by-Byte Voting • CORBA provides interoperability across • CPU architecture • Operating system • Programming language • ORB (vendor) implementation • CORBA’s “wire protocol” CDR: • Uses IEEE 754 encoding for floating point values’ transmission • But with different architectures (and other 3 variables same) can have different internal precisions and roundoff differences … • Some Pentium models have HW rounding switch • Thus all 4 above can be same, but still values diverge! © 2002 Dave Bakken: Mr. Fusion

7. Byte-by-Byte Limitations (cont.) • Have to look at the IDL to be able to handle • Variable-length header information which an ORB implementation may fill in or leave out • Otherwise alignment off • Example: system context • CORBA spec states value of padding bytes is undefined, anyway! • Byte-by-byte voting in practice: • Developers have no problems in lab or single LAN, because very homogenous (CPU, OS, language, ORB) • When fielded or released, mysterious bugs start to show up because much more heterogeneous • This is true for all middleware, not justCORBA! © 2002 Dave Bakken: Mr. Fusion

8. Ideal: Reality: Middleware Middleware TCP Secure Secure Reliable Reliable Multicast Multicast marshal IP IP  No clean layering: transport needs help unpacking data for value check! Byzantine Architectural Implications • Additional result: byzantine reliable multicasts • Cannot do value checking without help! (if heterogeneity) • (except from single int perhaps) • Applies to Rampart, “Practical” (MIT), … © 2002 Dave Bakken: Mr. Fusion

9. Outline of Presentation • Overview of voting, collation, and data fusion • Current middleware voting: limitations & their architectural implications • Mr. Fusion • Fusion Virtual Machine • Fusion Status Service © 2002 Dave Bakken: Mr. Fusion

10. Baseline: Voting VM 2.0 (see DSN-01) • VVM performs voting on application-level data • First to not use byte-by-byte voting that we are aware of • Embeddable into CORBA, DCOM, other kinds of middleware (MOM, publish-and-subscribe, XML-RPC, ...) • Voting module thus not embedded in the application • Could be used by a application directly if desired • Voting definition Language (VDL) allows the coding of portable, reusable, stand-alone voting algorithms • http://www.eecs.wsu/edu/~bakken/VVM-DSN2001.pdf • Limitations/Lessons • Goto/Branching very complex and expensive • Multi-dimensional (multi-parameter) support needed © 2002 Dave Bakken: Mr. Fusion

11. Mr. Fusion • Middleware support for voting and data fusion • Main parts: Fusion VM and Fusion Status Service • CORBA used for all external interfaces • Java implementation currently • Fusion VM: • Next generation Voting VM … • Fusion Status Service • Monitors “potential” timing (appl-level) value errors • Aggregates over ranges of temporal and spatial scopes • Subscribers can get callbacks when thresholds crossed • Query interface for interactive drill-down and roll-up © 2002 Dave Bakken: Mr. Fusion

12. Only One in VM Quorum Evil Goto Timeout in the policy There are many in VM Wrappers Retry Timeout outside of the policy Multidimensional Exclusion & Collation Voting VM Policy Vs. Fusion VM Policy © 2002 Dave Bakken: Mr. Fusion

13. Mr. Fusion Architecture Fusion VM: Left Half © 2002 Dave Bakken: Mr. Fusion

14. Fusion Core © 2002 Dave Bakken: Mr. Fusion

15. Retry & Failure • The Retry restarts a Fusion Session. • It can be signaled by a policy. • It can be signaled by the Policy Runner • It can be signaled multiple times. • A policy can declare Failure • Should not be called again this fusion session © 2002 Dave Bakken: Mr. Fusion

16. Outline of Presentation • Overview of voting, collation, and data fusion • Current middleware voting: limitations & their architectural implications • Mr. Fusion • Fusion Virtual Machine • Fusion Status Service © 2002 Dave Bakken: Mr. Fusion

17. Fusion Status Service (FSS) • The FSS builds, maintains, and manages, a database of fusion session information • Why: FVM maintains useful information on • Potential Value Errors (at application level) • Potential Timing Failures • How: Temporal database • Subscribers subscribe to conditions over multiple fusion sessions • Callback when condition triggered • Examples: • Group Membership: expel if “too late too often” over a window • Security system: suspect problems if “too many bad values” over a window © 2002 Dave Bakken: Mr. Fusion

18. FSS as a Temporal Database Data cube is a multidimensional hierarchy of aggregate values with values higher in a hierarchy being aggregations of those lower in the hierarchy. © 2002 Dave Bakken: Mr. Fusion

19. Dimensions of the Data Cube • FSS Data Cube has three dimensions: • Source ID • Status (too late…) • Time © 2002 Dave Bakken: Mr. Fusion

20. Configurable+Hierarchical Categories • Example Category: Replication ID • Categories flexible, specified by text input © 2002 Dave Bakken: Mr. Fusion

21. Conclusions • Mr. Fusion support data fusion and its synthesis • CORBA used for all major module interfaces • Fusion VM • Programmable data fusion and voting algorithms • Fusion Status Service • Aggregates potential value and timing failures over multiple temporal and spatial scopes • Subscribers get callbacks based on threshold conditions • Status • DSN-2002 Software Demo Paper, June 2002 • Deliverable August, 2002 © 2002 Dave Bakken: Mr. Fusion

22. Backup Slides © 2002 Dave Bakken: Mr. Fusion

23. VVM/FVM and Fault Tolerant CORBA • FT-CORBA not required to tolerate value faults • Placeholder replication style ACTIVE_WITH_VOTING defined but not yet specified • Spec could allow a customizable voter module, but unlikely • All replicas of an object must be hosted by infrastructure from same ORB vendor • Could zero out padding bytes and rely on this • Thus byte-by-byte voting could work on integer types • Would still have to deal with floating point (inexact voting) • VVM/FVM + FT-CORBA??? • “You’re dead if you standardize beyond the state of the practice” Rick Schantz, BBN • VVM/FVM and voting in middleware is recent state of the art • FT-CORBA would want a small VVM/FVM subset, maybe no VDL/FDL © 2002 Dave Bakken: Mr. Fusion

24. VVM Collaborations and Tech. Transfer • Analysis and Management: Doug Blough et al. Georgia Tech. (Fast Abstract later today) • Network Associates Inc. Labs (a.k.a. Trusted Information Systems) • Integrating VVM subset into TAO for byzantine-fault-tolerant CORBA • Replicated clients so replicated voting • Project ITDOS on DARPA OASIS program (Jay Lala) • TriGeo Network Security Inc. negotiation licence adding to commercial product for managed security and intrusion detection, www.trigeo.com © 2002 Dave Bakken: Mr. Fusion

25. Harsh Questions: Java vs FDL • Why not just define a voting API and upload Java? • Is FDL just “distributed systems syntactic sugar”? • Is the FVM clever and cute, but just “stupid middleware tricks”? • FDL has many advantages • Potential for analyzability and FVM manageability • Adaptive voting • Transparent voting • Readabilty of FDL code, so better reuse • Higher-level language for coding voting algorithm • Termination of FDL code and other safety properties should be able to be guaranteed (future work) © 2002 Dave Bakken: Mr. Fusion