Fault tolerance in Information Centric Networks

www.helsinki.fi
Fault Tolerance in Information
Centric Networks
Nitinder Mohan
nitinder.mohan@cs.helsinki.fi

www.helsinki.fi
1. Why Fault Tolerance?
2. Model network architectures
i. Disruption Tolerant Networks
ii. Information Centric Networks
3. ICN vs DTN
i. Architectural
ii. Routing
4. Modelling content dissemination in DTN
5. Modelling network disruptions in ICN
6. Faulty network use-case – Mobile Ad-hoc Networks (MANETs)
Presentation Overview

www.helsinki.fi
Typical IP-based end-to-end communication assumes the following:
1. Best effort-packet delivery
• Retransmission by end hosts is sufficient
2. Stationary Hosts and Stable Topology
• Discover best-path for delivery, and if not found, drop the packet!
3. End-to-End Connections
• Links are reliable, overall RTT is quite small
Problems with Current IP Approach

www.helsinki.fi
Present-day systems are riddled with faults!
• Hardware failure
• Software bugs
• Operator errors
• Network errors/outages
In short, almost anything critical involved in running a system-over-
network can fail!
Faults…Faults…Everywhere!

www.helsinki.fi
Transient Faults
• Temporary faults
• Occurs and
disappears
• Eg. Message
transmission
timeout on a single
try!
Types of Faults
Intermittent
Faults
• Device irregularity/
Malfunctions
• Difficult to find and
repair
• Eg. Server
Downtime due to
software failures
Permanent
Faults
• Conditional faults
from which no
repair can be
done.
• Eg. Hardware
failures/outages

www.helsinki.fi
1. Critical Applications
• Typical use-case: Aircrafts, chemical reactors, medical equipment,
financial applications
• Malfunction in such networks can lead to catastrophic results!
2. Harsh Environments
• Typical use-case: Computing in electromagnetic field, external forces
• High failure rate and no useful results
3. Highly complex systems
• Typical use-case: Computing amongst millions of devices, mobile
network
• Every device has a probability of failure, overall probability → HIGH
Need for Fault Tolerance

www.helsinki.fi
Transient Faults
• Temporary faults
• Occurs and
disappears
• Eg. Message
transmission
timeout on a single
try!
Types of Faults
Intermittent
Faults
• Device irregularity/
Malfunctions
• Difficult to find and
repair
• Eg. Server
Downtime due to
software failures
Permanent
Faults
• As the name
suggests,
conditional faults
from which no
repair can be
done.
• Eg. Hardware
failures/outages

www.helsinki.fi
1. Critical Applications:
• Typical use-case: Aircrafts, chemical reactors, medical equipment,
financial applications
• Malfunction in such networks can lead to catastrophic results!
2. Harsh Environments
• Typical use-case: Computing in electromagnetic field, external forces
• High failure rate and no useful results
3. Highly complex systems
• Typical use-case: Computing amongst millions of devices, mobile
network
• Every device has a probability of failure, overall probability → HIGH
Need for Fault Tolerance

www.helsinki.fi
Connected Network

www.helsinki.fi
Disruption Tolerant Networks (DTN)

www.helsinki.fi
• Fault tolerance over IP network.
• Originally, developed to support inter-planetary communication
o Unreliable end-to-end communication
o Transmission delays in order of minutes!
o Many hop transmissions
• Closely resembles present day network scenarios.
o Vehicular Networks
o Mobile Ad-hoc Networks
o Wild-life tracking
Disruption Tolerant Networks (DTN)
QUESTION: What about content deliverability?

http://www.xkcd.com/949/

www.helsinki.fi
• Future Internet architecture for content disemmination
• Content addressing rather than node addressing
• Developed to handle content delivery in current scenarios
o Assumptions: Nobody cares about the location of the server!
o Works amazingly well for intra-domain content delivery.
Information-Centric Networks (ICN)
QUESTION: What about network faults?!
Jacobson, CoNext slides, 2009

Fault tolerance in Information Centric Networks

• Implements its own layer over “sender-receiver agreement” of Transport Layer
• Follows IP addressing
• Assumes nodes in network to have persistent storage

• Follows its own network stack over “universal agreement” of Network layer
• Addresses content using hierarchical naming schemes
• Assumes routers in network to have cache storage

• Powerhouse for fault-tolerance nature of DTN
• Provides key capabilities:
o Custody-transmissions
o Connectivity over opportunistic and intermittent links
o End-to-end reliable delivery of messages over un-reliable links

• Entire ICN functionality of named data addressing
• Provides key capabilities:
o Packet mapping to Interest and Data
o Multiple simultaneous connectivity
o Opportunistic connectivity over un-reliable links

www.helsinki.fi
DTN Routing:
Post-Office Model
Store-and-Forward model to deliver over faulty links
i
X Z
Y
i
i
Balasubramanian, DTN, 2010

www.helsinki.fi
DTN Routing:
Post-Office Model
PROBLEM!
i
X
Z
Y
i

www.helsinki.fi
DTN Routing:
Post-Office Model
DTN also provides replication of messages
i
X
Z
Y
i
i
W
i

www.helsinki.fi
ICN Routing:
In-network Cache
Store-and-Supply model to reduce time for content deliverability
Consumer
Router
Producer
Interest

www.helsinki.fi
ICN Routing:
In-network Cache
Consumer
Router
ProducerData

www.helsinki.fi
ICN Routing:
In-network Cache
Consumer
Router
Producer
Consumer

www.helsinki.fi
1. ICN and DTN are quite similar architecturally
• Both assume in-network storage
• Both store data within the network
• Both take advantage of opportunistic networking
2. Even though ingredients are approximately same, end-product is
quite different!
• ICN uses its architecture to improve content dissemination
• DTN uses its architecture to improve content deliverability
Takeaway
QUESTION: Can we somehow inter-mingle the two?

www.helsinki.fi
• DIsruption REsilient Content Transport (DIRECT) proposed by Solis et al. [5]
• Envisions a modified DTN architecture very similar to ICN
• Content is disseminated according to object names rather than node
addresses
• Objects are stored in in-network cache memory present at each node and is
mapped to object table for faster access
• Pub-Sub like queries for fetching objects
ICN like DTN
Content
Object Wrapper
Hierarchical Object Name

www.helsinki.fi
Node
publishes
content with
desired object
name
Network
Layer adds
object to
Object Table
Consumer
issues a GET
query with the
desired object
name
Every node
adds the
query to its
Query
Table
Checks the
Object
Table for
desired
object
If yes, send
back the object,
store it in in-
network
storage
If No, route
to next node
using routing
algorithm
followed in
DTN
ICN like DTN

www.helsinki.fi
User-centric DTN
Intuition: “Store-and-forward” routing model with replication wastes
resources in an already constrained network
Idea: What if the content was only forwarded to nodes who are
interested in it rather than every node which lies in the
opportunistic path
Solution: Gao et al [6] proposed a user-centric DTN
• Monitor user interests through a probabilistic framework.
• Rank nodes according to their overall interest in a content
• Make next hop routing decisions to form a r-hop
opportunistic path.

www.helsinki.fi
Selfish nodes in DTN
• “Selfish” nodes in DTN request for a content but leave as soon
as the content is delivered!
• Data routing is costly → entire network suffers!
• Krifa et al. [7] proposed a “tit-for-tat” model
 For every data request, the node has to supply some data of interest
in return
 The interests of all nodes is modelled in an “interest profile register”
and is advertised
 Isolates free-riders and acts as an incentive strategy
 Increase in over-all content dispersion

www.helsinki.fi
• As discussed, ICN is very similar to DTN architecturally but fulfills
different functions
• Yu et al. [8] proposed a hybrid DTN/ICN network model, Disruption
Tolerant-Information Centric Ad-hoc Network (DT-ICAN)
 Nodes send “node-interest” to profess interest in a content → BROADCAST
 Receiving node-interest → Don’t send content (network overload!)
 Node prepare cache summary of available content → send to one-hop
neighbors
 Nodes requests subset of data (both what it needs and its neighbors want)
→ send request message
 Data exchange between nodes is a three-way handshake
 Data travels in one-hop steps!
Disruption Tolerant ICN

www.helsinki.fi
• Several DTN-MANET solutions have been proposed [10][11]
• ICN offers several benefits over DTN for MANETs
1. Exploit multiple connections simultaneously
• Opportunistic connectivity over any connection (LTE, WiFi,
Bluetooth) is a problem for DTN due to end-to-end connectivity
• As ICN stack detaches itself from TCP/IP transport layer, such
connections are possible!
2. No location-based connection scoping
• Applications offer restrictions to users based on their location (eg.
Spotify)
• Legitimate user over-the-border suffers the most
• ICN takes away location scoping and offers global access to data
Why ICN-MANETs?

www.helsinki.fi
1. Producer Mobility
• With content dispersion, ICN natively supports consumer mobility
• However, when producer is mobile → Only most frequently
requested content will be cached in the network!
Solutions proposed
i. CHANET [14] employs control messages to advertise producers
new routing location on network change
ii. S.Y. Oh et al. [9] proposes Internet Registry (IR) which keeps the
global network state of MANET. IR is periodically updated through
broadcasts
Issues with ICN-MANETs

www.helsinki.fi
2. Content routing
• Content routed in MANET is yet-to-be-generated → How to name
such data for routing?
• Emergency-MANETs require pushing awareness content which is
not supported in ICN
Solutions proposed
i. S.Y. Oh et al. [9] proposes Metadata Registry (MR) kept at every
producer and contains metadata of published content. MR is
advertised via broadcast.
ii. ICN-Publish-Subscribe [16][17] can be used to route real time
content and push awareness content

www.helsinki.fi
3. Wireless channel collisions
• MANETs are connected via opportunistic wireless channels
• Current ICN lacks design for tackling wireless packet collisions, handoffs
and packet overhearing!
Solutions proposed
1. S.Y. Oh et al. [9] and Tyson et al. [12] propose Request and Reply for
avoiding simultaneous transmissions in ICN-MANETs (two-way
handshake)
‒ Consumer issues Interest to producer
‒ Producer sends Reply to consumer
‒ Consumer sends Request to producer
‒ Producer sends the Data

www.helsinki.fi
[1] F. Warthman, “Delay- and Disruption-Tolerant Networks (DTNs) - A Tutorial,” p. 35, 2012.
[2] V.Jacobson,D.K.Smetters,J.D.Thornton,M.F.Plass,N.H. Briggs, and R. L. Braynard, “Networking named content,”
in Proceedings of the 5th international conference on Emerging networking experiments and technologies. ACM,
2009, pp. 1– 12.
[3] T. Spyropoulos, R. N. Rais, T. Turletti, K. Obraczka, and A. Vasilakos, “Routing for disruption tolerant networks:
taxonomy and design,” Wireless networks, vol. 16, no. 8, pp. 2349– 2370, 2010.
[4] A. Hoque, S. O. Amin, A. Alyyan, B. Zhang, L. Zhang, and L. Wang, “Nlsr: Named-data link state routing proto-
col,” in Proceedings of the 3rd ACM SIGCOMM Workshop on Information-centric Networking. ACM, 2013, pp. 15–
20.
[5] I. Solis, I. Solis, J. J. Garcia-Luna-Aceves, and J. J. Garcia- Luna-Aceves, “Robust content dissemination in
disrupted environments,” The third ACM Workshop on Chal lenged networks (CHANTS ’08), p. 7, 2008. [Online].
Available: http://portal.acm.org/citation.cfm?id=1409988
[6] W.GaoandG.Cao,“User-centricdatadisseminationindisrup- tion tolerant networks,” in INFOCOM, 2011
Proceedings IEEE. IEEE, 2011, pp. 3119–3127.
[7] A. Krifa, C. Barakat, and T. Spyropoulos, “Mobitrade: trading content in disruption tolerant networks,” in
Proceedings of the 6th ACM workshop on Challenged networks. ACM, 2011, pp. 31–36.
[8] Y.-T. Yu, J. Joy, R. Fan, Y. Lu, M. Gerla, and M. Sanadidi, “Dt-ican: A disruption-tolerant information-centric ad-
hoc network,” in Military Communications Conference (MILCOM), 2014 IEEE. IEEE, 2014, pp. 1021–1026.
[9] S. Y. Oh, D. Lau, and M. Gerla, “Content centric networking in tactical and emergency manets,” in Wireless Days
(WD), 2010 IFIP. IEEE, 2010, pp. 1–5.
References

www.helsinki.fi
[10] J. Ott, D. Kutscher, and C. Dwertmann, “Integrating dtn and manet routing,” in Proceedings of the 2006 SIGCOMM
workshop on Challenged networks. ACM, 2006, pp. 221–228.
[11] J.WhitbeckandV.Conan,“Hymad:Hybriddtn-manetrouting for dense and highly dynamic wireless networks,” Computer
Communications, vol. 33, no. 13, pp. 1483–1492, 2010.
[12] G. Tyson, N. Sastry, R. Cuevas, I. Rimac, and A. Mauthe, “A survey of mobility in information-centric networks,”
Communi- cations of the ACM, vol. 56, no. 12, pp. 90–98, 2013.
[13] Ó. R. Helgason, E. A. Yavuz, S. T. Kouyoumdjieva, L. Paje- vic, and G. Karlsson, “A mobile peer-to-peer system for op-
portunistic content-centric networking,” in Proceedings of the second ACM SIGCOMM workshop on Networking, systems,
and applications on mobile handhelds. ACM, 2010, pp. 21–26.
[14] M. Amadeo and A. Molinaro, “Chanet: A content-centric architecture for ieee 802.11 manets,” in Network of the Future
(NOF), 2011 International Conference on the. IEEE, 2011, pp. 122– 127.
[15] G. Tyson, E. Bodanese, J. Bigham, and A. Mauthe, “Beyond content delivery: Can icns help emergency scenarios?”
Network, IEEE, vol. 28, no. 3, pp. 44–49, 2014.
[16] A. Carzaniga, M. Papalini, and A. L. Wolf, “Content-based publish/subscribe networking and information-centric
networking,” in Proceedings of the ACM SIGCOMM workshop on Information-centric networking. ACM, 2011, pp. 56–61.
[17] J. Chen, L. Jiao, M. Arumaithurai, X. Fu, and K. Ramakrishnan, “Ps-ccn: Achieving an efficient publish/subscribe
capability for content-centric networks,” Technical Report No. IFI-TB-2011-04, Institute of Computer Science, University of
Goettingen, Tech. Rep., 2011.
References

Fault tolerance in Information Centric Networks

More Related Content

What's hot (19)

Similar to Fault tolerance in Information Centric Networks (20)

Recently uploaded (20)

Fault tolerance in Information Centric Networks