Cache Updates in a Peer-to-Peer Network of Mobile Agents Ilias Leontiadis Master’s Thesis University of Ioannina,Greece Supervisors: Vassilios V. Dimakopoulos Evaggelia Pitoura

2 System model Multi-Agent system (MAS)  Network of software agents  Computational resources are distributed across this network  The agents cooperate to fulfill a specified task To do so, they need resources provided by other agents Open MAS  No global knowledge of the agents in the system  Thus, agents are not aware of which agent provides a particular resource

3 Resource discovering in open MAS Approaches : Central directory  There is a single agent which holds a directory, matching resources to agents Middle agents  Some agents (middle agents) keep a fraction of the directory Distributed caches: each agent keeps part of the directory  Performance  Fault tolerance Issue How to locate an agent that provides a particular resource

4 Distributed cache model Each agent maintains cache entries about k different resources of other agents Cache entries: keep the contact information of one agent that provides the resource The system is modeled as a directed graph G(V;E) called the cache network If agent u  v, then v is a neighbor of u a2a2 a4a4 a1a1 a6a6 a3a3 a5a5 R 4 : A 2 R 8 : A 6 R1R2R3R1R2R3 R4R7R4R7 R1R1 R8R5R2R1R8R5R2R1 R9R9 R6R6 Cache of a 1

5 Searching for a resource We consider the following flood-based search methods  Plain flood Forward the query to all its neighbors for a maximum number of steps (TTL: Time-To- Live)  Teeming Propagates the search message only to a random subset of its neighbors Φ the fixed probability of selecting a particular neighbor  Teeming with decay like teeming, but the subset gets smaller as we go deeper into the tree Φ = (1-d) level d < 1. d is called decay parameter  K-Random paths (K-walkers) The agent that initiates the search selects K random neighbors All the other agents forward the message to only one random neighbor Plain floodTeeming2-Random paths

6 The Problem: Cache network and mobility Mobility  Agents may move (e.g. change IP)  Resources may move from one agent to another In fact, no one knows the new location of agent A: when it moved, it didn’t inform anyone a2a2 a4a4 a1a1 a6a6 a3a3 a5a5 a3a3 Old location New location Problem: when an agent A moves, other agents that had cached A’s resources now have invalid cache entries

7 Cache update policies Since the cache entries form our overlay network, what we update is the network topology itself. We propose a number of update policies that combine two basic techniques:  Pull-based Initiated by the agent that wants to update its cache  Push-based Initiated by the agent that moves. We consider the problem of cache updates in a peer-to-peer network of mobile agents

8 Pull-based method Initiated by the agent that wants to refresh a cache entry  Periodically  On-demand Any flood-based search algorithm can be used  Plain flood  Teeming (with decay)  K-Random paths Pull method search the network for an agent that knows the new location

9 Pull search example Old location New location Agents knows the new location Agent that pulls

10 Pull search example

11 Pull search example

12 Pull search example

13 Pull search example Replies Directly

14 Pull search example

15 Push-based method Pull cannot work alone When an agent moves, it must inform at least one more agent about its new location Push method When an agent moves, it “pushes” a message to the network to inform other agents about its new location

16 Push example New location Needs the update Old location

17 Push example

18 Push example

19 Push example

20 Push example

21 Our Update Policies Plain Push/Pull combination with appropriate variations of flooding Push with snooping directories combined with periodic pulls a novel variation of push, where agents that receive information about other moving agents maintain it for a short period of time Inverted Cache with Leasing an informed push approach combined with leasing

22 Plain push/pull method There is no information about which agents need the update Plain push The moving agent blindly floods the network with messages that contain its new location in order to inform others.

23 Plain push/pull method A wide push is needed to update a sufficient number of agents  Large TTL and small decay An agent may not receive the update because:  Offline during push  Push messages may not reach it Larger TTL and decay values needed Disconnected network Such agents should perform on-demand pull.

24 Periodic Pull Another option is to use periodic pull How frequently do we pull ?

25 Periodic Pull Adaptive Time To Pull period (TTP) When TTP expires: If resource was still there  Increase TTP If resource had moved D times  Decrease TTP: Use weight to calculate new TTP Bhide, M., Deolasee, P., Katkar, A., Panchbudhe, A., Ramamritham, K., and Shenoy, P Adaptive Push-Pull: Disseminating Dynamic Web Data. IEEE Trans. Comput. 51, 6 (Jun. 2002),

26 Push with snooping directories and periodic pulling Push with snooping directories Every agent monitors the network and maintains a directory of recently moved agents. This directory is termed snooping directory.

27 Push with snooping directories example

28 Push with snooping directories example Snooping dir -a 1 moved to … Snooping dir -a 1 moved to …

29 Push with snooping directories example a1a1 Snooping dir -a 1 moved to … Snooping dir -a 1 moved to … Snooping dir -a 1 moved to … Snooping dir -a 1 moved to … Snooping dir -a 1 moved to …

30 Push with snooping directories and periodic pulling All agents perform periodic local pulls Periodically, they search the network locally for agents that have recently moved and they update their cache, if necessary Why periodic pulling?  To take advantage of the snooping directories: if we pull after a long time, information about old moves might have already been deleted  Time between two subsequent pulls < expiration time of entries in the snooping directories

31 Push with snooping directories and periodic pulling: Discussion Before: send the update to as many agents as possible Now: send it to some agents and others will be updated by periodic local pulling. For example: If agents periodically pull from their two-hop neighborhood:  it is sufficient to push-inform just one agent in every two-hop neighborhood We prefer to use a k-walkers algorithm for pushing  We spawn K-walkers and we would like all agents to be at most two-hops away from the walk-paths. Snooping directories with periodic pulling allows us to reduce push-flooding

32 Push with snooping directories Changed location

33 Inverted cache push/pull When the agent moves, it informs the agents found  in its inverted cache  to update their plain cache  in its plain cache  to update their inverted directory By knowing where to send the updates  Avoid flooding  Low message overhead Drawback: When an agent adds/replaces/deletes a resource from its cache, a message has to be sent to the resource owner. ABCA B C Every agent keeps a list of the agents to which it is known, called inverted cache

34 Inverted cache push/pull Issue Storing the entire inverted cache directory may not always be preferable, as there may exist popular agents/resources Solution  Only a limited directory may be maintained  The inverted cache strategy can be combined with Leasing The agents that are not informed could use on- demand/periodic pull.

35 Inverted cache push/pull: Leasing Every entry in the cache gets a lease time issued by the resource owner After the expiration the resource owner may delete the entry from its inverted cache, without ever informing the leaser We could control the size of inverted cache directory through lease times  Shorter lease times  smaller inverted cache directories  Maximum inverted cache directory  zero lease times When lease expires or cannot get/renew a lease  Periodic/on-demand pulling Lease time Time interval, during which the resource owner guarantees that it will notify the leaser in case the former moves.

36 Experimental results Evaluation using a simulator Create a random graph  There are 1000 agents owning 3000 resources.  Each agent shares some resources  Some resources are more popular than others  Initially, all agents have valid cache entries The simulation runs for a number of turns:  In each turn, an agent can Move Search for a resource (on demand pull if necessary) Make a cache replacement etc. We keep statistics

37 Plain push/pull Extent of flooding and percentage of valid cache entries decayTTL narrow0.44 medium0.35 wide0.25 full05

38 Plain push/pull Extent of flooding and message overhead

39 Push with snooping directories and periodic pull Extent of flooding and percentage of valid cache entries

40 Push with snooping directories and periodic pull Extent of flooding and message overhead

41 Plain push/pull vs. snooping

42 Inverted cache push/pull with leases Lease time duration and percentage of valid cache entries Lease time small5 medium25 large50 very large100

43 Inverted cache push/pull with leases Lease time duration and inverted cache directory size

44 Inverted cache push/pull Replacement frequency and message overhead

45 Comparison Plain push/pull  Easily implemented  Can be used in an unreliable environment (on-demand pull)  Achieves satisfactory results when using wide flooding  High message overhead: It should be used only when we have low mobility  Should be used only when we do not want to use any additional memory for cache update methods Push with snooping directories and periodic pull  Can achieve the same cache quality with plain push/pull but with significantly less message overhead.  Uses additional memory Inverted cache with leasing  Negligible push message overhead  One-hop update propagation  Replacing a cache entry requires contacting the resource owner Unsuitable for systems with high replacement ratio.  Directory size can become quite large for popular agents  Not appropriate for unreliable open MAS Agents rely on each other to be updated Agents must be online to maintain a valid inverted cache

46 Conclusions We considered the problem of cache updates in a peer-to-peer network of mobile agents  Each agent maintains in its cache information about other agents  When agents move, cached entries about them become obsolete We propose a number of update policies that combine  pull-based techniques  initiated by the agent that wants to update its cache  push-based methods  initiated by the agent that moves. Push/pull variations  Plain push/pull combination  Push with snooping directories and periodic pulls  inverted cache with leasing Our experimental results designate  Snooping directory  same cache consistency with plain push/pull but with less message overhead  Inverted cache method  is cost effective when cache replacements are infrequent

47 Future work  Mobile agents resemble mobile (wireless) nodes in ad-hoc networks: apply our policies to route maintenance in these networks  File replicas in p2p systems apply push/pull techniques to create optimum number of replicas keep replicas consistent

48 Questions ?