Transcript In-Network Caching

Overview, Challenges and Prospects of the
Information-Centric Networking Paradigm
Ioannis Psaras
EPSRC Fellow
University College London
[email protected]
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, “NameBased Replication Priorities in Disaster
Cases”, Proc. IEEE INFOCOM NOM‘14,
April 2014
1000
800
LP2
LP1
600
MP1
300m
300m
HP1
400
HP2
200
0
0
200
MP2
400
600
300m
800
1000
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
Satisfied Interest Table (SIT)
Content Store (CS)
Name
Name
Data
….
….
/a/b
/a/b
….
/c/d
….
….
….
Face List
Face 0
1
3,1
….
Face 1
Index
Ptr Type
CS
PIT
Face 2
FIB
SIT
Pending Intreest Table (PIT)
Name
Forwarding Info Base (FIB)
Prefix
0,3
/a
2
/c/d
2
/c
0,1
….
….
Face 3
Face List
/a/b
….
•
Req. Faces
….
V. Sourlas, L. Tassiulas, I. Psaras, G. Pavlou, “Information Resilience through UserAssisted 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 10th 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 11th 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
ProbCache: Probabilistic In-Network Caching
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 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
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 InformationCentric Networking", Proc. of the 7th 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 HotNets 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 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
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
B
X
C
Ti+1
A
X
B
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
• 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.
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
• In-Network Caching:
– Individually named and self-identifiable packets/chunks allow for innetwork 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
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
B
C
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
B
C
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
[email protected]
http://www.ee.ucl.ac.uk/~uceeips/