Post on 14-Jan-2016
Improving On-demand Data Access Efficiency with Cooperative Caching in MANETs
Phd Dissertation Defense
11.21.05@CSE.ASU
Yu Du
Chair: Dr. Sandeep Gupta
Committee: Dr. Partha Dasgupta
Dr. Arunabha Sen
Dr. Guoliang Xue
Supported in part by NSF grants ANI-0123980, ANI-0196156, and ANI-0086020, and Consortium for Embedded Systems.
2
Roadmap
1. Introduction
2. Cooperative caching
3. Related works
4. Proposed approach – COOP
5. Performance evaluation
6. Conclusions and future works
3Data Server
Data Server
1.1 Problems of data access in MANETs
• MANETs – Mobile Ad hoc Networks
– Wireless medium
– Multi-hop routes
– Dynamic topologies
– Resource constraints
• On-demand data access – client/server model.
Data Server
Data Server
Data Server
Data Server
Data Server
Data Server
1. Introduction
4
1.2. Reducing data access costs in MANETs
• The locality principle [Denning]– Computer programs tend to repeat referencing a subset of
data/instructions.
– Used in processor caches, storage hierarchies, Web browsers, and search engines.
• Zipf’s law [Zipf]– P(i) 1/∝ iα(αclose to unity), common interests in popular data.
– 80-20 rule: 80% data accesses happen on 20% data.
• Cooperative caching– Multiple nodes share and cooperatively manage their cached contents.
1. Introduction
5
1.3. Cooperative caching• Cooperative caching
– A caching node not only serves its own data requests but also the requests from others.
– A caching node not only stores data for its own needs but also for others.
– Shorter path, less expensive links, less conflictions, lower risks of route breakage.
– save time, energy, and bandwidth consumption as well as improves data availability.
• Why?– Data locality and commonality in users’ interests.
– Client/Server communication Vs. inter-cache communication.
– Users around the same location tend to have similar interests.
• People gathered around the food court: menus.
• Exploration team: environmental information.
1. Introduction
AshleyBob To remote server
6
Roadmap1. Introduction2. Cooperative caching
2.1. Overview2.2. Cache resolution2.3. Cache management2.4. Cache consistency control
3. Related works4. Proposed approach – COOP5. Performance evaluation6. Conclusions and future works
7
2.1 Overview
• Cooperative caching– Multiple nodes share and cooperatively manage their
cached contents.
– Cache resolution
– Cache management
– Cache consistency control
• Used in Webcache/Proxy servers on Internet.– To alleviate server overloading and response delay.
– Did not consider special features of MANETs.
2. Cooperative caching
8
2.2 Cache resolution
• How to find a cache storing the requested data?
1
54
32
76?
?
OK
Hierarchical Directory-based Hash table based
Caching node Data items
Node 1
Node 2
…
Item1
Item2
…
1
2
3
4
5
Node 1
Node 2 Node 3
Harvest [Chank96]
Summary[Fan00]
Squirrel[Lyer02]
2. Cooperative caching
9
2.3 Cache management
• What to cache?
– Admission control.
– Cache replacement algorithm.
• LRU
• Extended LRU (Squirrel)
– any access has same impact, whether it is from the local node or other nodes.
2. Cooperative caching
10
2.4 Cache consistency control
• How to maintain the consistency between server and cache?
– Strong/Weak consistency: whether consistency is always guaranteed.
– Pull/Push-based: who (client/server) initiates the consistency verification.
• TTL is used in this research.
– Each data item has a Time-To-Live field – allowed caching time.
– TTL is popularly adopted in real applications – HTTP.
– Lower cost than strong-consistency protocols.
Pull-based Push-based
Weak TTL Synchronous Invalidation
Strong Lease Asynchronous Invalidation
2. Cooperative caching
11
3. Related works
Schemes Cache Resolution Cachemanagement
Consistencycontrol
Networkmodel
Harvest [Chank96]
Hierarchically No specification TTL WAN
Summary[Fan00]
Directory-based LRU TTL WAN
Squirrel[Lyer02]
Hash-based Extended LRU TTL LAN
Cao04[Cao04]
CacheData,CachePath,
HybridCache
LRU TTL MANET
12
Roadmap
1. Introduction
2. Cooperative caching
3. Related works
4. Proposed approach – COOP4.1. System architecture
4.2. Cache resolution
4.3. Cache management
5. Performance evaluation
6. Conclusions and future works
13
4.1 System architecture
• Each node runs a COOP instance.
• The running COOP instance– Receives data requests from user’s
applications.
– Resolves requests using the cocktail cache resolution scheme.
– Decides what data to cache using COOP cache management scheme.
– Uses the underlying protocol stack. COOP
User Applications
Cocktail Cache Resolution
COOP Cache Management
User requests Response
COOP Messages
Network Protocol Stack
Local Cache
Secondarydata
Primarydata
Node A
4. Proposed approach – COOP
14
4.2. Cache Resolution
4.2.1. Hop-by-Hop
4.2.2. Zone-based
4.2.3. Profile-based
4.2.4. COOP cache resolution – a cocktail approach
4. Proposed approach – COOP
15
4.2.1 Hop-by-Hop cache resolution
• The forwarding nodes try to resolve a data request before relaying it to the next hop.
• Reduces the travel distance of requests/replies.
• Helps to avoid expensive/unreliable network channels.
Data Server
Data Server
Data Server
Data Server
4. Proposed approach – COOP, 4.2 Cache resolution
16
4.2.2 Zone-based cache resolution
• Users around the same location tend to share common interests.
• Cooperation zone – the surrounding nodes within r-hop range.– r: the radius of the cooperation zone
• To find an item within the cooperation zone– Reactive approach – flooding within the cooperation zone.
– Proactive approach – record previous heard requests.
Data Server
Data Server
Data Server
Data Server
Data Server
Data Server
4. Proposed approach – COOP, 4.2 Cache resolution
17
4.2.3 Profile-based cache resolution
• Records received request to assist future cache resolution– RRT – Recent Request Table.
– Entry is deleted when if the recorded requester fails to reply the corresponding data item.
– When the table is full, use LRU to decide replacement.
Requester Time Requested Data ID
192.168.0.11 15:26:59:08:16:2005 D1
192.168.0.15 15:25:59:08:16:2005 D2
192.168.0.18 15:20:59:08:16:2005 D3
4. Proposed approach – COOP, 4.2 Cache resolution
18
4.2.4 COOP cache resolution – a cocktail approach
Received a datarequest
Data in localcache?
Success?
Reactive zone-basedcache resolution
Done
Yes
No
Profile-based cacheresolution
Hop-by-Hop cacheresolution
Success?Yes
Yes
No
No
4. Proposed approach – COOP, 4.2 Cache resolution
19
4.3. Cache Management
4.3.1. Primary and secondary data
4.3.2. Inter-category and intra-category rules
4. Proposed approach – COOP
20
4.3.1. Primary and secondary data
• Different cache misses may introduce different costs.– Example: cache miss cost for X is higher than cache miss cost for Y.
• Primary data and secondary data.– Primary data – not available within cooperation zone.
– Secondary data – available within cooperation zone.
Data Server
Data Server
X can be obtained from a
neighbor.
Y has to be obtained from
the server.
4. Proposed approach – COOP, 4.3 Cache management
21
4.3.2. Inter-category and intra-category rules
• Inter-category rule– when replacement decision is to be made between different categories.
– Primary data have precedence over secondary data
• Intra-category rule– when replacement decision is to be made within the same category.
– LRU
• Example: A1 – A5 (Primary); B1 – B6 (Secondary)
T0 T4T3T2T1
4. Proposed approach – COOP, 4.3 Cache management
22
Roadmap1. Introduction2. Cooperative caching3. Related works4. Proposed approach – COOP5. Performance evaluation
5.1. The impact of different zone radius5.2. The impact of data access pattern5.3. The impact of cache size5.4. Data availability5.5. Time cost: average travel distance5.6. Cache miss ratio5.7. Energy cost: message overhead
6. Conclusions and future works
23
5.1 The impact of different zone radius
(1) Average probability of finding a requested item d within the zone.(2) Average time cost
– assuming time cost is proportional to the number of covered hops
(3) Average energy cost– assuming time cost is proportional to the number of messages.
2
)1(1)( rdPrP
2
)1())(1)(()( rdPLrrPLrrrPD
2
)1())(1)(()( 222 rdPLrrPLrrPrE
(1)
(2)
(3)
Pd average probability of a node caches d.
ρ the average node density.
L the distance (hops) between the requesting node and the server.
r the cooperation zone radius.
5. Performance evaluation
24
5.1 The impact of different zone radius
2
)1())(1)(()( rdPLrrPLrrrPD
Average t i me cost Vs. cooperati on zone radi us
0
10
20
30
40
1 2 3 4 5 6 7 8 9 10
Cooperati on zone radi us
Aver
age
time
cos
t
Average energy cost Vs. cooperat i on zoneradi us
050
100150200250300350
1 2 3 4 5 6 7 8 9 10
Cooperat i on zone radi us
Aver
age
ener
gy c
ost
2
)1())(1)(()( 222 rdPLrrPLrrPrE
5. Performance evaluation
P( r) Vs. cooperat i on zone radi us
00. 20. 40. 60. 8
11. 2
1 2 3 4 5 6 7 8 9 10
Cooperat i on zone radi us
P(r)
2
)1(1)( rdPrP
• If an item is not found within a certain size cooperation zone, it is unlikely to find it within a larger size zone.• The saturation point.
25
5.2 The impact of access pattern
Cache mi ss rat i o Vs Data access pat tern
0
0. 2
0. 4
0. 6
0. 8
1
1. 2
0. 5 0. 6 0. 7 0. 8 0. 9
Al pha
Cac
he m
iss
rati
o
SC
HBH
CT- 1
CT- 2
CT- 3
Average t ravel di stance Vs Al pha
0
2
4
6
8
10
0. 5 0. 6 0. 7 0. 8 0. 9
Al pha
Dist
ance
(Hop
s) SCHBHCT- 1CT- 2CT- 3
Average #messages Vs Al pha
0
5
10
15
20
25
0. 5 0. 6 0. 7 0. 8 0. 9
Al pha
#Mes
sage
sSCHBHCT- 1CT- 2CT- 3
• α ++• Cache miss ratio - -
•CT-3, CT-2, CT-1, HBH, SC• Average travel distance - -
•CT-3, CT-2, CT-1, HBH, SC• Average #messages - -
•HBH CT-1, SC CT-2, CT-3
5. Performance evaluation
26
5.3 The impact of cache size
Average #messages Vs. Cache si ze
0
5
10
15
20
25
10 20 30 40 50
Cache si ze
Aver
age
#mes
sage
s
SCHBHCT- 1CT- 2CT- 3
Average t ravel di stance Vs Cache si ze
0
2
4
6
8
10
10 20 30 40 50
Cache si ze
Dist
ance
(hop
s) SCHBHCT- 1CT- 2CT- 3
Cache mi ss rat i o Vs Cache si ze
0
0. 2
0. 4
0. 6
0. 8
1
1. 2
10 20 30 40 50
Cache si ze
Cac
he m
iss
rati
o
SC
HBH
CT- 1
CT- 2
CT- 3
• Cache size ++• Cache miss ratio - -
•CT-3, CT-2, CT-1, HBH, SC• Average travel distance - -
•CT-3 CT-2, CT-1, HBH, SC• Average #messages - -
•HBH CT-1, SC CT-2, CT-3
5. Performance evaluation
27
5.4 Data availability
Request success Rat i o Vs. node number
0
0. 2
0. 4
0. 6
0. 8
1
50 60 70 80 90 100
Number of Nodes
Succ
ess
rati
o
SCHBHCT- 1CT- 2
Request uccess rat i o Vs. node vel oci ty
0
0. 2
0. 4
0. 6
0. 8
1
1 10 20 30
Speed
Succ
ess
rati
oSCHBHCT- 1CT- 2
Request success rat i o Vs. pause t i me
0
0. 2
0. 4
0. 6
0. 8
1
60 120 180 240 300
Pause t i me
Succ
ess
rati
o
SCHBHCT- 1CT- 2
• Varied factors• node number• pause time• node velocity
• Data availability• CT-2, CT-1, HBH, SC
5. Performance evaluation
28
5.5 Time cost: average travel distance
Average travel di stance Vs. node number
0
2
4
6
8
50 60 70 80 90 100Number of nodes
Numb
er o
f ho
ps
SCHBHCT-1CT-2
Average t ravel di stance Vs. pause t i me
0
24
6
8
60 120 180 240 300
Pause t i me
Numb
er o
f ho
ps
SCHBHCT- 1CT- 2
Average t ravel di stance Vs. nodevel oci ty
02468
1 10 20 30
Speed
Numb
er o
fho
ps SCHBHCT- 1CT- 2
• Varied factors• node number• pause time• node velocity
• Average travel distance• CT-2, CT-1, HBH, SC
5. Performance evaluation
29
5.6 Cache miss ratio
Cache mi ss rat i o
00. 20. 40. 60. 8
11. 2
60 120 180 240 300
Pause t i me
Cach
e mi
ss r
atio
SCHBHCT- 1CT- 2
Cache mi ss rat i o Vs. node number
00. 20. 40. 60. 8
11. 2
50 60 70 80 90 100
Number of nodes
Cach
e mi
ss r
atio
SCHBHCT- 1CT- 2
Cache mi ss rat i o
00. 20. 40. 60. 8
11. 2
1 10 20 30
Speed
Cach
e mi
ss r
atio
SCHBHCT- 1CT- 2
• Varied factors• node number• pause time• node velocity
• Cache miss ratio• CT-2, CT-1, HBH, SC
5. Performance evaluation
30
5.7 Energy cost: average #messages
Message overhead Vs. node number
05
1015202530
50 60 70 80 90 100
Number of nodes
Numb
er o
f me
ssag
es
SCHBHCT- 1CT- 2
Average number of messages per request
05
1015202530
60 120 180 240 300
Pause t i me
Numb
er o
f me
ssag
es
SCHBHCT- 1CT- 2
Average #messages per successf ul request
05
1015202530
1 10 20 30
Speed
Numb
er o
f me
ssag
esSCHBHCT- 1CT- 2
• Varied factors• node number• pause time• node velocity
• Average #messages• CT-1 HBH, SC, CT-2
5. Performance evaluation
31
6. Conclusions and future works
• Cooperative caching is supported by data locality and the commonality in users’ interests.
• Proposed approach – COOP– Higher data availability – Less time cost– Smaller cache miss ratio – The tradeoff is message overhead– Tradeoff is dependent the cooperation zone radius.
• Future works– Adapt cooperation zone radius based on user’s requirements.– Explore different cooperation structure.– Enforce fairness in cooperative caching.
32
References
• [Cao04] L. Yin and G. Cao, “Supporting cooperative caching in ad hoc networks”, INFOCOM, 2004.
• [Chank96] A. Chankhunthod et al. “A Hierarchical internet object cache”, USENIX Annual Technical Conference, 1996.
• [Denning] P. Denning, “The locality principle”, Communications of the ACM, July 2005.
• [Fan00] L. Fan et al. “Summary cache: A scalable wide-area web cache sharing protocol”, Sigcomm, 1998.
• [Lyer02] S. Lyer et al. “Squirrel: A decentralized peer-to-peer web cache”, PODC, 2002.
• [Zipf] G. Zipf, “Human behavior and the principle of least effort”, Addison-Wesley, 1949.
33
Q & A
Thank You!