Odyssey Agile, Application-Aware Adaptation for Mobility

1. OdysseyAgile, Application-Aware Adaptation for Mobility • Kip Walker • some slides “borrowed” from Satya

2. A Glimpse of the Future • Imagine you are a tourist in Paris • with a wearable computer • wireless access to remote services • unobtrusive heads-up display, microphone, earphones • speech for computer interactions • online language translation • Let’s go . . . . . .

3. What Makes This Science Fiction? Lack of hardware? NO! We have what we need. Lack of applications? Nope - we have those too. Need a system capable of coping with the problems of mobility Odyssey to the rescue...

4. Problems with Mobility • Mobile elements are resource-poor • relative to static elements of same era • weight, power, size constraints • Mobility leads to communication uncertainty • enormous variation in bandwidth & latency • intermittent connectivity • Power management is a concern • actions may have to be slowed or deferred • communication costs energy • need to rely on resources of remote servers, • but may not be able to reach them!

5. Adaptation Make mobile clients more robust by offering adaptation rely on servers when possible function autonomously if needed monitor and adjust to current conditions

6. Adaptive Applications applications consume resources network bandwidth, CPU cycles, battery power, disk space, $$$ resources are variable …so… applications adapt use of resources as resource quality changes

7. Goals Support variety of applications and data types Concurrent applications Quick adaptation Simple programming model

8. Who Controls Adaptation The Operating System? Individual applications? Both! … Application-Aware Adaptation

9. What Knobs Do We Have? • Where work gets done • let powerful remote servers do the work • How snazzy the data is: “Fidelity” • degrade data meaningfully before giving to mobile host • has many dimensions • one is universal: consistency • others depend on data type • movies: frame rate, frame quality • geographical databases: feature set, minimum feature size • tradeoffs are application-dependent

10. Cutting to the chase… • We built a prototype • runs on several UN*X platforms • logically an OS extension • provides a small API to applications • Implementation follows directly from the high-level design • need data type aware components to offer fidelity choices • need a central piece to watch the resources (network, etc.)

11. Viceroy and Wardens • System-level data differentiation through wardens • specialized code components (a la device drivers) • provides system-level support to manage a data type • trusted entities (unlike applications) • Wardens subordinate to viceroy • single, central component • type-independent, system-level support • responsible for all resource allocation, arbitration • central point of authority and control for Odyssey

12. Client Structure Odyssey Warden3 Viceroy Warden2 Application Warden1 Upcall All system calls Odyssey calls NetBSD Interceptor OS Kernel

13. Resource Negotiation • Applications give viceroy a window of tolerancefor some resource • viceroy monitors resource availability • if it leaves window, notifies application via upcall • Our architecture supports many resources • we currently focus only on network bandwidth Fid. 1 Fid. 2 Fid. 3 Fid. 4 Available bandwidth

14. Applications • Video • server offers movie at several levels of fidelity • application plays the track that the current bandwidth can support • xanim: split into client and server • WWW • “distillation server” degrades data before shipping to client • images can be compressed • HTML can be summarized • Netscape: client-side proxy + remote distillation server • Speech Recognition • local/remote/hybrid execution • Janus: support remote recognition method, hybrid

15. Evaluation (don’t blink…) • Application-aware adaptation is superior to static strategies • applications are able to attain desired “performance” • movie doesn’t drop frames • web delays are masked by compression • speech recognition always available • Centralized resource management outperforms alternatives • all applications come closer to meeting performance goals • Agility needs improvement

16. Future Work • Short term • adaptation for Web objects other than images • improving agility on bandwidth drops • support for unified cache managment • Medium term • explore integration of Odyssey in other operating systems • broaden number of managed resources • enlarge range of supported applications • ... • Long term • deploy Odyssey for real use • dynamic function vs. data shipping as in speech • ...

17. Conclusion • Need for adaptation in mobile systems is widely recognized • Application-aware adaptation • offers most general and effective approach to adaptation • collaborative partnership between system and application • previous approaches are limiting cases of this approach • Odyssey prototype provides initial validation of concept

18. Contributors to Odyssey • Primary contributors • Jason Flinn • Dushyanth Narayanan • Brian Noble • M. Satyanarayanan • Eric Tilton • Kip Walker • Numerous secondary contributors involved in • Coda • Janus • NetBSD • Trace Modulation • etc., etc., etc.