Odyssey Agile, ApplicationAware 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
• Lets 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 UNX 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 tolerance
  for 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 (dont blink)

• Application-aware adaptation is superior to
  static strategies
• applications are able to attain desired
  performance
• movie doesnt 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.