1

Odyssey – Support for Mobile, Adaptive Applications

Examples and some slides from Brian Noble and Kip Walker (contributors to the project)

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 is Key

Highly dynamic environment – adaptation key to good performance

Who adapts? System?

• take advantage of good times

• Behave ok during bad times

• CODA

This paper: applications also must adapt

• Change expectations depending on surrounding state

• End to end argument?

6

Client Adaptation

Make mobile clients more robust by offering adaptation rely on servers when possible function autonomously if needed monitor and adjust to current conditions Change application expectations

7

Adaptive Applications

applications consume resourcesnetwork bandwidth, CPU cycles, battery power, disk space, $$

$

resources are variable

…so…

applications adapt use of resources as resource quality changes

8

Who Controls Adaptation

The Operating System?

Individual applications?

Both!

… Application-Aware Adaptation

9

Application-Aware Adaptation

Application only (laissez faire) What if different applications compete for the resources?

OS only (application-transparent) Does not differentiate between applications (student viewing

a video of a lecture vs. a video teleconference)

Joint responsibility in Odyssey (application-aware) Several ways to divide the functionality – odyssey only one

10

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

Fidelity 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

Discussion – anything else?

11

12

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

Other?

13

Odyssey

A Platform for adaptive mobile data access

• Built a prototype for Un*x as OS extension• Provides a small API to the application

• Implementation:• Need a central component for resource monitoring

and management (Viceroy)• Need data aware components that offer fidelity

choices (Wardens)

14

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

15

Odyssey Architecture

Upcalls

Interceptor

Odyssey runtime

Application

kernelTsop,

request

Videowarden

WebWarden

viceroy

Sys calls

Odyssey calls

16

Resource Negotiation

Applications give viceroy a window of tolerance for some resource viceroy monitors resource availability if it leaves window, notifies application via upcall

Currently focus only on network bandwidth; what are other resources of interest?

Available bandwidth

Fid. 1 Fid. 2 Fid. 3 Fid. 4

17

Viceroy

Monitors resources and notifies applications of any changes in resource levels Does this apply to non-mobile applications? Viceroy acts as a single point of resource control

Applications must be able to specify what changes of resources are of interest to them Reporting everything is too expensive since it crosses the

OS to user boundary Solution – application specifies a window of tolerance in a

resource request system call

• Viceroy does an upcall if resource availability moves outside the window

18

Wardens

Wardens are code components that manage type specific operations

Wardens manage communication with the various servers

They also offer the fidelity menu to applications Type specific operations can be customized using

wardens (e.g., caching) To avoid API explosion, one system call (type-

specific operation tsop() is provided Tsop is similar to the un*x ioctl() Can also be used to request type specific operations

19

Operational Model Control loop:

1. Select fidelity (application)

2. Place request (system call)

3. Detect change

4. Notify application

20

Agility

An Odyssey client must estimate the quality of network paths used by various applications.

Odyssey records: Round-trip time Throughput

Odyssey updates its estimates of latency and bandwidth once every half second.

Aside, Noble’s group followed up with agility estimation work for ad hoc networks

21

Agility (cont.)

22

Agility (cont.)

23

Stability

Pursuing agility while completely sacrificing stability can be counterproductive. Rapidly switching Low-fidelity Variable latency

Stability is properly incorporated by individual application.

When notifying an application , the viceroy can include information about the expected variance of estimate.

24

Client Server Based Solutions

Server, typically: Stationary host Possibly replicated Resource rich Holds long running state

Client, typically: Mobile host, intermittent connectivity Resource poor, etc..

Communication restricted between client and server, no mobile-to-mobile communication

25

Extended Client-Server Model

Classic client-server systems assume that the location of client and server hosts do not change and also the connection among them does not change

Functionality between client and server is statically partitioned

Extended Client server Architecture thus deals with these inconsistencies in network connections and location specifics

26

Extended Client-Server Model

Thin client architecture

Full client architecture

Flexible client architecture

27

Thin client architecture

28

Full-Client Architecture

Can support disconnected or weakly connected client The full client architecture supports emulations of

functions of server at client host Light weight servers or proxy E.G CODA , WebExpress

29

Flexible Client-Server Architecture

Generalizes both thin client and full client architecture

Connection between client and server can be dynamically established

30

Client-Server Application Adaptation

The Rover toolkit supports application aware adaptation through the use of RDO http://www.pdos.lcs.mit.edu/rover/ RDOs are relocatable dynamic objects (more in a second)

Philosophy/Motivation similar to Odyssey; approach is different Odyssey changes application in place Rover allows responsibility to be exchanged between client and

server

Benefits to Application Designers Application designers have semantic knowledge Can tightly couple data with program code and manage resources

31

Key Ideas

Relocatable Dynamic Objects Objects (code and data) that can be exchanged between the

client and the server – why?

Queued Remote Procedure Calls (QRPCs) Asynchronous/non-blocking RPC calls If disconnected, application can continue execution RPC executed upon reconnection

32

Programmer’s tasks

Define RDO’s for data types manipulated by the application For data exchanged between client and server

Partition application: Portions that run on client and those that run on server They communicate using QRPC

Define methods for updating objects Includes conflict detection and resolution

33

Using Rover

Programmer links code with toolkit

Application “cooperates” with runtime environment Imports RDOs Invokes methods on RDOs Export logs of invocation to servers Reconcile copies of objects with those at server

Similar to agents? Similar to process migration?

34

35

The application specific proxy has been proposed as an intermediary between client and server

It performs storage intensive and computation intensive tasks

Proxy reduces Bandwidth demands and allow legacy and non standard client to communicate with the server

Proxy-Based Application Adaptation

36

Mobile Objects/Agents

Pieces of code that can freely roam the network

Mobile objects allow clients to download the server code to mobile host for execution

They can maintain state information and make intelligent decisions

Challenge in using mobile objects? Frequently disconnected or weak environment

37

Collaborative Groups

Division of members into groups

Members can access data for the group

A client is able to access data residing on server to which it is communicating or any machine holding the copy of the database, including personal laptop, should be willing to server read and write requests from nearby machines E.g., Bayou system

38

Mobile Data Access

Some slides and Diagram courtesy Mike Franklin, UMD (Lead the Broadcast Disks

project)

39

Mobile Data Access

Mobile data access enables the delivery of server data and the maintenance of client-server data

Data Access strategies in mobile environment can be characterized by Data delivery Data organization Consistency requirement

Data Delivery Modes Client –pull Server-push Hybrid delivery

In fact, this is instance of the more general problem of scalable content delivery

40

Dissemination based Application

Applications where content is delivered to a large number of clients Stock tickers Sport tickers Real-time video broadcasts Software updates (Got redhat 9 yet?) Entertainment/News delivery Others?

How well does it scale? Use the web to deliver Heavy traffic, central point of failure

41

What is the problem?

Asymmetric applications, but web is symmetric

Asymmetry: client to server ration Mouse and keyboard clicks vs. content and update Asymmetry Couch Potatoes

Most people are informational couch potatoes …thankfully

42

Push is the answer?

Traditional pull (e.g., RPC) requires two way interaction

“push” can solve some types of asymmetry Update – no need for polling Client-Server ratio: clients don’t need to bother Network: reduce or eliminate back channel use

43

Push and Pull

Overloaded terms Push vs. pull is just one dimension to compare data delivery

mechanisms Different mechanisms for data delivery can and should be

applied at different points in the system

44

Server Data Dissemination

With mobile nodes, asymmetric communication and resources emphasized

Which alternatives does it make sense to use? Scalability problems for applications with

asymmetrical communication Solution: Broadcast –based dissemination Broadcast disk Indexing on air

Increases query time Decreases Listening time

45