This document presents an approach for estimating content popularity in fragmented information-centric networks (ICNs) with intermittent connectivity. Data mules carry interests between fragmented communities and aggregate [nonce:count] tuples to estimate popularity in a distributed manner. When mules meet, they exchange interests and aggregate counts to distribute popularity information without exchanging full lists. Evaluation of the approach across two fragmented communities retrieving interests with Zipf distributions showed it can accurately estimate popularity with 15 contacts between mules.

1. © NEC Corporation 2015
HydraICN
Scalable Content Exchange
in Challenged ICNs
Bilal Gill
Jan Seedorf
Dirk Kutscher
NEC Laboratories Europe
Supported by GreenICN Project
1

2. © NEC Corporation 2015
ICN Information Availability in Fragmented Networks
2
ICN nodes: store-and-forward mode

3. © NEC Corporation 2015
Data Mules Between Fragmented Communities
3

4. © NEC Corporation 2015
Challenges
▐ Achieving „optimal“ data availability in fragmented ICNs
with intermittent, unpredictable connectivity
▐ Allocating storage and networking resources accordingly
▐ Leveraging knowledge about data popularity/relevance to
optimize resource usage
▐ No global view on popularity: need good enough
decentralized estimation
▐ Estimation algorithm: balance effectiveness and complexity
4

5. © NEC Corporation 2015
Objectives
▐ Distributed counting/aggregating of interests
Interests serve as popularity counters
Aggregating interest information without losing too
much information
▐ Robust protocol
Scalable with respect to network size and network
lifetimes
Loop-free to accomodate random, unpredictable
movements of ICN nodes
5

6. © NEC Corporation 2015
Naïve Approach: Counting Interests
▐ Append nonce to each unique Interest message
and accumulate nonces in the network
 Interest + nonce == unique interest
▐ Advantage: can lead to accurate representation
of popularity per Interest at many nodes
▐ Disadvantage: Scalability problem
Need to store all nonces per Interest
Also: need to exchange complete nonce list when
two nodes meet
6

7. © NEC Corporation 2015
Our Approach
▐ Idea: Aggregate [nonce:count] tuples
 Approximate content popularity
▐ Append nonce to each unique Interest message and count
nonces as a popularity counter: [nonce:count] tuples
▐ Data mules maintain sorted list of [nonce:count] per
interest for scalability
▐ When two data mules meet, they exchange their Interests
 Interests & Popularity estimation gets distributed in network
7

8. © NEC Corporation 2015
Our Approach
▐ For each Interest, aggregate [nonce:count] tuples
as follows:
▐ Compare([nonce1, count1] , [nonce2, count2])
▐ IF nonce1 == nonce2
 new_count = MAX(count1, count2) (at both nodes)
▐ IF nonce1 != nonce2
 New_nonce = nonce with largest counter([nonce1,
count1],
[nonce2, count2])
 New_count = count1 + count2
8

9. © NEC Corporation 2015
Sample Exchange 1
9
DMx
DMy
DMa
DMz
/com/nec/info
Nonce: ##az
/com/nec/info
Nonce: uoa#
Two end users request the same name from DMx

10. © NEC Corporation 2015
Sample Exchange 2
10
DMx
DMy
DMa
DMz
/com/nec/info
Nonce: 8098:2
/com/nec/info
Nonce: 8098:2
End users are assigned a new nonce with count 2 for the same prefix

11. © NEC Corporation 2015
Sample Exchange 3
11
DMx
DMy
DMa
DMz
1
2
3
4
DMa receives duplicate query (loop) from DMz,
thus drops the message (loop detection)
/com/nec/info
Nonce: 8098:2
/com/nec/info
Nonce: 8098:2
/com/nec/info
Nonce: 8098:2
/com/nec/info
Nonce: 8098:2
Duplicate:
Will not increase
popularity counter

12. © NEC Corporation 2015
Sample Exchange 4
12
DMx
DMy
DMa
DMz
1
2
3
4 /com/nec/info
Nonce: 8098:2
/com/nec/info
Nonce: 5678
/com/nec/info
Nonce: 9904
Two new user requests with same prefix from DMz

13. © NEC Corporation 2015
Sample Exchange 5
13
DMx
DMy
DMa
DMz
1
2
3
4 /com/nec/info
Nonce: 8098:4
/com/nec/info
Nonce: 8098:4
/com/nec/info
Nonce: 8098:4
DMz updates its count and sends new once to the end user
DMz updates its
counter

14. © NEC Corporation 2015
Loop Problem
14
DMx
DMy
DMz
/com/nec/info
Nonce: 8098:1
/com/nec/info
Nonce: 8098:3
/com/nec/info
Nonce: 6789:8

15. © NEC Corporation 2015
Loop Problem
15
DMx
DMy
DMz
/com/nec/info
Nonce: 8098:3
/com/nec/info
Nonce: 8098:3
/com/nec/info
Nonce: 6789:8
1

16. © NEC Corporation 2015
Loop Problem
16
DMx
DMy
DMz
/com/nec/info
Nonce: 6789:11
/com/nec/info
Nonce: 8098:3
/com/nec/info
Nonce: 6789:11
1
2

17. © NEC Corporation 2015
Loop Problem
17
DMx
DMy
DMz
/com/nec/info
Nonce: 6789:14
/com/nec/info
Nonce: 6789:14
/com/nec/info
Nonce: 6789:11
3
2
Over-estimating
Popularity!

18. © NEC Corporation 2015
Loop Prevention
▐ Data mules keep list of recently encountered mules per
Interest
▐ If a data mule is encountered shortly after the first encounter,
counters are not added
▐ Instead, max-counter rules is applied at both sides
 nonce1 != nonce2 (AND recently met)
• New_nonce = nonce with largest counter([nonce1,
count1], [nonce2, count2])
• New_count = MAX(count1, count2)
▐ Sliding approach: FIFO list of encountered nodes has limited
(configurable) size
 Can trade off acuracy against memory conservation
18

19. © NEC Corporation 2015
Exchange Scheme (1)
19
UE1 Data Mule A UE2Data Mule B
/com/nec/movie1/  [9x6q; 12]
I: /com/nec/movie1/  [67ww; 1]
R: /com/nec/movie1/  [9x6q; 13]
/com/nec/movie1/  [9x6q; 13] [UE1]
I: /com/nec/movie1/  [9x6q; 13]
/com/nec/movie1/  [9x6q; 13] [UE1]

20. © NEC Corporation 2015
Exchange Scheme (2)
20
UE1 Data Mule A UE2Data Mule B
/com/nec/movie1/  [9x6q; 13] [UE1]
/com/nec/movie1/  [9x6q; 13] [UE1]
I: /com/nec/movie1/  [7j8k; 1]
R: /com/nec/movie1/  [9x6q; 14]
/com/nec/movie1/  [9x6q; 14] [UE1, UE2]

21. © NEC Corporation 2015
Exchange Scheme (3)
21
UE1 Data Mule A UE2Data Mule B
/com/nec/movie1/  [9x6q; 13] [UE1]
/com/nec/movie1/  [9x6q; 14] [UE1, UE2]
I: /com/nec/movie1/
 [9x6q; 13]
R: /com/nec/movie1/
 [9x6q; 14]
/com/nec/movie1/  [9x6q; 14] [UE1, DMB]
/com/nec/movie1/  [9x6q; 14] [UE1, UE2, DMB]
DMB in source list
for /com/nec/movie1/?

22. © NEC Corporation 2015
Implementation
▐ Interests are retransmitted whenever two nodes meet
▐ Application on top of CCN creates FIB entries for all the interests
(names) we want to send to the next node
▐ The life time of an interest packet is set to infinite
 Objective: don‘t expire interest
 PITs can become large...
▐ Current exchange protocol implemented in TCP (not in CCNx
protocol)
▐ Popularity count for all the prefixes in the PIT
 Colon separates nonce and count
22
/com/nec/info 8098:4

23. © NEC Corporation 2015
Name/Popularity-Based Prioritization
▐ Contact time between two data mules could be short
 Data prioritization scheme needed to optimize exchanges
 Here: Leverage popularity estimation for prioritization
▐ Name-Based Prioritization protocol (NBP)
1. Node contact: nodes exchange meta data about cached objects
 List of names, assessed popularity
2. Requesting node generates Interest packets, ordered by „priority“
▐ Different categorization schemes possible
 GreenICN: prioritizing by name / prefix (disaster scenario)
23

24. © NEC Corporation 2015
Evaluation
▐ Objective: evaluate accuracy of distributed popularity estimation
▐ Two Fragmented Communities
▐ 100 distinct data objects
 Queried from three different DMs in each of the fragmented
communities
▐ Data mules meet each other in a random manner and exchange
interests
▐ Zipf distribution for Interests with 0.8 < alpha <0.9
24

25. © NEC Corporation 2015
Scenario Diagram
25
Fragmented Community 1 Fragmented Community 2
• 3 Nodes per FG which fetch interests from 600 end users
• Different sets of names (popular content) in FGs

26. © NEC Corporation 2015
Measurement Setup
▐ Areas with data mules
 Emulation: Mules meet randomly, no disruption during intermeeting
times
▐ Details of the test setup
 6 nodes, 2 Fragmented Communities with different set of names
 Three nodes in their respective FG fetch interest from end users
 Meet DM at random times
 15 contacts between different DM at different times
 Object size: 8 KB
 Approx. 500 Interests issued by users
▐ Test specs
 10 runs for each of the normalized results
 Each runs takes several minutes
26

27. © NEC Corporation 2015
Evaluation (15 Contacts)
27
Results from the Fragmented Community # 1
Zipf, alpha=0.9
15 contacts

28. © NEC Corporation 2015
Zipf-Alpha=0.8
28
Results from the Fragmented Community # 1
Zipf, alpha=0.8
15 contacts

29. © NEC Corporation 2015
Better Estimation with more Contacts
Zipf, alpha=0.9
7 and 15 contacts

30. © NEC Corporation 2015
Observations
▐ More contacts: better accuracy
15 contacts lead to quite good results
But: consistent underestimation (for all objects) – so
may not be a real problem
▐ There can be more than one nonce per object name in
the network
 Can lead to slight overestimation
▐ PITs can become large
▐ Our approach significantly more memory-efficient than
naive approach (thanks to aggregation)
30

31. © NEC Corporation 2015
Summary
▐ Popularity estimation in ICN for optimizing performance
and availability (here: DTN scenario)
▐ Leveraging ICN naming and storage features – changing
CCN semantics (store-carry-forward of interests for long
time)
▐ Simple scheme – intuitively scalable
▐ First evaluations suggest sufficient accuracy
▐ Next Steps
 Polish implementation, documentation, more experiments
 Mobile GW implementation
31

32. © NEC Corporation 2015
www.greenicn.org