Overview Challenges and Prospects of the InformationCentric Networking

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/ I-CAN Workshop, AUEB, Athens, 2 -5 June 2015 (work presented here has been carried out together with K. V. Katsaros, L. Saino, G. Pavlou, W. K Chai, K. K. Ramakrishnan, M. Arumathurai)

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

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

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

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

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

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!

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 10 th IFIP Networking, Valencia, Spain, 9 -13 May 2011

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 11 th IFIP Networking, Prague, Czech Republic, 21 -25 May 2012 Best Paper Award! • 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

Probabilistic In-Network Caching Prob. Cache: Probabilistic In-Network Caching Capability of a Path Weight-based Caching • I. Psaras, W. K. Chai, G. Pavlou, "Probabilistic In-Network Caching for Information-Centric Networks", Proc. of the 2 nd 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

Cache-aware-/Hash-routing for ICN • L. Saino, I. Psaras, G. Pavlou, ”Hash-routing schemes for Information-Centric Networks", Proc. of the 3 rd 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 7 th ICST SIMUTOOLS, Lisbon, Portugal, March 2014

None of this seems to be convincing enough! : (

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

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 switching enables pooling of link capacities and routers processing power – Buffers enable pooling of link capacity at adjacent time periods – MPLS TE and ECMP enable pooling of multiple paths

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

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

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

Current State of Affairs The 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 e 2 e path

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

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

Eliminating Uncertainty Information-Centric Networking • Request and Data paths are symmetric • Instead of the “data-ACK” model of TCP, in ICN we have a “request-data” model s i 1 # y t n ai ed! t r e Unc inimis • Receivers (instead ofmsenders) 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.

Eliminating Uncertainty In-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 #2 y t in a t ) packets/chunks allow for inr y e l – Individually named and self-identifiable i c r n ra U o d p e network storage! t m a (te od m – Put caches in every router and serve network-layer requests for om c c named chunks from acaches on the path • In-Network Caching: • We use in-network caching for temporary storage

Stability & Fairness Global Stability Local Fairness Local Stability Global Fairness

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

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 C B E F

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 C B E F

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

Data on detour availability

Some (very initial) Results 0. 9 0. 8 Netwrok throughput 0. 7 0. 6 0. 5 SP ECMP 0. 4 INRP 0. 3 0. 2 0. 1 0 Telstra Exodus Tiscali

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

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