CCNxCon 2012: Session #7: Off-Path Caching in CCN

1,243 views

Published on

Off-Path Caching in CCN
Chadi Barakat, Anshuman Kalla, Damien Saucez, Thierry Turletti (INRIA, France)

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,243
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
29
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

CCNxCon 2012: Session #7: Off-Path Caching in CCN

  1. 1. Off-Path Caching in CCN Damien Saucez Chadi Barakat Anshuman Kalla Thierry Turletti *{first.last}@inria.frCCNxCon 2012 - 09/13/2012 INRIA Sophia Antipolis - Planète Project Team
  2. 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. 3. On-path caching is sub-optimal 1 1 1 1 1 1/Sophia/sun 3
  4. 4. On-path caching is sub-optimal 1 1 1 1 1 1/Sophia/sun 3
  5. 5. On-path caching is sub-optimal 1 1 1 1 1 1/Sophia/sun 3
  6. 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. 7. How to perform caching within an enterprisenetwork such that the use of inter-domain linksis minimized while keeping the domain links’usage below their nominal capacities? 5
  8. 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. 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. 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. 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. 12. Optimization problem 9
  13. 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. 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. 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. 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 9c∈C e∈E
  17. 17. Optimal contentplacement and deflection1. Estimate λc,e for every content c, at every edge router e2. Solve the optimization problem to determine A3. Inject A in the routing tables 10
  18. 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. 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. 20. Encapsulation based deflection R1 R2 /Sophia/sun 42241. HASH % |R| R3 4 R4 R5 Interest for Interest for2. /Sophia/sun /encap/R5/Sophia/sun 13
  21. 21. Evaluation 14
  22. 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. 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. 24. Conclusion 17
  25. 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. 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. 27. Off-Path Caching in CCN /**/ || ?? 20
  28. 28. Backup 21
  29. 29. Technique vs users• Communication is between two devices• Users use services, from anywhere 22
  30. 30. How to reconcile the two worlds• Evolutionary solutions • Enhance current architecture • Provide interworking mechanisms• Clean-slate solutions • Rethink the paradigms 23
  31. 31. How to reconcile the two worlds• Evolutionary solutions • Enhance current architecture • Provide interworking mechanisms• Clean-slate solutions • Rethink the paradigms 24
  32. 32. Content-Centric Networking (CCN)• Shift from location-based to content-based communications • Contents become first class citizens in the network 25
  33. 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. 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. 35. Packets IP packet Interest packet Data packet Source Address Content Name Content Name Selector SignatureDestination 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. 36. CCN in a nutshellInterest: /IRM/CCN 29
  37. 37. CCN in a nutshellInterest: /IRM/CCN 29
  38. 38. CCN in a nutshellPending Interest Table (PIT)/IRM/CCN, from NW Interest: /IRM/CCN 29
  39. 39. CCN in a nutshellPending Interest Table (PIT)/IRM/CCN, from NW Interest: /IRM/CCN 29
  40. 40. CCN in a nutshellPending Interest Table (PIT) Pending Interest Table (PIT)/IRM/CCN, from NW /IRM/CCN, from W Interest: /IRM/CCN 29
  41. 41. CCN in a nutshellPending Interest Table (PIT) Pending Interest Table (PIT)/IRM/CCN, from NW /IRM/CCN, from W Interest: /IRM/CCN 29
  42. 42. CCN in a nutshellPending Interest Table (PIT) Pending Interest Table (PIT)/IRM/CCN, from NW /IRM/CCN, from W Data: /IRM/CCN= 29
  43. 43. CCN in a nutshellPending Interest Table (PIT) Pending Interest Table (PIT)/IRM/CCN, from NW /IRM/CCN, from W Data: /IRM/CCN= 29
  44. 44. CCN in a nutshellPending 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. 45. CCN in a nutshellPending Interest Table (PIT)/IRM/CCN, from NW Content Store (CS) /IRM/CCN = Data: /IRM/CCN= 29
  46. 46. CCN in a nutshellPending Interest Table (PIT)/IRM/CCN, from NW Content Store (CS) Content Store (CS) /IRM/CCN = /IRM/CCN = Data: /IRM/CCN= 29
  47. 47. CCN in a nutshell Content Store (CS) Content Store (CS)Data: /IRM/CCN= /IRM/CCN = /IRM/CCN = 29
  48. 48. CCN in a nutshell Content Store (CS) Content Store (CS) /IRM/CCN = /IRM/CCN = 29
  49. 49. CCN in a nutshell Content Store (CS) Content Store (CS) /IRM/CCN = /IRM/CCN =Interest: /IRM/CCN 29
  50. 50. CCN in a nutshell Content Store (CS) Content Store (CS) /IRM/CCN = /IRM/CCN =Interest: /IRM/CCN 29
  51. 51. CCN in a nutshell Content Store (CS) Content Store (CS) /IRM/CCN = /IRM/CCN =Data: /IRM/CCN= 29
  52. 52. CCN in a nutshell Content Store (CS) Content Store (CS) /IRM/CCN = /IRM/CCN =Data: /IRM/CCN= 29
  53. 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. 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. 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. 56. Every content benefitsfrom 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. 57. Context• Controlled fixed networks (e.g., ISP) • peering links are expensive and slow • internal network is over provisioned 34
  58. 58. What if... 35
  59. 59. What if...• we are in an enterprise/campus network? • internal network is over provisioned • peering links are expensive and slow 35
  60. 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. 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. 62. Inter-domain link bandwidth gain no cachingcummulative 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 content36
  63. 63. Inter-domain link bandwidth gain no cachingcummulative 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 content36
  64. 64. Inter-domain link bandwidth gain no cachingcummulative 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 cached36
  65. 65. Inter-domain link bandwidth gain no cachingcummulative 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 the36 437 inter-domain traffic, while at optimal they account only for 0.7%
  66. 66. Off-path caching improves hit ratio CACH 1.2 on-path popularity estimator optimal placement 1 0.8hit ratio 0.6 0.4 0.2 0 1 10 100 1000 content 37
  67. 67. Off-path caching improves hit ratio CACH 1.2 on-path • popularity estimator 1 optimal placement High hit ratio for popular contents 0.8hit ratio 0.6 0.4 0.2 0 1 10 100 1000 content 37
  68. 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. 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. 70. Off-path caching improves retrieval delay On-path CACH Optimal placement5.11ms ± 0.05 28.08ms ± 0.04 23.52ms ± 0.03 38
  71. 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 placement5.11ms ± 0.05 28.08ms ± 0.04 23.52ms ± 0.03 38
  72. 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 placement154.42ms ± 0.05 119.19ms ± 0.11 84.23ms ± 0.09 38

×