This document proposes using off-path caching in content-centric networking (CCN) to optimize caching within an enterprise network. On-path caching is suboptimal as it can duplicate content across multiple caches, lowering hit rates and increasing delays. The document suggests assigning each popular content to a specific cache and deflecting interest packets for that content directly to its assigned cache to avoid duplication. This approach aims to minimize usage of expensive inter-domain links while keeping intra-domain link usage below capacity. An optimization problem is formulated to determine optimal content placement across caches.

1. Off-Path Caching in
CCN Damien Saucez
Chadi Barakat
Anshuman Kalla
Thierry Turletti
*{first.last}@inria.fr
CCNxCon 2012 - 09/13/2012 INRIA Sophia Antipolis - Planète Project Team

2. What changes with
CCN?
• Shift from location to content based
communications
• Shift from end-to-end to local communications
! secure data themselves instead of
communication channels
! contents can be cached anywhere
! topology is an only an optimization
2

3. On-path caching is sub-optimal
1
1
1 1
1 1
/Sophia/sun 3

4. On-path caching is sub-optimal
1
1
1 1
1 1
/Sophia/sun 3

5. On-path caching is sub-optimal
1
1
1 1
1 1
/Sophia/sun 3

6. On-path caching is sub-optimal
• The amount of traffic on the inter-domain
links of an AS that can cache N contents is
minimized if the N most popular contents
are cached
• On-path caching is sub-optimal as contents
might be duplicated on different caches:
• lower hit rates
• higher delays
4

7. How to perform caching within an enterprise
network such that the use of inter-domain links
is minimized while keeping the domain links’
usage below their nominal capacities?
5

8. Deflect popular content traffic
to optimally located caches
• To avoid content duplication on various caches,
each popular content is assigned a specific cache
• A content is cached only by its assigned cached
• Every Interest packet for a given popular
content is deflected to its content’ assigned
cache
! As the shortest path is not followed anymore,
we call it off-path caching
6

9. Off-path caching to
achieve optimality
I am The cache for /Sophia/sun
1
1
1 1
1 1
I am The cache for /Belgium/rain
/Sophia/sun 7

10. Off-path caching to
achieve optimality
I am The cache for /Sophia/sun
1
1
1 1
1 1
I am The cache for /Belgium/rain
/Sophia/sun 7

11. Where to place
contents?
• Ideal placement would be such that
• contents are not duplicated,
• popular contents are cached close (delay)
to their consumers,
• cache memory is not overloaded,
• links are not be overloaded.
8

12. Optimization problem
9

13. Optimization problem
• Let A be the “content (c) to cache (r)” allocation
matrix, with
∗
Ar,c = 1, Ar,c ∈ {0, 1} , ∀c ∈ C
r∈R
9

14. Optimization problem
• Let A be the “content (c) to cache (r)” allocation
matrix, with
∗
Ar,c = 1, Ar,c ∈ {0, 1} , ∀c ∈ C
r∈R
• Minimize the delay due to deflection
min λc,e Ar,c · de,r
c∈C∗ e∈E r∈R
9

15. Optimization problem
• Let A be the “content (c) to cache (r)” allocation
matrix, with
∗
Ar,c = 1, Ar,c ∈ {0, 1} , ∀c ∈ C
r∈R
• Minimize the delay due to deflection
min λc,e Ar,c · de,r
c∈C∗ e∈E r∈R
• Do not overload cache memory
Ar,c ≤ memoryr , ∀r ∈ R
c∈C∗
9

16. Optimization problem
• Let A be the “content (c) to cache (r)” allocation
matrix, with
∗
Ar,c = 1, Ar,c ∈ {0, 1} , ∀c ∈ C
r∈R
• Minimize the delay due to deflection
min λc,e Ar,c · de,r
c∈C∗ e∈E r∈R
• Do not overload cache memory
Ar,c ≤ memoryr , ∀r ∈ R
c∈C∗
• Do not overload links
λc,e · vc · δl,e,c,A ≤ capacityl , ∀ link l
9
c∈C e∈E

17. Optimal content
placement and deflection
1. Estimate λc,e for every content c, at every
edge router e
2. Solve the optimization problem to
determine A
3. Inject A in the routing tables
10

18. Optimality is complex
to reach
• Optimal placement problem is NP-complete
• requires content popularity estimation
• not tractable in some configuration (e.g.,
large network, large caches...)
• not adapted to dynamic popularity
distribution
• Routing table size is O(N ) with N potentially
large
11

19. Hash function based
heuristic
• A heuristic that avoids content duplication,
removes the necessity to solve an
optimization problem, and maintains flow
table size linear with the size of the network
• Caching All Contents by Hashing (CACH):
• hash names
• routing based on the hash value
12

20. Encapsulation based
deflection R1
R2
/Sophia/sun 4224
1. HASH % |R| R3
4
R4
R5
Interest for Interest for
2. /Sophia/sun /encap/R5/Sophia/sun
13

21. Evaluation
14

22. Simulation setup
• Rocketfuel [SMW02] topology ASN 3967
• 79 core routers, 44 edge routers (2 per city), 6
peering routers
• LRU caching on edge routers, 10 cache entries per core
router
• 150ms peering link delay
• 200,000 Interest packets generated, simulations repeated
11 times
• 7,900 content of Zipf 0.8 [FRR12] popularity distribution
15

23. Main observations
• Rocketfuel simulation (popularity ~ Zipf 0.8)
• Inter-domain link usage is reduced
• from 83% to 53% (opt. 35%) of the load
without cache
• Hit ratio is increased
• from 17% to 53% (opt. 65%)
• Overall retrieval delay is reduced significantly
16

24. Conclusion
17

25. Summary
• The default on-path caching CCN policy is sub-
optimal as contents are duplicated on several
caches
• We then propose off-path caching that deflects
popular traffic to optimally selected caches
• off-path caching maximizes cache hit ratio
• which results in lower inter-domain link usage
• and lower average content retrieval delay
18

26. Next steps
• Transpose the model to dynamic traffic
demand (e.g., content consumers move in
the network) and mobile infrastructure
• Resiliency / optimality tradeoff
19

27. Off-Path Caching in CCN
/**/ || ??
20

28. Backup
21

29. Technique vs users
• Communication is between two devices
• Users use services, from anywhere
22

30. How to reconcile the
two worlds
• Evolutionary solutions
• Enhance current architecture
• Provide interworking mechanisms
• Clean-slate solutions
• Rethink the paradigms
23

31. How to reconcile the
two worlds
• Evolutionary solutions
• Enhance current architecture
• Provide interworking mechanisms
• Clean-slate solutions
• Rethink the paradigms
24

32. Content-Centric
Networking (CCN)
• Shift from location-based to content-based
communications
• Contents become first class citizens in
the network
25

33. The idea
• Content-Centric Networking (CCN)
treats content as a primitive [JST+09]
• Every chunk of data is assigned a name,
such that any content can be directly
retrieved by its name
• Routers cache chunks of data on-path
between consumers and producers
26

34. Workflow
• A content consumer (client) asks for
content by sending an Interest packet to
nodes at its direct neighborhood
• A node that has data that satisfies the
interest responds with a Data packet
• Otherwise, the node forwards the Interest
packet to its neighbors, and remembers from
which neighbors it receives the interest
27

35. Packets
IP packet Interest packet Data packet
Source Address Content Name Content Name
Selector Signature
Destination Address (order preference, publisher filter, scope...)
Nonce Signed Info
Payload
Data
• Two types of CCN packets
• Packets indicate the what, not the who or
the where (neither source nor destination)
28

36. CCN in a nutshell
Interest: /IRM/CCN
29

37. CCN in a nutshell
Interest: /IRM/CCN
29

38. CCN in a nutshell
Pending Interest Table (PIT)
/IRM/CCN, from NW
Interest: /IRM/CCN
29

39. CCN in a nutshell
Pending Interest Table (PIT)
/IRM/CCN, from NW
Interest: /IRM/CCN
29

40. CCN in a nutshell
Pending Interest Table (PIT) Pending Interest Table (PIT)
/IRM/CCN, from NW /IRM/CCN, from W
Interest: /IRM/CCN
29

41. CCN in a nutshell
Pending Interest Table (PIT) Pending Interest Table (PIT)
/IRM/CCN, from NW /IRM/CCN, from W
Interest: /IRM/CCN
29

42. CCN in a nutshell
Pending Interest Table (PIT) Pending Interest Table (PIT)
/IRM/CCN, from NW /IRM/CCN, from W
Data: /IRM/CCN=
29

43. CCN in a nutshell
Pending Interest Table (PIT) Pending Interest Table (PIT)
/IRM/CCN, from NW /IRM/CCN, from W
Data: /IRM/CCN=
29

44. CCN in a nutshell
Pending Interest Table (PIT) Pending Interest Table (PIT)
/IRM/CCN, from NW /IRM/CCN, from W
Content Store (CS)
/IRM/CCN =
Data: /IRM/CCN=
29

45. CCN in a nutshell
Pending Interest Table (PIT)
/IRM/CCN, from NW
Content Store (CS)
/IRM/CCN =
Data: /IRM/CCN=
29

46. CCN in a nutshell
Pending Interest Table (PIT)
/IRM/CCN, from NW
Content Store (CS)
Content Store (CS)
/IRM/CCN =
/IRM/CCN =
Data: /IRM/CCN=
29

47. CCN in a nutshell
Content Store (CS)
Content Store (CS)
Data: /IRM/CCN= /IRM/CCN =
/IRM/CCN =
29

48. CCN in a nutshell
Content Store (CS)
Content Store (CS)
/IRM/CCN =
/IRM/CCN =
29

49. CCN in a nutshell
Content Store (CS)
Content Store (CS)
/IRM/CCN =
/IRM/CCN =
Interest: /IRM/CCN
29

50. CCN in a nutshell
Content Store (CS)
Content Store (CS)
/IRM/CCN =
/IRM/CCN =
Interest: /IRM/CCN
29

51. CCN in a nutshell
Content Store (CS)
Content Store (CS)
/IRM/CCN =
/IRM/CCN =
Data: /IRM/CCN=
29

52. CCN in a nutshell
Content Store (CS)
Content Store (CS)
/IRM/CCN =
/IRM/CCN =
Data: /IRM/CCN=
29

53. What does it change?
• Shift from location to content based
communications
• Shift from end-to-end to local communications
! contents can be cached anywhere
! secure data themselves instead of
communication channels
! topology is an only an optimization
30

54. The reason of CCN?
• Communications in the Internet focus on the endpoints.
• Names are bound to servers which are bound to IP addresses,
• TCP flows are bound to IP address.
• Most of today’s networks use is to acquire named chunks of data
(e.g., web pages, videos).
• There is a gap between the technology and the usage leading to
inefficiencies:
• reliability issue (e.g., what if the server breaks down?),
• inefficient resource utilization (e.g., hotspots),
• weak mobility support.
31

55. Implement off-path
caching with SDN
• Off-path caching is a two-fold process:
• compute the optimal placement of
popular contents in the caches,
• Interest packets deflection to the
appropriate caches.
• As the shortest path is not followed
anymore, we call it off-path caching.
32

56. Every content benefits
from optimal placement
250
CACH
on-path
popularity estimator
200 optimal placement
average delay [ms]
150
100
50
0
1 10 100 1000
content
33

57. Context
• Controlled fixed networks (e.g., ISP)
• peering links are expensive and slow
• internal network is over provisioned
34

58. What if...
35

59. What if...
• we are in an enterprise/campus network?
• internal network is over provisioned
• peering links are expensive and slow
35

60. What if...
• we are in an enterprise/campus network?
• internal network is over provisioned
• peering links are expensive and slow
• content is produced outside the network?
35

61. What if...
• we are in an enterprise/campus network?
• internal network is over provisioned
• peering links are expensive and slow
• content is produced outside the network?
• traffic demand is stable over reasonable
time periods?
35

62. Inter-domain link
bandwidth gain
no caching
cummulative amount of external bandwidth
on-path
CACH
200000 popularity estimator
optimal placement
150000
100000
50000
0
0 1000 2000 3000 4000 5000 6000 7000 8000
content
36

63. Inter-domain link
bandwidth gain
no caching
cummulative amount of external bandwidth
on-path
CACH
200,000
200000 popularity estimator
optimal placement
166,479 Peering traffic drops
150000
from 83% of the
total traffic to 47%
100000 94,657
and 35%.
69,509
50000
0
0 1000 2000 3000 4000 5000 6000 7000 8000
content
36

64. Inter-domain link
bandwidth gain
no caching
cummulative amount of external bandwidth
on-path
CACH
200,000
200000 popularity estimator
optimal placement
166,479 Peering traffic drops
150000
from 83% of the
total traffic to 47%
100000 94,657
and 35%.
69,509
50000
0
0 1000 2000 3000 4000 5000 6000 7000 8000
Popular contents are always
content cached
36

65. Inter-domain link
bandwidth gain
no caching
cummulative amount of external bandwidth
on-path
CACH
200,000
200000 popularity estimator
optimal placement
166,479 Peering traffic drops
150000
from 83% of the
50% total traffic to 47%
100000 94,657
22% and 35%.
69,509
50000 0.7%
0
0 1000 2000 3000
Popular contents are always
4000 5000 6000 7000 8000
cached
content
The top 5.5% of popular contents accounts for 50% of the
36
437 inter-domain traffic, while at optimal they account only for
0.7%

66. Off-path caching
improves hit ratio
CACH
1.2 on-path
popularity estimator
optimal placement
1
0.8
hit ratio
0.6
0.4
0.2
0
1 10 100 1000
content
37

67. Off-path caching
improves hit ratio
CACH
1.2 on-path
•
popularity estimator
1
optimal placement High hit ratio for popular
contents
0.8
hit ratio
0.6
0.4
0.2
0
1 10 100 1000
content
37

68. Off-path caching
improves hit ratio
CACH
1.2 on-path
•
popularity estimator
1
optimal placement High hit ratio for popular
contents
0.8
•
hit ratio
0.6 The overall hit ratio
significantly increases from
0.4
17% to 53% and 65%
0.2
0
1 10 100 1000
content
37

69. Off-path caching
improves hit ratio
CACH
1.2 on-path
•
popularity estimator
1
optimal placement High hit ratio for popular
contents
0.8
•
hit ratio
0.6 The overall hit ratio
significantly increases from
0.4
17% to 53% and 65%
0.2
0
1 10 100 1000
• What is the impact on delay?
content
37

70. Off-path caching
improves retrieval delay
On-path CACH Optimal placement
5.11ms ± 0.05 28.08ms ± 0.04 23.52ms ± 0.03
38

71. Off-path caching
improves retrieval delay
• Once a content is cached, the deflection has a
negative impact on the average retrieval delay
On-path CACH Optimal placement
5.11ms ± 0.05 28.08ms ± 0.04 23.52ms ± 0.03
38

72. Off-path caching
improves retrieval delay
• Once a content is cached, the deflection has a
negative impact on the average retrieval delay
On-path CACH Optimal placement
5.11ms ± 0.05 28.08ms ± 0.04 23.52ms ± 0.03
• But the overall average retrieval delay is
reduced with off-path caching, thanks to a
better hit ratio
On-path CACH Optimal placement
154.42ms ± 0.05 119.19ms ± 0.11 84.23ms ± 0.09
38