Karsten Schwan Greg Eisenhauer Matt Wolf Mustaq Ahamad (Nagi Rao - ORNL Constantinos Dovrolis)

1. IQ-ECho: Middleware Principles for Real-time InteractionAcross Heterogeneous Hardware/Software Platforms Karsten Schwan Greg Eisenhauer Matt Wolf Mustaq Ahamad (Nagi Rao - ORNL Constantinos Dovrolis) College of ComputingGeorgia Tech schwan/eisen/mwolf@cc.gatech.edu http://www.cc.gatech.edu/systems/projects/IQECho/

2. Large-scale Collaborative Applications on Heterogeneous Systems: Terastream Services and Teragrid High End Users and Displays Wireless Users and Displays GT High Performance Data Streaming Data Transport capture, transport, filter, select, sample, re-route Data Source (e.g., spallation neutron source) Transform Specialize ORNL Teragrid Atlanta Hub Cluster Computer Terastream Server High End Users and Displays Instrumented Testbeds/Facilities (e.g., for spallation neutron source) Emory University Visualization Scalable Services Real-time Collaboration and Inspection Data Cache Instrumented Testbed/Facility Local Users Caching, Recovery, Logging, Security

3. vs. Undamaged Damaged Undamaged W W L L W / l and L / l l = interatomic spacing Real-time Collaboration: Molecular Dynamics Requirements: • Multiple collaborators explore common data space • Personalized views, with ability to annotate and manipulate • Real-time sharing of data, even between different representations • Mechanical Engineering • Physics • Chemistry • Aerospace Engineering Twinning Plane FCC

4. IQ-ECho: Middleware Principles for Network-aware Collaboration • Adaptive Peer-to-Peer Data Exchange: • IQ-ECho: High performance events: • Event-based peer-to-peer streaming data communications -binary data exchanges (PBIO) for interactive apps (steering, real-time collaboration, …) • Source-based filtering: IQ-services deployed to meet required application QoS, i.e., by disposition of application-specific code into remote sites and underlying platform • Dynamic quality attributes: coordinated adaptation of platform (e.g., communication protocols)and of interactive applications • Network-awareness: adaptive communications (with Nagi Rao/ORNL, Constantinos Dovrolis/GT): • Runtime detection of congestion • Runtime response: adaptation: re-routing, concurrent paths, coordinated protocol/application response (IQ-RUDP)

5. Real-time Collaboration with IQ-ECho Filters Adaptive Source-based Filtering Dynamic Quality Attributes Multiple Event Types

6. Types of adaptation Middleware- and/or Network-level: • Frequency • Same amount of data but different rate • Resolution • Same rate, different amount • Reliability • Changing proportion of discardable packets • Multiple Connections • Protecting critical connections from large-data traffic

7. Adaptive Communication • Adapt what? • Congestion windows + data rates • Issues: • Transport cannot delegate all adaptation choices to applications and still be fair to the network • Applications cannot delegate all adaptation to the transport without limiting their choices or incurring difficulties (e.g., QoS translation) • Goal: • provide a mechanism to allow effective application adaptations while remaining network-friendly

8. Coordinated Adaptation • Use `quality attributes’ to share information across middleware/protocol - IQ-Services • `Coordination methods’ Services/Protocol to address: • Conflicting adaptations • Combined effect of adaptation that may lead to overreaction • Limited application adaptation granularity • Others, ... • Problems important in networks where (delay * bandwidth) is large: • cost of adaptation • delay before correction of mistakes

9. Middleware/Protocol Interactions • IQ-Services in Middleware: • Application-relevant data manipulation: • Data prioritizers, data filters, downsamplers • Controlled by dynamic quality attributes • On-line Network Measurement: • e.g., Rao’s TCP-based methods • Using an Instrumented Protocol: IQ-RUDP extends Reliable UDP • TCP-friendly congestion control (LDA algorithm) • Exposes network performance metrics • Supports application-registered callbacks • Application-controlled adaptive reliability

10. Middleware Architecture

11. Evaluation of Coordinated Adaptation • How effective is coordination in two-layer adaptations? • Metric is “smoothness” of delay over time • Evaluate three cases where coordination is necessary • Hold application traffic pattern constant, vary network bandwidth • iperf used to generate background traffic • Hold network bandwidth constant, vary application traffic • Emulate content delivery server using MBONE trace • Drive adaptations using callbacks on error ratio

12. Example: Conflicting Adaptations • No Coordination • Transport unaware of adaptation • All packets sent regardless of priority • More unmarked packets delivered • Larger delay for marked packets • Coordination • Transport can drop non-priority packets • Better delay/jitter for high priority packets • Average delay improves due to spacing

13. Conflicting Adaptations • IQ-RUDP (on right) achieves lower avg delay (emulation results)

14. Example: Metadata-based Filtering • IQ-RUDP (on right) achieves substantially higher frame rate (measured results)

15. Conclusions and Status • Key technologies: • Adaptive, lightweight middleware services • software release of IQ-ECho available soon (installation at ORNL in progress) • Coordinated middleware/network (re)actions (through quality attributes) • generalizes to other network efforts (e.g., Net100) • Heterogeneous, distributed collaboration with high end data streams: • Smartpointer (MD - SC2002) • Evaluation on wide area networks • Internet, GT/ORNL link (yet to come) • Focus on integration • MxN services, AG 2.x

16. Ongoing Efforts and Leverage • Deployment and Evaluation (Year 3): • Realistic applications and testbeds: • deploy remote collaboration infrastructure (with ORNL) and experiment across ORNL/GT Gigabit Testbed (with N. Rao, ORNL) • experiment with other data sets (e.g., spallation neutron source), other protocols, other network measurement methods (NSF/DOE) • CCA/OGSI integration: • CCA integration: use MxN service as challenge example (joint with James Kohl - ORNL) • OGSI integration challenge example: remote graphics services for AG-> OGSI, directory services • Leverage: CERCS and GT/ORNL efforts: • NSF Netreact project • integrated network measurement - w. Dovrolis, Rao • NSF XML project - dynamic metadata • Teragrid and GT/ORNL and GT/NRL: high end network links

17. Future Work • Platform resources: effective deployment: • Servers: real-time data transformation with the Terastream server (utilizing end points!) • Networks: • application-specific processing on programmable routers • utilizing high end links, e.g.,Teragrid • Dynamic data interoperability: • heterogeneous data, using XML markups • automating XML/binary translations • Protected services: • controlling IQ-service execution

18. Publications Qi He and Karsten Schwan, “IQ-RUDP: Coordinating Application Adaptation with Network Transport”, High Performance Distributed Computing (HPDC-11), July 2002. Matt Wolf, Zhongtang Cai, Weiyun Huang, Karsten Schwan, ``SmartPointers: Personalized Scientific Data Portals in Your Hand'', Supercomputing 2002. Fabian Bustamante, Patrick Widener, Karsten Schwan, ``Scalable Directory Services Using Proactivity'', Supercomputing 2002. Patrick Widener, Greg Eisenhauer, Karsten Schwan, and Fabián E. Bustamante, "Open Metadata Formats: Efficient XML-Based Communication for High Performance Computing", Cluster Computing: The Journal of Networks, Software Tools, and Applications, 2003. Greg Eisenhauer, Fabián Bustamante and Karsten Schwan, "Native Data Representation: An Efficient Wire Format for High-Performance Computing", IEEE Transactions on Parallel and Distributed Systems, 2003.