Presentation is loading. Please wait.

Presentation is loading. Please wait.

CS848: Pervasive and Mobile Computing April 15, 2002 Department of Computer Science The University of Western Ontario Mobile Computing Models.

Similar presentations


Presentation on theme: "CS848: Pervasive and Mobile Computing April 15, 2002 Department of Computer Science The University of Western Ontario Mobile Computing Models."— Presentation transcript:

1 CS848: Pervasive and Mobile Computing April 15, 2002 Department of Computer Science The University of Western Ontario Mobile Computing Models

2 Outline Agile Application-Aware Adaptation for Mobility Mobile Agents for Mobile Computing

3 Agile Application-Aware Adaptation for Mobility B. Noble, M.Satyanarayanan, D. Narayanan, J. Tilton, J. Flinn, K. Walker

4 Motivation: Mobile Clients Many Problems: u unpredictable variation in network quality (jitter) u inconsistent availability of remote services u limitations on local resources u battery power u less reliable Adaptation is key to mobility.

5 What is Odyssey? A set of extensions to NetBSD to support adaptation for mobile information access applications. Minimalist “..smallest set of interface and code extensions… necessary for agile adaptation in mobile environments”

6 A Brief History of NetBSD First Version (0.8) dates back to 1993 Originally from the 4.3 BSD Lite OS University of California, Berkeley Open source. Latest Version 1.5.2.

7 Philosophy of NetBSD A stable and complete base system without redundancy Not to be satisfied with partial implementations. Other systems have the philosophy of "If it works, it's right". NetBSD has the philosophy "It doesn't work unless it's right".

8 Portability (over 20 platforms are supported) Code quality and correctness Adherence to the standards Research and innovation A good (according to them, only) choice for a Unix system that runs consistently on a variety of platforms. Basic Features of NetBSD

9 Fidelity Definition: The degree to which data presented at a client matches the reference copy at the server. Many dimensions to Fidelity, varies depending on application. Consistency = Universal dimension. Examples of Application-specific dimensions: u Video: frame rate, image quality of frames. u Spatial Data: resolution u Telemetry: sampling rate, timeliness

10 Concurrency Vital Taken for granted on desktop OS. Is it useful for mobile clients? Yes, because users will want to run stuff in background. u For example information filtering applications, (stock prices, SMS, emergency response) Support: control use of limited resources u Need centralized monitoring and coordinated resource management on a mobile client. Makes many applications less effective.

11 Agility Definition: The speed and accuracy in detecting and responding to changes in resource availability. Complicated with many components: u Differing sensitivity for different resources u Different causes for changes in availability of the same resource

12 Application Aware Adaptation Ideally, mobile client has perfect knowledge of current resource levels. Odyssey model is best characterized as application-aware adaptation. Essentially a collaborative partnership between the system and individual applications. Attempts to address application diversity and concurrency. Challenge is to support this separation without compromising agility.

13 Models of Adaptation

14 Realizing the Model Obvious Implementation: u directly address previous issues on an individual basis u system code treats data generically u individual applications responsible for differential handling of data types Can't Do This Because: u disparity in the properties of the various data types u E.g. Video can drop data, but with FTP that's bad. u Needs system-level knowledge of type

15 Realizing the Model Solution: a more sophisticated architecture with two responsibilities. u (1) Must be aware of shared access to remote data by concurrent applications. n To properly manage resources. u (2) Must have type-specific knowledge. n For resource management actions.

16 Wardens Odyssey incorporates type-awareness via specialized code components called wardens. Wardens encapsulate the system-level support at a client u to effectively manage a data type. A warden has to be incorporated into Odyssey at each client for each new data type. Subordinate to Viceroy

17 Viceroy Responsible for centralized management Type independent component

18 A Collaborative Relationship Two Parts: u Data-centric (Viceroy and Wardens). n Get fidelity level for each data type n Factors them into resource management. u Action-centric (Applications and Odyssey) n Applications control selection of fidelity levels n Supported by the wardens.

19 Odyssey Client Architecture

20 Operating on Odyssey Objects Built upon NetBSD file system calls Implemented in user space, instead of kernel. Operations on Odyssey objects are redirected to the viceroy by a small in-kernel interceptor module. All other system calls handled directly by NetBSD Wardens statically linked with the viceroy Wardens entirely responsible for communicating with servers Odyssey and the file system are integrated

21 Integration Pros: u Well-understood framework u Simplified implementation u Can provide small amount of type-awareness without new system calls. Cons: u Some data types don't fit u No standard operations for changing fidelity

22 Expressing Resource Expectations Applications communicates resource expectations to Odyssey using the request system call. Resource Negotiation Operations Request(in path, in resource-descriptor, out request-id) Cancel(in request-id)

23 Expressing Resource Expectations Application Decides on New Fidelity Level Viceroy registers request Sorry Odyssey receives request. Application happy, life goes on. Sends request Tolerance NOT OK Return Error Code and Current Resource Level Tolerance OK Send ID to Application

24 Expressing Resource Expectations Each resource is named by a unique resource identifier Window of Tolerance indicated by upper/lower bounds. Resource descriptor also specifies the name of a procedure that will be called to notify the application that the resource has left the window. resource-id lower bound upper bound name of upcall handler Resource Descriptor Fields

25 Generic Resources in Odyssey Network Bandwidth Network Latency Disk Cache Space CPU Battery Power bytes/second microseconds kilobytes SPECint95 minutes

26 Notifying Applications When availability of resource strays outside registered window of tolerance, viceroy generates an upcall Application adjusts its fidelity. Makes another request call to register a revised window of tolerance appropriate to the new fidelity. handler(in request-id, in resource-id, in resource-level) Upcall Handler

27 Notifying Applications Upcalls closely resemble UNIX signals but with more features Like signals: u can be sent to one or more processes u can be blocked or ignored Unlike signals: u offer exactly-once, in-order semantics for each receiver of a particular upcall u parameters can be passed to target process u results returned

28 Changing Fidelity Not supported easily by NetBSD file system interface u untyped byte stream model General purpose mechanism, tsop (type specify an operation). tsop(in path, in opcode, in insize, in inbuf, inout outsize, out outbuf)

29 Example Applications Three types: u Video Player u Web Browser u Speech Recognizer Each have different fidelity requirements

30 Video Player

31 Using Xanim Split monolithic implementation into client and server Wrote a Warden to handle client request and fetch data from server Three levels of fidelity (99, 50, 0.01). Warden supports two tsop's, to read movie meta data and get specific frame from track When player opens a movie, it calculates the bandwidth requirements When notified of bandwidth change, determines new fidelity level and switches to that track

32 Web Browser

33 Redirect all Netscape requests to module called Cellophane u uses Odyssey API to select fidelity level u transforms HTTP requests into file operations Web warden forwards requests to a distillation server Distillation server provides multiple levels of fidelity u fetches request objects from appropriate web server u distills them to the requested fidelity level Transparent to web server and Netscape. Code interpositioning is solution for non-open source applications.

34 Speech Recognizer

35 Using Janus Split into client and server and speech warden constructed Front end captures raw speech and writes it to an object Warden decides if it is faster to perform first pass of the recognition on local, slower CPU or ship it raw to the server Server can accept raw or partially processed speech Recognized speech converted into text

36 Evaluation Three Questions: u How agile is Odyssey in the face of changing network bandwidth? u How beneficial is it for applications to exploit the dynamic adaptation made possible for Odyssey? u How important is centralized resource management for concurrent applications?

37 Agility Metrics Generate sharp discontinuities in network bandwidth u 120kB/s for high u 40 kB/s for low

38 How Agile Is Odyssey? Viceroy looks at log entries u round trip entries for small exchanges u throughput entries for bulk transfers Each entry measures TIME it takes to receive a window's worth of data Viceroy estimates bandwidth available per connection Estimate composed of two parts: u competed-for (proportional to recent use) u fair-share (expected lower bound)

39 Varying Supply Ran an application that consumed data as fast as possible through a streaming warden Available Bandwidth varied Results: u Works very well with sudden increases u Not so good for sudden decreases

40 Varying Supply

41

42

43

44 Varying Demand Client given 30 seconds alone Second identical client added Three experiments: 10%, 45% and 100% Results: u immediate reaction for low utilization u slower for higher demand ones u give preference to first client (until second one establishes itself)

45 Results: Video Player Goal: play highest quality without dropping frames Three fidelity levels: u 1.0 u 0.5 u 0.01 Run Xamin for each of the three levels, then run Odyssey

46 Results: Video Player Results: u Drop less frames then going at JPEG(99) alone u Manages to drop fewer frames by reverting to JPEG(50) frames at lower bandwidth u Since this means more JPEG(99) frames shown, therefore meets self-described goals...

47 Results: Web Browser Goal: Fetch 22kB image as fast as possible Cellophane chooses from four fidelity levels: u 1.0 u 0.5 u 0.25 u 0.05

48 Results: Web Browser Results: u "Meets our performance goal in all cases" u Faster than static strategies u In Impulse-Up case, fooled into fetching better quality images

49 Results: Speech Recognizer Goal: Speed of Recognition Three fixed strategies: u Always Hybrid u Always Remote u Adaptive

50 Results: Speech Recognizer Results u Hybrid best (for when speech is only application running) u Odyssey copies Hybrid u Unconfirmed: Adaptive better for higher bandwidths

51 Importance of Centralized Resource Management Method: Compare Odyssey to laissez-faire and blind- optimism. Laissez-fair: No resource management u simulated by looking at logs in isolation Blind-optimism: networking layer of OS notifies applications when switching between network technologies. u simulated by passing the theoretical bandwidth to the viceroy at each transition. Viceroy then notifies any interested applications.

52 Importance of Centralized Resource Management Results: u Odyssey better u Drops less frames u Able to do so because it correctly accounts for bandwidth competition

53 Importance of Centralized Resource Management Most real-time systems use a resource reservation system Odyssey does not, tries keep things transparent to application u uses feedback driven adaptation u no need to calibrate resource to specific applications Author's argue that installation of pieces of code at low levels already done in databases for improved performance.

54 Future of Odyssey Full support for deciding between dynamic function and data shipping Support the searching of distributed repositories by using dynamic sets. Better techniques for analyzing agility and stability

55 Summary of Odyssey Need adaptation for mobile information access Application-aware adaptation most general approach Odyssey does this u Through collaboration between application and system Experiment supposed to show prototype is feasible.

56 Issues/Discussion Needs warden for every application Application must be aware of its own fidelity u What if all applications took a selfish approach? u Everyone has to play nice. Does network bandwidth really have so much variance as to require this?

57 Mobile Agents For Mobile Computing R. Gray, D. Kotz, S. Nog, D. Rus, and G. Cybenko

58 Research in AI community Single-agent systems: u Action selection (planning) u Knowledge representation and inference u Agent learning and adaptation Multi-agent systems: u Communication and collaboration u Emergent properties of group behavior

59 Motivation People want access at all times but... u Mobile computers often disconnected u Connection often has low bandwidth and high latency and is prone to sudden failure u Network connection varies u May be assigned a different IP address every time it connects. Unreliable

60 What is an Agent? A program (“software agent”), e.g., n Personal assistant (mail filter, scheduling) n Information agent (tactical picture agent) n E-commerce agent (stock trader, bidder) n Recommendation agent (Firefly, Amazon.com) A program that can: u interact with users, applications, and agents u collaborate with the user Software agents help with repetitive tasks

61 What is an Agent? Not all programs are agents Agents are: u customized u persistent u autonomous u adaptive

62 What is a mobile agent? Machine AMachine B Search engine An Agent is something that: u migrates from machine to machine u in a heterogeneous network u at times of its own choosing

63 Why Mobile Agents? Efficiency: consume fewer network resources by moving the computation to the data rather than the data to the computation. Fault tolerance: do not require a continuous connection between machines. Convenient paradigm: hide the communication channels but not the location of the computation. Customization: allow clients and servers to extend each other's functionality by programming each other.

64 Why Mobile Agents? There are many alternative techniques -- queued RPC, proxy servers, etc. -- that have many of these same advantages. The problem with these alternative techniques is that each one is only suitable for certain applications. A mobile-agent system is a single, unified framework in which a wide range of distributed applications can be implemented easily and efficiently.

65 Reason: Uses Less Bandwidth Server Database Client/Proxy Server Database

66 Reason: Bandwidth Conservation Database Dynamically selected proxy site

67 Reason: Reduce Latency Server Agent 1. Observe high average latency to clients 2. Move to better location

68 Reason: Reduce Completion Time Efficiency Mobile user 1. Send code with unique query 2. Perform multi-step queries on large, remote, heterogeneous databases 3. Return requested data Low bandwidth channel

69 Reason: Load balancing Jobs/Load Jobs/Load migrate in a heterogeneous network of machines

70 Agent Tcl Reduce migration to a single instruction. (Programmer should not have to explicitly collect state information) Provide transparent communication among agents. Provide a simple scripting language as the main agent language and allow the straightforward addition of a new language or transport mechanism. Provide effective security

71 Architecture of Agent Tcl

72 The Agent server: u keeps track of the agents that are running on its machine u provides inter-agent communication facilities u accepts and authenticates agents arriving from other host and restarts these agents in their own interpreter. All other services are provided by agents. Agents themselves are separate processes executing the appropriate language interpreter.

73 Mobile Computing Agent system must support disconnected operation To be effective, an agent must be able to: u jump off a partially connected computer and return to it u navigate through the internet to find the services it needs u sense and react to the network environment u communicate effectively with other agents

74 Laptop Docking System Each laptop is paired with a dock machine

75 Jumping To or From a Laptop M (laptop) M_dock (permanently connected machine) Queue of agents waiting to go to M Queue of agents waiting to leave 1. Jump directly to laptop 2. If laptop unreachable, go to dock 3. Change in network status 4. Notify dock of new location 5. Transfer waiting agents in both directions

76 Laptop to Laptop Jump Both laptops could be never be connected simultaneously!

77 Multi-destination Jumps For when agent: u wishes to visit multiple hosts in no particular order u is to search all sites for information u is visiting one of a replicated set of servers Dock-master on S tries to transfer the agent to one of the final destinations by trying each one in order If all destinations are unreachable, agent goes to S_dock. The dock-master at S_dock repeatedly tries to reach the destinations until it succeeds. Agent wakes up knowing it has arrived at one of the destinations.

78 Hooks More control over jumping process allow agents to: u query the status of the network connection u request a failure notification u request that the jump go as far as possible then be awoken

79 Agent Navigation and Adaptation World is dynamic and uncertain u Machines go up and down u data changes u steps to complete a task often not completely known An autonomous agent is crippled with no without external state An agent needs sensors for adaptive navigation

80 Network Sensing Ability for a laptop to detect the state of its network connection Enables agents to adapt to changing network conditions For example: an agent that needs to visit information resources at several sites. u A smart agent should be able to adapt if some sites currently unreachable and visit others first. u A smarter agent may be able to plan a sequence of visits given an estimate of the current network delay to each site. u Maybe tailor their behaviour to the current bandwidth

81 Network Sensing Tools So agent can get info about the network status u A tool to determine whether the local host is physically connected. (Pings the broadcast address on the local subnet) u A tool to determine whether a specific host is reachable (just standard ping) u A tool to determine the expected bandwidth to a remote host n Bandwidth is predicted from experience, not measured n Weighted average of all communications

82 Navigation Agents Agents need a dynamic index of service agents to locate other agents Virtual Yellow Pages contain listing of services and their locations. u distributed database of service locations u maintained by navigation agents

83 Navigation Agents Services register with a navigation agent Each machine has special agent that knows the location of some of the navigation agents By consulting the local specialist agent and then visiting one or more navigation agents, an application agent can get a list of services and their locations. Adaptive learning methods are used to keep the virtual yellow pages up-to-date.

84 An Example of Navigation

85 Navigation Agents After visiting the services listed, the application agent returns to the navigation agent to provide feedback on the usefulness of the sites. Navigation agents use this info to prioritize their lists. Application agents that discover services accidentally report the corresponding sites to the navigation agents. Relevant services might be discovered while handling a different but related task. If agent receives different site information from two navigation agents it will tell it to them

86 Adaptive Agent Navigation Application agents use the prioritized list of services they receive from the navigation agents as their initial plan. Most applications want to visit either one or all sites on the list. Using network sensing tools they may want to skip some sites that are unreachable to too slow (and go to them later).

87 Inter-Agent Communication Low-level: agents communicate through message passing or through a direct connection Higher level: agent remote procedure call mechanism adds structure and higher-level abstraction. u Server agents in the system register with the local "name- server”using a flexible definition language interface u Client agents search for a service by providing a similar interface and having the "name-server" find a match u Flexible interface matching technique helps agents communicate even if they share only a subset of complex interface

88 Mobile node setup GPS Unit Cabletron/ Digital Roamabout Metricom Ricochet Linux laptop

89 Experiment Laptop called Bond Started an agent on Bond Agent jumps off to remote server Bond disconnected, moved to another lab Meanwhile agent finished task and tried to jump back to Bond. Jump failed so transferred to Bond_dock, where its state was saved

90 Experiment Bond reconnected to different subnet with new IP Bond's dock-master discovered new connection and new address; sent message to Bond_dock in old lab Bond_dock then sent waiting agent to Bond Experiment repeated, carrying Bond back to old lab Agent was able to leave laptop and return home twice, despite disconnect, reconfiguration and new IP address

91 Future of Agent Tcl Re-named to D’Agent (Dartmouth Agent) www.cs.dartmouth.edu/~agent Support for multi-destination jumps Support for Persistent Storage Refined bandwidth-prediction tools

92 Current trends lead to mobile agents Information overload Diversified population Bandwidth gap Mobile users and devices “Customization” Proxy-based Server-side Avoid large transfers Disconnected Operation Mobile code to client Mobile code to server or proxy Mobile Agents High latency Increased need for personalization Too many unique, dispersed clients to handle Multiple sites to visit Avoid “star” itinerary

93 Conclusion: Pros A unifying framework for making many applications more efficient Treats data and code symmetrically Multiple-language support possible Supports disconnected networks in a way that other technologies cannot Cleaner programming model

94 Conclusion: Acknowledged Limitations If agent is running on a machine and machine goes down, agent is lost If agent is running on machine and machine is disconnected for very long time, agent stuck on machine If laptop connected for only brief period of time, dock-master agent won't detect connection Cannot handle some environments, like nameless hosts (e.g. PC with dynamically assigned IP addresses).

95 Issues/Discussion Security is big a concern u Malicious Agents u Bad Machines u etc. Overhead for moving code is high Not backward compatible with current code Networks will be fast, performance may not be an issue

96 Mike and Sue Scenarios Agile Application-Aware Adaptation u device that measures the glucose level and transmits this information to his doctor’s office. u accepting verbal orders (the conference call: “Connect me with John Robinson and Tom Smith at 9”) u Sue wants to know if the price of XYZ reaches a certain point so that she may buy it.

97 Mike and Sue Scenarios Mobile Agents for Mobile Computing u electronic shopping list u doctor’s office keeps track of the measures u Mike’s personal electronic agent negotiates with the dental office-computing environment for an alternative time u Mike selects a PRINTER for Tom’s message u contents of the whiteboard are transmitted u news delivered and personalized

98 Mike and Sue Scenarios Mobile Agents for Mobile Computing Continued u charts of patients downloaded to PDA u computer in the hospital which may find that the supply of medication is not enough, orders more u personalized financial advisor agent, Fred u Fred asked to check to see if enough $ to cover purchase


Download ppt "CS848: Pervasive and Mobile Computing April 15, 2002 Department of Computer Science The University of Western Ontario Mobile Computing Models."

Similar presentations


Ads by Google