CAN is a distributed hash table that provides a scalable peer-to-peer architecture for data storage and retrieval. It addresses issues with centralized systems like Napster and completely decentralized systems like Gnutella by partitioning the network's virtual space among nodes. Nodes are responsible for zones in this space, and messages are routed through the network to the node responsible for a given zone. Several improvements were proposed to enhance CAN, such as using multiple coordinate spaces to improve routing latency and overloading zones to increase data availability. While powerful, CAN has some limitations regarding load balancing, query correctness, and susceptibility to attacks.

1. 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

2. Contents
1. 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

3. 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

4. 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

5. 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)

6. Content-Addressable Networks (CAN)
• d-dimensional hyperspace with n zones
6
y
Peer
Keys
Zone
x

7. 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])

8. 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 total
Path length goes to log(n).
8

9. 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
x
New Node
[x,y]

10. CAN Construction

11. 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 addresses
3. Bootstrap is special CAN Node which holds only a list of
several Nodes are currently in the system
User 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

12. 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)

13. 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.

14. 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

15. 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

16. 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

17. 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

18. 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 with
following extensions:

19. 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 with
following extensions:

20. 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 with
following extensions:

21. 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

22. 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

23. Mixed Improvement: Overloading Zones 1
Overloading 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)

24. Mixed Improvement: Overloading Zones 2
Extended 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. Otherwise
1. Zone is split in half
2. Peer list is split in half too
3. Refresh the peer and neighbor lists

25. Mixed Improvement: Overloading Zones 2
Extended 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. Otherwise
1. Zone is split in half
2. Peer list is split in half too
3. Refresh the peer and neighbor lists

26. Mixed Improvement: Overloading Zones 2
Extended 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. Otherwise
1. Zone is split in half
2. Peer list is split in half too
3. Refresh the peer and neighbor lists

27. Mixed Improvement: Overloading Zones 2
Extended 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. Otherwise
1. Zone is split in half
2. Peer list is split in half too
3. Refresh the peer and neighbor lists

28. Mixed Improvement: Overloading Zones 2
Periodical self updating
1. Periodically, Node gets a peer list of
each 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

29. 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. 30
ISSUES
- Security (DoS attacks)
- Parameter tuning needed to achieve scalability (Cannot vary d as n
increases - 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? (total
reconstruction of the CAN?)
- Specification of inter-update times, caching TTL values, etc.

31. 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

32. 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

33. 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

34. 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

35. 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

36. 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

37. THANK YOU