Overview, Challenges and Prospects of the Information-Centric Networking Paradigm

1. Overview, Challenges and Prospects of the Information-Centric Networking Paradigm Ioannis Psaras EPSRC Fellow University College London i.psaras@ucl.ac.uk http://www.ee.ucl.ac.uk/~uceeips/ (work presented here has been carried out together with K.V. Katsaros, L. Saino, G. Pavlou, W.K Chai, K.K. Ramakrishnan, M. Arumathurai) I-CAN Workshop, AUEB, Athens, 2-5 June 2015

2. Why bother with ICN • Motivation • Network is content-agnostic and content is location-dependent! • GP: “some of the protocols have not kept pace” • Why ICN • Looks like a more natural way of transferring bits around • GX: “IP apps can do better over ICN” • Internet is transformed to a native content distribution network • It’s more secure, can support mobility and multicast • What extra can we do with ICN • New apps? • Possibly very little– just do the same things, but more efficiently! That’s a start.. • Killer app has not been found yet

3. Architecture Matters • Clean-slate • Extra machines to carry out ICN operations • Upgrades to current infrastructure Bottomline: Someone has to foot the bill!

4. Naming also matters • In ICN, naming determines routing • Content names are effectively a tool to expose information that can be used by the network. • Information “leaked” through names deserves more attention. • For example, • it can help in the caching process • it can assist with the dissemination process in infrastructureless networks (e.g., scoping, single- or multi-recipient transmission) • But: • it might reveal the identity of content providers and therefore, help cancel network neutrality • It might prevent CDNs from logging requests for their content – billing problems/business models

5. Information Exposure • K. Katsaros, L. Saino, I. Psaras, G. Pavlou, “Information Exposure through Named Content”, Workshop on Quality, Reliability and Security in Information-Centric Networking (Q-ICN), Q-SHINE, August 2014. Name-based Replication • I. Psaras, L.Saino, M.Arumaithurai, K.K. Ramakrishnan and G.Pavlou, “Name-Based Replication Priorities in Disaster Cases”, Proc. IEEE INFOCOM NOM‘14, April 2014

6. In-Network Caching • In-network caching supposed to be one of the main benefits of ICN • ISPs count a lot on transparent in-network caching • Quite some challenges: • Line speed operation • Chunk-based caching, as opposed to whole object caching – where to find different parts • Latency to retrieve a cached content is an issue

7. Information-Resilience through In-Network Caching • V. Sourlas, L. Tassiulas, I. Psaras, G. Pavlou, “Information Resilience through User-Assisted Caching in Disruptive Content-Centric Networks”, IFIP Networking 2015 Best Paper Award!

8. Modelling In-Network Caching • I. Psaras, R. G. Clegg, R. Landa, W. K. Chai, G. Pavlou, "Modelling and Evaluation of CCN-Caching Trees", Proceedings of the 10th IFIP Networking, Valencia, Spain, 9-13 May 2011

9. Centrality-Based In-Network Caching • W. K. Chai, D. He, I. Psaras, G. Pavlou, "Cache "Less for More" in Information-centric Networks", Proceedings of the 11th IFIP Networking, Prague, Czech Republic, 21-25 May 2012 • W. K. Chai, D. He, I. Psaras, G. Pavlou, "Cache "Less for More" in Information-centric Networks", Elsevier Computer Communications Special Issue on ICN 2013 Best Paper Award!

10. Probabilistic In-Network Caching • I. Psaras, W. K. Chai, G. Pavlou, "Probabilistic In-Network Caching for Information-Centric Networks",Proc. of the 2nd ACM SIGCOMM Workshop on ICN 2012, Helsinki, Finland, August 2012 • I. Psaras, W. K. Chai, G. Pavlou,”In-Network Cache Management and Resource Allocation for Information-Centric Networks", IEEE TPDS ProbCache: Probabilistic In-Network Caching Caching Capability of a Path Weight-based Caching

11. Cache-aware-/Hash-routing for ICN • L. Saino, I. Psaras, G. Pavlou, ”Hash-routing schemes for Information-Centric Networks",Proc. of the 3rd ACM SIGCOMM Workshop on ICN 2013, Hong Kong, August 2013 • L. Saino, I. Psaras, G. Pavlou, ”Icarus: a Caching Simulator for Information-Centric Networking",Proc. of the 7th ICST SIMUTOOLS, Lisbon, Portugal, March 2014

12. None of this seems to be convincing enough! :(

13. In-Network Resource PoolingIn-net caching from a different angle ACM HotNets 2014 I. Psaras, L. Saino, G. Pavlou “Revisiting Resource Pooling: The case for In-Network Resource Sharing”

14. The Resource Pooling Principle “Pooling of customer demands, along with pooling of the resources used to fill those demands” “networked resources behave as a pooled resource” • Internet (among others): a network of resources • From bandwidth, computation and storage resources, to information/content and service resources • Packet switchingenables pooling of link capacities and routers processing power • Buffersenable pooling of link capacity at adjacent time periods • MPLSTEand ECMPenable pooling of multiple paths

15. Efficiently Pooling End-to-end Paths • Multipath TCP has been recently proposed to efficiently pool end-to-end paths • Multiple simultaneous connections are opened between two communicating hosts over different paths • Load is dynamically shifted among each path based on available bandwidth • Assumes that at least one host is multihomed • More reactive and fine-grained control than MPLS traffic engineering and ECMP

16. Pooled resources Links Switching devices Packet switching Buffers ECMP, MPLS TE, MPTCP Paths Sub-paths Our proposal Packet caches

17. The Resource Pooling Principle We claim that: Pooling can be thought of as a tool to manage uncertainty. • Uncertainty in the Internet (among others): • Senders overloading the network with traffic • Excessive demand for bandwidth over some particular link/area • Target: Maintain stabilityand guarantee fairness

18. Current State of AffairsThe Long Long Discussion on TCP • TCP deals with uncertainty using the “one-out one-in” principle • TCP effectively deals with uncertainty by (proactively) suppressing demand! • TCP is moving traffic as fast as the path’s slowest link • End-points have to speculate on the resources available along the e2e path

19. Vision • Push traffic as far in the path and as fast aspossible • Once in front of the bottleneck, store traffic temporarily in custodian nodes/routers and deal with congestion locally • Exploit all available (sub-)paths making decisions on a hop-by-hop manner.

20. Caches and resource pooling • The presence of ubiquitous packet caches enables more efficient usage of resources by enabling pooling of sub-paths. Ti X A B C Ti+1 X A B C

21. Eliminating UncertaintyInformation-Centric Networking • Request and Data paths are symmetric • Instead of the “data-ACK” model of TCP, in ICN we have a “request-data” model Uncertainty #1 is minimised! • Receivers (instead of senders) regulate the traffic that is pushed in the network • Based on requests forwarded, each forwarding entity knows how much traffic to expect within one RTT.

22. Eliminating UncertaintyIn-Network Caching • Caching has been used for resource optimisation • Reduce delay, save on bandwidth etc. • Overlay Caching: • Put caches in “strategic” places and redirect (HTTP) requests to those caches • In-Network Caching: • Individually named and self-identifiable packets/chunks allow for in-network storage! • Put caches in every router and serve network-layer requests for named chunks from caches on the path • We use in-network caching for temporary storage Uncertainty #2 (temporarily) accommodated

23. Stability & Fairness Global Stability Local Fairness Local Stability Global Fairness

24. 3-Phase Operation • Push-data phase – Open-Loop System • Processor-sharing, RCP-like transmission • Open loop system – senders send even more than what they have received requests for • Push data as far and as quickly as possible • Cache & Detour phase • Every router monitors incoming Requests • When demand is expected to exceed supply, the local router tries to find alternative paths to detour • In the meantime traffic in excess (if any) is cached locally • Backpressure phase – Closed-Loop System • If alternative paths do not exist or are equally congested: • Pace Requests • Send notification upstream to slow down and enter closed-loop transmission

25. 3-Phase Operation • Push-data phase – Open-Loop System • Processor-sharing, RCP-like transmission • Open loop system – senders send even more than what they have received requests for • Push data as far and as quickly as possible D A B C E F

26. 3-Phase Operation • Cache & Detour phase • Every router monitors incoming Requests • When demand is expected to exceed supply, the local router tries to find alternative paths to detour • In the meantime traffic in excess (if any) is cached locally D A B C E F

27. 3-Phase Operation • Backpressure phase – Closed-Loop System • If alternative paths do not exist or are equally congested: • Pace Requests • Send notification upstream to slow down and enter closed-loop transmission D A B C E F

28. Data on detour availability

29. Some (very initial) Results

30. Summary, Open Issues and Things We Don’t (Yet) Know • Information-Centric Networks: • Requires investment and effort • Worth doing, but need to get the full set of advantages • There is an opportunity to deal with congestion control at the network layer • Open Issues: • How do you know detour paths are not congested • How will this co-exist with traditional TCP flows? • Out of order delivery • Flows swapping between original and detour paths

31. Questions? Thanks! Ioannis Psaras i.psaras@ucl.ac.uk http://www.ee.ucl.ac.uk/~uceeips/