University College Of Engineering,Kota

CONTENT ADDRESSABLE NETWORK

Presented by – ALKA

11/638(CP-1)

Submitted To –

C.P. Gupta

(Asso. Prof. & HOD of CP & IT Dept.)

Mrs. Iti Sharma

Contents1. Introduction to CAN

2. CAN Routing

3. CAN Construction

4. CAN Problems

5. Node departure

6. Architecture improvements

a. Path Latency Improvement

b. Hop Latency Improvement

c. Mixed approaches

7. CAN Cons

8.CAN Pros

9.CAN summary

10.CAN References

What is CAN?

The goal was to make a scalable peer-to-peer file distribution system

Napster problem: centralized File Index

Gnutella problem: File Index completely decentralized

• There is a single point of failure: Low data availability

• Non scalable : No way to decentralize it except to build a new

system

• Network flood: Low data availability

• Non scalable: No way to group data

CAN - Content Addressable Network

What is CAN?CAN - Distributed, Internet-Scale, Hash table.

CAN provides Insertion, Lookup and Deletion operations under Key, Value

pairs (K,V), e.g. file name, file address

• CAN is designed completely Distributed

(does not require any centralized control)

• CAN design is Scalable, every part of the system maintains only a small

amount of control state and independent of the no. of parts

• CAN is Fault-tolerance (It provides a rooting even some part of the system is

crashed)

CAN features

ABOUT CAN

• Usage: P2P file-sharing systems, large scale storage management systems, wide-area name resolution services.

• It was one of the original four distributed hash tables introduced concurrently. (Chord, Pastry and Tapestry)

Content-Addressable Networks (CAN)

• d-dimensional hyperspace with n zones

6

y

Peer

Keys

Zone

x

CAN Routing

• d-dimensional space with n zones

• Two zones are neighbors if d-1 dimensions overlap

7

y

x

[x,y]Peer

Keys

lookup([x,y])

Routing in a CAN

A routing message hops from node to node, Getting closer and closer to the Destination.

A node only knows about its immediate Neighbors

Routing Path Length is (d/4)(n1/d)

As d approaches log(n), the totalPath length goes to log(n).

8

CAN Construction

Joining CAN

1.Pick a new ID [x,y]

2.Contact a bootstrap node

3.Route a message to [x,y], discover the current owner

4.Split owners zone in half

5.Contact new neighbors

9

y

xNew Node

[x,y]

CAN Construction

CAN architecture: Access

How to get an access to CAN system

1. CAN has an associated DNS domain

2. CAN domain name is resolved by DNS domain to Bootstrap server’s IP addresses3. Bootstrap is special CAN Node which holds only a list of several Nodes are currently in the systemUser scenario

1. A user wants to join the system and sends the request using CAN

domain name

4. The user chooses one of them and establishes a connection.

2. DNS domain redirects it to one of Bootstraps

3. A Bootstrap sends a list of Nodes to the user

CAN problems

Main problems:

1. Routing Latency

a. Path Latency - avg. # of hops per path

b. Hop Latency - avg. real hop duration

2. Increasing fault tolerance

3. Increasing data availability

Basic CAN architecture archives:

1. Scalability, State of distribution

2. Increasing data availability (Napster, Gnutella)

CAN construction: Node departure

Node is crashed

1. Periodically every node sends a message to all its neighbors

2. If Node does not receive from one of its neighbors a message for period of time t

it starts a TAKEOVER mechanism

3. It sends a takeover message to each neighbor of the crashed Node, the neighbor

which did not send a periodical message

4. Neighbors receive a message and compare its own Zone with the Zone of the

sender. If it has a smaller Zone it sends a new takeover message to all crashed

Node neighbors.

5. The crashed Node’s Zone is handled by the Node which does not get an answer

on its message for period of time t

Data stored on the crashed Node are unavailable until source owner refreshes the CAN state.

CAN construction: Node departure Node departure

b. Otherwise one of the neighbors handles two different zones

a. If Zone of one of the neighbors can be merged with departing Node’s Zone to produce a valid Zone. This neighbors handles merged Zone

CAN construction: Node departure 2. Node departure

b. Otherwise one of the neighbors handles two different zones

a. If Zone of one of the neighbors can be merged with departing Node’s Zone to produce a valid Zone. This neighbors handles merged Zone

CAN construction: Node departure 1. Node departure

b. Otherwise one of the neighbors handles two different zones

a. If Zone of one of the neighbors can be merged with departing Node’s Zone to produce a valid Zone. This neighbors handles merged Zone

In both cases (a and b):

1. Data from departing Node is moved to the

receiving Node

2. The receiving Node should update its

neighbor list

3. All their neighbors are notified about changes

and should update their neighbor lists

Path latency Improvements 1

Realities: multiple coordinate spaces

• Maintain multiple (R) coordinate spaces with

each Node

• Every Node contains different Zones in different

Realities, all zones are chosen randomly

• Contents of hash table replicated on every reality

• Each coordinate Space is called Reality

• All Realities have

The same no. of Zones

The same data

The same hash function

Path latency Improvements 2

The extended routing Algorithm for Realities

b. The request is forwarded in the best Reality

a. Every Node on the path checks in which of its realities a distance to the destination is the closest one

1. The destination Zone are the same for all realities

2. Each Zone can be own by many Nodes

3. For routing is applied a basic algorithm withfollowing extensions:

Path latency Improvements 2

The extended routing Algorithm for Realities

b. The request is forwarded in the best Reality

a. Every Node on the path checks in which of its realities a distance to the destination is the closest one

1. The destination Zone are the same for all realities

2. Each Zone can be own by many Nodes

3. For routing is applied a basic algorithm withfollowing extensions:

Path latency Improvements 2

The extended routing Algorithm for Realities

b. The request is forwarded in the best Reality

a. Every Node on the path checks in which of its realities a distance to the destination is the closest one

1. The destination Zone are the same for all realities

2. Each Zone can be own by many Nodes

3. For routing is applied a basic algorithm withfollowing extensions:

Path latency Improvements 3

n = 1000, equal zones

d Avg. path length

2 15

3 7.5

5 5

10 4.95

Multi-dimensioned Coordinates Spaces

• Average path length is

• the no. of dimensions d increases

• the average path Length decreases

)n*O(d 1/d

Hop latency improvement

RTT CAN Routing Metrics

2. New Metrics: Cartesian Distance + RTT

1. RTT is Round Trip Time (ping)

• Expanded Node is the closest to the destination by Cartesian Distance

• RRT between current Node and expanded Node is minimal for all optimal Nodes

number of dimensions

routing without RTT (ms) per hop

routing with RTT (ms) per hop

2 116.8 88.3

3 116.7 76.1

4 115.8 71.2

5 115.4 70.9

Mixed Improvement: Overloading Zones 1Overloading coordinate zones

• One Zone – many Nodes

• MAXPEERS – max no. of Nodes per Zone

• Every Node keeps list of its Peers

• The number of neighbors stays the same(O(1) in each direction)

•The general routing algorithm is used(from neighbor to neighbor)

Mixed Improvement: Overloading Zones 2Extended construction algorithm

New node A joins the system:

1. It discovers a Zone (owner Node B)

2. B checks: how many peers does it have

3. If less than MAXPEERS1. A is added as a new Peer

2. A gets a list of Peers and Neighbors from B

4. Otherwise

1. Zone is split in half

2. Peer list is split in half too

3. Refresh the peer and neighbor lists

Mixed Improvement: Overloading Zones 2Extended construction algorithm

New node A joins the system:

1. It discovers a Zone (owner Node B)

2. B checks: how many peers does it have

3. If less than MAXPEERS1. A is added as a new Peer

2. A gets a list of Peers and Neighbors from B

4. Otherwise

1. Zone is split in half

2. Peer list is split in half too

3. Refresh the peer and neighbor lists

Mixed Improvement: Overloading Zones 2Extended construction algorithm

New node A joins the system:

1. It discovers a Zone (owner Node B)

2. B checks: how many peers does it have

3. If less than MAXPEERS

1. A is added as a new Peer

2. A gets a list of Peers and Neighbors from B

4. Otherwise1. Zone is split in half

2. Peer list is split in half too

3. Refresh the peer and neighbor lists

Mixed Improvement: Overloading Zones 2Extended construction algorithm

New node A joins the system:

1. It discovers a Zone (owner Node B)

2. B checks: how many peers does it have

3. If less than MAXPEERS

1. A is added as a new Peer

2. A gets a list of Peers and Neighbors from B

4. Otherwise1. Zone is split in half

2. Peer list is split in half too

3. Refresh the peer and neighbor lists

Mixed Improvement: Overloading Zones 2Periodical self updating

1. Periodically, Node gets a peer list ofeach its neighbors

2. Node estimates a RRT to every node in peer list

3. Node chooses the closest peer Node as a New Neighbor Node in this direction

CAN construction improvements

Uniform Partitioning

1. The Node to be split compares the

volume of its Zone with Zones of its

Neighbors

2. The Zone with the largest volume

should be split

30

ISSUES

- Security (DoS attacks)

- Parameter tuning needed to achieve scalability (Cannot vary d as nincreases - n not known by any node)

- CAN maintenance protocol overhead? (Cost of update operation)

- Accommodation of administrative boundaries? (handling of key value pairs?)

- Initial knowledge of the deterministic hash function? Ways to be changed dynamically? Implications? (totalreconstruction of the CAN?)

- Specification of inter-update times, caching TTL values, etc.

Discussion - Pros

• Using some of the improvement made CAN a very robust routing and storage protocol.

• Using geographic location in the overlay creation would create smarter hops between close nodes.

31

Discussion - Cons

• Not much work on Load-Balancing the Keys

• When all of the Extra Features are running at once, CAN becomes quite complicated.

• Tough to guarantee uniform distribution of keys with hash functions on a large scale.

• Query Correctness

32

CAN - Weaknesses

• Impossible to perform a fuzzy search

• Susceptible to malicious activity

• Maintain coherence of all the indexed data (Network

overhead, Efficient distribution)

• Still relatively higher routing latency

• Poor performance w/o improvement

Discussion

• Addresses two key problems in the design of Content-Addressable Networks: scalable routing and indexing.

• Simulation results validate the scalability of our overall design – for a CAN with over 260,000 nodes, we can route with a latency that is less than twice the IP path latency.

• Future works– Secure CAN

– Key word searching

34

CAN: Summary CAN is scalable, distributed Hash Table

CAN provides:

• Dynamical Zone allocation

• Fault Tolerance Access Algorithm

• Stable Fault Tolerance Routing Algorithm

There are many improve techniques which

• Increase Routing Latency

• Increase Data availability

• Increase Fault Tolerance

The scalable, distributed, efficient P2P system was

designed and developed

REFERENCES

• [1] S. Ratnasamy, P. Francis, M. Handley, R. Karp, and S. Shenker. A Scalable Content-

Addressable Network. In ICSI Technical Report, Jan. 2001.

• [2] Balasubramanian, R.; Injong Rhee; Jaewoo Kang, "A scalable architecture for SIP

infrastructure using content addressable networks," Communications, 2005. ICC 2005. 2005

IEEE International Conference on , vol.2, no., pp.1314,1318 Vol. 2, 16-20 May 2005

• [3] Shidong Zhang; Bai Wang; Gengyu Wei; Chao Xin, "Web QoS Management Model

Based on CAN," Computational Intelligence and Design (ISCID), 2011 Fourth International

Symposium on , vol.1, no., pp.143,146, 28-30 Oct. 2011

• [4] Zhongtao Li; Weis, T., "Using zone code to manage a Content-Addressable Network for

Distributed Simulations," Communication Technology (ICCT), 2012 IEEE 14th International

Conference on , vol., no., pp.1350,1357, 9-11 Nov. 2012

• [5] Al-Omari, D.K.; Gurbani, V.K.; Anjali, T., "A novel architecture for a computer network

defense (CND) system using Content Addressable Networks (CAN)," Globecom Workshops

(GC Wkshps), 2012 IEEE , vol., no., pp.758,762, 3-7 Dec. 2012

THANK YOU