1

P2P Networks (Continue)

2

CAN

3

CAN :OverviewSupport basic hash table operations on key-value pairs (K,V): insert, search, deleteCAN is composed of individual nodesEach node stores a chunk (zone) of the hash table

A subset of the (K,V) pairs in the tableEach node stores state information about neighbor zonesRequests (insert, lookup, or delete) for a key are routed by intermediate nodes using a greedy routing algorithmRequires no centralized control (completely distributed)Small per-node state is independent of the number of nodes in the system (scalable)Nodes can route around failures (fault-tolerant)

4

CAN ZonesVirtual d-dimensionalCartesian coordinatesystem

Example: 2-d [0,1]x[1,0]Dynamically partitionedamong all nodesPair (K,V) is stored bymapping key K to a point P in the space using a uniform hash function and storing (K,V) at the node in the zone containing PRetrieve entry (K,V) by applying the same hash function to map K to P and retrieve entry from node in zone containing P

If P is not contained in the zone of the requesting node or its neighboring zones, route request to neighbor node in zone nearest P

5

Routing:

6

Routing:Follow straight line path through the Cartesian space from source to destination coordinatesEach node maintains a table of the IP address and virtual coordinate zone of each local neighborUse greedy routing to neighbor closest to destinationFor d-dimensional space partitioned into n equal zones, nodes maintain 2d neighbors

Average routing path length:

dnd 1

4

7

Join CANJoining node locates a bootstrap node using the CAN DNS entry

Bootstrap node provides IP addressesof random member nodes

Joining node sends JOIN request to random point P in the Cartesian spaceNode in zone containing P splits the zone and allocates “half” to joining node(K,V) pairs in the allocated “half” are transferred to the joining nodeJoining node learns its neighbor set from previous zone occupant

Previous zone occupant updates its neighbor set

8

Join CAN

9

Departure, Recovery and Maintenance

Graceful departure: node hands over its zone and the (K,V) pairs to a neighborNetwork failure: unreachable node(s) trigger an immediate takeover algorithm that allocate failed node’s zone to a neighbor

Detect via lack of periodic refresh messagesNeighbor nodes start a takeover timer initialized in proportion to its zone volumeSend a TAKEOVER message containing zone volume to all of failed node’s neighborsIf received TAKEOVER volume is smaller kill timer, if not reply with a TAKEOVER messageNodes agree on neighbor with smallest volume that is alive

10

CAN ImprovementsCAN provides tradeoff between per-node state, O(d), and path length, O(dn1/d)

Path length is measured in application level hopsNeighbor nodes may be geographically distant

Want to achieve a lookup latency that is comparable to underlying IP path latency

Several optimizations to reduce lookup latency also improve robustness in terms of routing and data availability

Approach: reduce the path length, reduce the per-hop latency, and add load balancingSimulated CAN design on Transit-Stub (TS) topologies using the GT-ITM topology generator (Zegura, et. al.)

11

Adding DimensionsIncreasing the dimensions of the coordinate space reduces the routing path length (and latency)

Small increase in the sizeof the routing table ateach node

Increase in number ofneighbors improvesrouting fault-tolerance

More potential next hopnodes

Simulated path lengthsfollow O(dn1/d)

12

Adding RealitiesNodes can maintain multiple independent coordinate spaces (realities)For a CAN with r realities:a single node is assigned r zonesand holds r independentneighbor sets

Contents of the hash tableare replicated for each reality

Example: for three realities, a(K,V) mapping to P:(x,y,z) maybe stored at three different nodes

(K,V) is only unavailable whenall three copies are unavailableRoute using the neighbor on the reality closest to (x,y,z)

13

Dimensions vs. RealitiesIncreasing the number of dimensions and/or realities decreases path length and increases per-node stateMore dimensions has greater effect on path lengthMore realities providesstronger fault-tolerance and increased data availabilityAuthors do not quantify the different storage requirements

More realities requires replicating (K,V) pairs

14

RTT RatioIncorporate RTT in routing metric

Each node measures RTT to each neighborForward messages to neighbor with maximum ratio of progress to RTT

15

Zone OverloadingOverload coordinate zones

Allow multiple nodes to share the same zone, bounded by a threshold MAXPEERSNodes maintain peer state, but not additional neighbor statePeriodically poll neighbor for its list of peers, measure RTT to each peer, retain lowest RTT node as neighbor(K,V) pairs may be divided among peer nodes or replicated

16

Multiple Hash FunctionsImprove data availability by using k hash functions to map a single key to k points in the coordinate spaceReplicate (K,V) and storeat k distinct nodes(K,V) is only unavailablewhen all k replicas aresimultaneouslyunavailableAuthors suggest queryingall k nodes in parallel toreduce average lookup latency

17

Other optimizationsRun a background load-balancing technique to offload from densely populated bins to sparsely populated bins (partitions of the space)Volume balancing for more uniform partitioning

When a JOIN is received, examine zone volume and neighbor zone volumesSplit zone with largest volumeResults in 90% of nodes of equal volume

Caching and replication for “hot spot” management

18

Chord

19

System ModelLoad balance:

Chord acts as a distributed hash function, spreading keys evenly over the nodes.

Decentralization:Chord is fully distributed: no node is more important than any other.

Scalability:The cost of a Chord lookup grows as the log of the number of nodes, so even very large systems are feasible.

Availability:Chord automatically adjusts its internal tables to reflect newly joined nodes as well as node failures, ensuring that, the node responsible for a key can always be found.

Flexible naming:Chord places no constraints on the structure of the keys it looks up.

20

System ModelThe application interacts with Chord in two main ways:

Chord provides a lookup(key) algorithm that yields the IP address of the node responsible for the key.The Chord software on each node notifies the application of changes in the set of keys that the node is responsible for.

21

The Base Chord ProtocolThe Chord protocol specifies how to find the locations of keys.It uses consistent hashing, all nodes receive roughly the same number of keys.When an N th node joins (or leaves) the network, only an O (1/N ) fraction of the keys are moved to a different location.In an N-node network, each node maintains information only about O (log N ) other nodes, and a lookup requires O (log N ) messages.

22

Consistent HashingThe consistent hash function assigns each node and key an m-bit identifier using a base hash function such as SHA-1.Identifiers are ordered in an identifier circle modulo 2m.Key k is assigned to the first node whose identifier is equal to or follows k in the identifier space. This node is called the successor node of key k.If identifiers are represented as a cycle of numbers from 0 to 2m – 1, then successor(k ) is the first node clockwise from k.

23

Consistent Hashing

An identifier circle consisting of the three nodes 0, 1, and 3.In this example, key 1 is located at node 1, key 2 at node 3,and key 6 at node 0.

24

Scalable key LocationLet m be the number of bits in the key/node identifiers.Each node, n, maintains a routing table with (at most) m entries, called the finger table.The i th entry in the table at node n contains the identity of the first node, s, that succeeds n by at least 2i -1 on the identity circle.

25

Scalable key Location

Definition of variables for node n, using m-bit identifiers.

26

Scalable key Location

(a) The finger intervals associated with node 1. (b) Finger tables and key locations for a net with nodes 0, 1, and 3, and keys 1, 2, and 6.

27

Scalable key LocationWith high probability (or under standard hardness assumption), the number of nodes that must be contacted find a successor in an N-node network is O (log N ).

28

Node JoinsEach node in Chord maintains a predecessor pointer, and can be used work counterclockwise around the identifier circle.When a node n joins the network:

Initialize the predecessor and fingers of node n.Update the fingers and predecessors of existing nodes to reflect the addition of n.Notify the higher layer software so that it can transfer state (e.g. values) associated with keys that node n is now responsible for.

29

Node Joins

(a) Finger tables and key locations after node 6 joins. (b) Finger tableand key locations after node 1 leaves. Changed entries are shown inblack , and unchanged in gray.

30

Failures and ReplicationWhen a node n fails, nodes whose finger tables include n must find n’s successor.Each Chord node maintains a “successor-list” of its r nearest successor on the Chord ring.A typical application using Chord might store replicas of the data associated with key at the k nodes succeeding the key.

31

Simulation: Load Balance

The mean and 1st and 99th percentiles of the number of keysstored per node in a 104 node network.

32

Load Balance

The probability density function (PDF) of the number of keysper node. The total number of keys is 5 x 105.

33

Path Length

The path length as a function of network size.

34

Path Length

The PDF of the path length in the case of a 212 node network.

35

Freenet

36

Freenet: OverviewP2P network for anonymous publishing and retrieval of data

DecentralizedNodes collaborate in storage and routing Data centric routingAdapts to demandsAddresses privacy & availability concerns

37

ArchitecturePeer-to-peer networkParticipants share bandwidth and storage spaceEach file in network given a globally-unique identifier (GUID)Queries routed through steepest-ascent hill-climbing search

38

GUID KeysCalculated with an SHA-1 hash Three main types of keys

Keyword Signed Keys (KSK)Content-hash keys

• Used primarily for data storage• Generated by hashing the content

Signed-subspace keys (SSK)• Intended for higher-level human use• Generated with a public key and (usually) text

description, signed with private key• Can be used as a sort of private namespace• Description e.g. politics/us/pentagon-papers

39

Keyword Signed Keys (KSK)User chooses a short descriptive text sdtext for a file,e.g., text/computer-science/esec2001/p2p-tutorialsdtext is used to deterministically generate a public/private key pairThe public key part is hashed and used as the file keyThe private key part is used to sign the fileThe file itself is encrypted using sdtext as keyFor finding the file represented by a KSK a user must know sdtext which is published by the provider of the FileExample: freenet:KSK@text/books/1984.html

40

KSK

FILE‘D’– key generation Pb + Pr ; SHA(Pb) D

+ Pr

KSKEncrypted FILE Signature

E(FILE, D)

41

SSK Generation and Query ExampleGenerate SSK:

Need: public/private keys, chosen text descriptionSign file with private key

Query for SSK:Need: public key, text descriptionVerify file signature with public key

Hash

Public Key

Hash

Description

Concatenate

Hash

SSK Key

42

Content Hash Keys (CHK)Derived from hashing the contents of the file Þ pseudo-unique file key to verify file integrityFile is encrypted with a randomly-generated encryption keyFor retrieval: CHK and decryption key are published (decryption key is never stored with the file)Useful to implement updating and splitting, e.g., in conjunction with SVK/SSK:

– to store an updateable file, it is first inserted under its CHK – then an indirect file that holds the CHK is inserted under a

SSK – others can retrieve the file in two steps given the SSK – only the owner of the subspace can update the file

Example: freenet:CHK@UHE92hd92hseh912hJHEUh1928he902

43

RoutingEvery node maintains a routing table that lists the addresses of other nodes and the GUID keys it thinks they hold.Steepest-ascent hill-climbing searchTTL ensures that queries are not propagated infinitelyNodes will occasionally alter queries to hide originator

44

RoutingRequesting Files:

Nodes forward requests to the neighbor node with the closest key to the one requestedCopies of the requested file may be cached along the request path for scalability and robustness

Inserting Files:If the same GUID already exists, reject insert – also propagate previous file along request pathPrevious-file propagation prevents attempts to supplant file already in network.

45

Data ManagementFinite data stores - nodes resort to LRURouting table entries linger after data evictionOutdated (or unpopular) docs disappear automaticallyBipartite eviction – short term policy

New files replace most recent files Prevents established files being evicted by attacks

46

Network growthNew nodes have to know one or more guys Problem: How to consistently decide on what key the new node specializes in?

Needs to be consensus decision – else denial attacks

Advertisement IP + H(random seed s0)Commitment - H(H(H(s0) ^ H(s1)) ^ H(s2))…….Key for new node = XOR of all seeds

Each node adds an entry for the new node

47

Network Growth

48

Performance

49

Comparisons