foundation of peer-2-peer computing

51
Foundation of Peer-2-Peer Computing Designing Structured Peer-to-Peer Overlays as a Platform for Distributed Network Applications in Mobile Ad Hoc Networks Thomas Zahn, INRIA Rocquencourt, France Jochen Schiller, Freie Universität Berlin, Germany by Rizal Mohd Nor (Joey) [email protected]

Upload: kitra

Post on 25-Feb-2016

71 views

Category:

Documents


1 download

DESCRIPTION

Designing Structured Peer-to-Peer Overlays as a Platform for Distributed Network Applications in Mobile Ad Hoc Networks Thomas Zahn, INRIA Rocquencourt, France Jochen Schiller, Freie Universit ä t Berlin, Germany by Rizal Mohd Nor (Joey) [email protected]. Foundation of Peer-2-Peer Computing. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Foundation of Peer-2-Peer Computing

Foundation of Peer-2-Peer Computing

Designing Structured Peer-to-Peer Overlays as a Platform for Distributed Network Applications in

Mobile Ad Hoc NetworksThomas Zahn, INRIA Rocquencourt, France

Jochen Schiller, Freie Universität Berlin, Germany

byRizal Mohd Nor (Joey)

[email protected]

Page 2: Foundation of Peer-2-Peer Computing

Purpose of Paper

This papers tries to introduce several ideas in implementing structured overlays networks using

DHT which will help create better P2P applications over MANETs.

Page 3: Foundation of Peer-2-Peer Computing

Introduction

➲ Distributed Hash Tables (DHTs) have been proposed for large-scale network applications.

➲ Route a packet based on a key (rather than a fixed destination address) to the (unknown) node in the network that is currently responsible for the given key within a bounded number of hops.

➲ This overlay routing is also referred to as indirect routing.

Page 4: Foundation of Peer-2-Peer Computing

Overlay Networks

➲ Overlay vs. physical topology

➲ Example of the mapping between a P2P overlay network and the physical network.

Will Indirect overlay work on Ad hoc Mobile Networks?

Page 5: Foundation of Peer-2-Peer Computing

Problem

➲ DHTs do not concern themselves with physical (routing) of the underlying network, because it was designed to form overlay networks in Internet-based networks where physical routing is practically taken for granted. Hence, DHT:

● Cause an increased lookup complexity.● Unstructured P2P flooding will not scale to a growing

number of nodes● Requests messages will overwhelm the underlying

physical network.

Page 6: Foundation of Peer-2-Peer Computing

Why conventional DHTs Won't Work in MANETs

1. Overly stretch

A single overlay hop constitutes a physical route consisting of multiple physical hops

Hence, probability of a successful decreases for each physical hop

Page 7: Foundation of Peer-2-Peer Computing

Overly Stretch

Node S

Node TNode B

Node C

Node D

Overlay Hop

Physical Hop

Shortest Path

Multiple hops on the physical network might be tolerable in the internet, however, in MANETs it could be a significant problem? Why?

Probability of a successful delivery decreases with each physical hop

Page 8: Foundation of Peer-2-Peer Computing

Why conventional DHTs Won't Work in MANETs

2. Physical Route Discovery/Maintenance

Unlike the wired Internet with its comparatively stable infrastructure, the topology of a MANETs changes constantly.

Routing protocols for MANETs are predominantly concerned with rediscovering routes between nodes.

Hence, the expensive physical route discoveries in MANETs can quickly cancel out the efficiency of DHT-based overlay routing.

Page 9: Foundation of Peer-2-Peer Computing

Physical Route Discovery

Node S

Node TNode B

Node C

Node D

Flood the network

Flood the network again! To find new physical route

The lost of two nodes, almost flood the whole network twice. Imagine in MANETs, where nodes move constantly in and out of a network.

Page 10: Foundation of Peer-2-Peer Computing

Why conventional DHTs Won't Work in MANETs

3. DHT Routing Table Maintenance

DHTs impose certain requirements that their routing table entries have to match.

Depending on the structure and size of their routing tables, this overlay maintenance can incur significant amount of traffic.

Extra overlay maintenance traffic can easily add a sizeable portion to the overall traffic, which will further increase the probabilities of collision and use up precious bandwidth.

Page 11: Foundation of Peer-2-Peer Computing

Node S

Node TNode B

Node C

Node D

Have to updateDHT Table

DHT Routing Table Maintenance

Similarly, moving nodes will make overlay maintenance, as well as flooding the network for discovering the new physical route.

Page 12: Foundation of Peer-2-Peer Computing

Solution

1. MADPastry: A new structured overlays (DHT) with added design goals:

1. Consideration of physical locality2. Provide standard DHT interface and functionality3. Avoid physical route discoveries4. Minimize overlay maintenance5. Exploit any available packet information

Page 13: Foundation of Peer-2-Peer Computing

MADPastry

➲ Each node in a MADPastry network assigns itself a unique overlay id

● defines its logical position on the virtual overlay id ring.

➲ MADPastry routes the message to the node in the network that is currently responsible for the message key

● the node whose overlay id is currently the numerically closest to the message key among all MADPastry nodes in the network.

➲ To avoid message broadcasts (e.g. for route discovery) ● MADPastry considers physical locality in the construction of its

routing tables.

Page 14: Foundation of Peer-2-Peer Computing

MADPastry and the concept of Landmark

Fixed Landmark keys are chosen by dividing the logical overlay id space into equal sections

0800..00, 1800..00, ......., F800..00

Fixed Landmark

Keys

Range of Lower Keys

Range of HigherKeys

08000000 00000000- 07FFFFFF 00000000- 0FFFFFFF

18000000 10000000- 17FFFFFF 10000000- 1FFFFFFF

28000000 20000000- 27FFFFFF 20000000- 2FFFFFFF

38000000 30000000- 37FFFFFF 30000000- 3FFFFFFF

48000000 40000000- 47FFFFFF 40000000- 4FFFFFFF

58000000 50000000- 57FFFFFF 50000000- 5FFFFFFF

68000000 60000000- 67FFFFFF 60000000- 6FFFFFFF

78000000 70000000- 77FFFFFF 70000000- 7FFFFFFF

88000000 80000000- 87FFFFFF 80000000- 8FFFFFFF

98000000 90000000- 97FFFFFF 90000000- 9FFFFFFF

A8000000 A0000000- A7FFFFFF A0000000- AFFFFFFF

B8000000 B0000000- B7FFFFFF B0000000- BFFFFFFF

C8000000 C0000000- C7FFFFFF C0000000- CFFFFFFF

D8000000 D0000000- D7FFFFFF D0000000- DFFFFFFF

E8000000 E0000000- E7FFFFFF E0000000- EFFFFFFF

F8000000 F0000000- F7FFFFFF F0000000- FFFFFFFF

MADPastry define its Fixed Landmark Keys

However, in MANETs, nodes are highly dynamic, then how can a Landmark sustain for long?Answer: Employed a

technique called Random Landmarking (RLM)

Page 15: Foundation of Peer-2-Peer Computing

MadPastry Random Landmark (RLM) Nodes

75A1FFE2

1) Initially, all nodes assigns itself overlay IDs

75A1FFE2

B5A1FEE2

74A1FFE2

72A1FF2175A1FFE2

A0594822

78000050

2) Listen for Beacons, to find out if they are close to any Landmark keys, if not check to see if they are responsible for being temporary landmark node

3) Node currently closest to a landmark key, becomes temporary landmark Node (RLM)

4) The temporary Landmark Node periodically issue beacon messages

5) Node associates itself with closest temporary landmark if have the same prefixed

6) If need be, a node assigns itself a new overlay id sharing the same prefix with the new closest temporary landmark node.

75A1FEE2

Page 16: Foundation of Peer-2-Peer Computing

MADPastry & Cluster Nodes

➲ Random Landmark (RLM)● No fixed landmark nodes, landmark keys instead

➲ These RLM keys divide the logical overlay id space into equal sections

● 0800..00, 1800..00, ......., F800..00

➲ Node currently closest to a landmark key● Become temporary landmark node● Periodically issue beacon messages

➲ Nodes overhearing these beacon messages and periodically determine the physically closest temporary landmark node.

Page 17: Foundation of Peer-2-Peer Computing

MADPastry & Cluster Nodes

➲ Node associates itself with closest temporary landmark

● assumes same overlay ID prefix

➲ If need be, a node assigns itself a new overlay id sharing the same prefix with the new closest temporary landmark node.

● physically close nodes forming overlay clusters with common id prefixes

➲ Therefore, physically close nodes are also likely to be close in the overlay

Page 18: Foundation of Peer-2-Peer Computing

MADPASTRY➲ MADPastry maintains three different routing tables:

Standard Pastry Leaf Set for Indirect Routing

Stripped down Pastry routing table that only contains Landmark Key

AODV routing table for actual physical routes of overlay hops.

Node 3BBA1234

Page 19: Foundation of Peer-2-Peer Computing

Considerations of Physical Locality

Spatial Distribution of overlay ID prefixes

➲ Employed a technique called Random Landmarking (RLM)

➲ RLM are randomly selected nodes in the cluster. The RLM node, will be the nodeID in the stripped down Pastry routing table.

➲ RLM nodes peridically send out beacon messages to associate closest overhearing nodes

➲ Lead to formation of clusters, where nodes are close in the physical layer, as well as numerical space

Page 20: Foundation of Peer-2-Peer Computing

Provide Standard DHT interface and functionality

➲ MADPastry first uses the Pastry routing table or Pastry leaf set to determine the destination of the next overlay hop.

➲ Next, the AODV routing table is used to determine the next physical hop towards the next node

MADPastry routing(overlay and physical view)

Page 21: Foundation of Peer-2-Peer Computing

Avoid Physical Route Discovery

➲ A forwarding node will first restrict such a route discovery to its own cluster before broadcasting it network-wide.

➲ Only if no such alternative destination is available will MADPastry engage in an AODV-style route discovery broadcast.

Page 22: Foundation of Peer-2-Peer Computing

Minimize overlay maintenance

➲ MADPastry nodes do not proactively perform routing table maintenance to avoid costly maintenance overhead.

➲ Routing tables are updated using information from received and overheard packets.

Page 23: Foundation of Peer-2-Peer Computing

Exploit Any Available Packet Information

➲ All other routing entries are obtained by overhearing data packets. A MADPastry packet consists of the following information:

● The AODV sequence number of the packet's source ● The AODV sequence number of the packet's previous physical hop ● The overlay id of the packet's source ● The overlay id of the packet's previous physical hop

➲ When a node overhears a packet, it updates its AODV routing table by extracting AODV sequence numbers in the packet and gains a new route to the packet's source. The existing routes are overwritten. Additionally, by overlay identifiers it inserts the nodes into the appropriate entries in the Pastry routing table and Pastry leaf set. Similarly all existing entries are overwritten.

Page 24: Foundation of Peer-2-Peer Computing

MADPastry RoutingVirtual Overlay ID ring

Physical Network

Node 17 which intends to send a packet with key prefixed B, will be forwarded to the cluster with B prefixed. (B7E9A014,17)

17 54

39

32

90

4

35

47

79

75A1FFE2

75A1FFE2

B207D11F

B207D11F

B7E1C101

B7E1C101

B7E9A014

B7E9A014

Node 17      

Pastry Routing Table    

Row 0 1 2 3

0 03438687 16378092 29476800 --

  NodeID 70 NodeID 88 NodeID 238 NodeID 17

  4 5 6 7

  45357677 58712758 65568991 79416102

  NodeID 71 NodeID 184 NodeID 145 NodeID 70

  8 9 A B

  84219169 97434904 A1610906 B7E9A014

  NodeID 113 NodeID 160 NodeID 187 NodeID 4

  C D E F

  C3739014 D3237999 E4514927 F4905072

  NodeID 233 NodeID 86 NodeID 212 NodeID 165

Page 25: Foundation of Peer-2-Peer Computing

MADPastry RoutingVirtual Overlay ID ring

Physical Network

17 54

39

32

90

4

35

47

79

75A1FFE2

75A1FFE2

B207D11F

B207D11F

B7E1C101

B7E1C101

B7E9A014

B7E9A014

Intermediate nodes on the physical path of an overlay hop consult their AODV table for the corresponding next physical hop.

Node 17

Dest NextHop Others

56 256 --

132 25 --

61 87 --

85 34 --

4 54 --

Page 26: Foundation of Peer-2-Peer Computing

MADPastry RoutingVirtual Overlay ID ring

Physical Network

17 54

39

32

90

4

35

47

79

75A1FFE2

75A1FFE2

B207D11F

B207D11F

B7E1C101

B7E1C101

B7E9A014

B7E9A014

Intermediate nodes on the physical path of an overlay hop consult their AODV table for the corresponding next physical hop.

Node 54

Dest NextHop Others

78 214 --

122 26 --

53 219 --

25 52 --

4 32 --

Page 27: Foundation of Peer-2-Peer Computing

MADPastry RoutingVirtual Overlay ID ring

Physical Network

17 54

39

32

90

4

35

47

79

75A1FFE2

75A1FFE2

B207D11F

B207D11F

B7E1C101

B7E1C101

B7E9A014

B7E9A014

Intermediate nodes on the physical path of an overlay hop consult their AODV table for the corresponding next physical hop.

Node 32

Dest NextHop Others

23 135 --

174 247 --

224 256 --

176 28 --

4 39 --

Page 28: Foundation of Peer-2-Peer Computing

MADPastry RoutingVirtual Overlay ID ring

Physical Network

17 54

39

32

90

4

35

47

79

75A1FFE2

75A1FFE2

B207D11F

B207D11F

B7E1C101

B7E1C101

B7E9A014

B7E9A014

Intermediate nodes on the physical path of an overlay hop consult their AODV table for the corresponding next physical hop.

Node 39

Dest NextHop Others

23 135 --

174 247 --

224 256 --

176 28 --

4 90 --

Page 29: Foundation of Peer-2-Peer Computing

MADPastry RoutingVirtual Overlay ID ring

Physical Network

17 54

39

32

90

4

35

47

79

75A1FFE2

75A1FFE2

B207D11F

B207D11F

B7E1C101

B7E1C101

B7E9A014

B7E9A014

Intermediate nodes on the physical path of an overlay hop consult their AODV table for the corresponding next physical hop.

Node 90

Dest NextHop Others

23 135 --

174 247 --

224 256 --

176 28 --

4 4 --

Page 30: Foundation of Peer-2-Peer Computing

MADPastry RoutingVirtual Overlay ID ring

Physical Network

17 54

39

32

90

4

35

47

79

75A1FFE2

75A1FFE2

B207D11F

B207D11F

B7E9A014

B7E1C101

B7E1C101B7E9A014

When a packet reaches the destination of an overlay hop, that node again consults its Pastry routing table and/or leaf set to determine the next overlay hop.

Smaller Larger

B1011101 B7E1C101

B1E12301 B9E67701

B1E1C321 BAE16201

Leaf Set

Page 31: Foundation of Peer-2-Peer Computing

MADPastry RoutingVirtual Overlay ID ring

Physical Network

17 54

39

32

90

4

35

47

79

75A1FFE2

75A1FFE2

B207D11F

B207D11F

B7E9A014

B7E1C101

B7E1C101B7E9A014

Consults its AODV routing table for the physical route to execute this overlay hop.

Node 4

Dest NextHop Others

23 135 --

174 247 --

224 256 --

176 28 --

35 47 --

Page 32: Foundation of Peer-2-Peer Computing

MADPastry RoutingVirtual Overlay ID ring

Physical Network

17 54

39

32

90

4

35

47

79

75A1FFE2

75A1FFE2

B207D11F

B207D11F

B7E9A014

B7E1C101

B7E1C101B7E9A014

Consults its AODV routing table for the physical route to execute this overlay hop.

Node 47

Dest NextHop Others

23 135 --

174 247 --

224 256 --

176 28 --

35 35 --

Page 33: Foundation of Peer-2-Peer Computing

MADPastry RoutingVirtual Overlay ID ring

Physical Network

17 54

39

32

90

4

35

47

79

75A1FFE2

75A1FFE2

B207D11F

B207D11F

B7E9A014

B7E1C101

B7E1C101B7E9A014

When a packet reaches the destination of an overlay hop, that node again consults its Pastry routing table and/or leaf set to determine the next overlay hop.

32

Smaller Larger

B1011101 B7E9A014

B1E12301 B8E67701

B1E1C321 BAE16201

Leaf Set

Page 34: Foundation of Peer-2-Peer Computing

Case Study: MADPASTRY➲ General Performance Evaluation

● Success Rate

MADPastry was compared to a variation of MADPastry that does not exploit physical locality in the construction of its routing table (NO RLM)

MADPastry was also compared to a Broadcast agent that maintains no overhead structure and extra maintenance overhead. It simply broadcasts all packets network-wide.

Clearly, it shows that MADPastry outperform the other protocols for high volume of nodes. This is because, using MADPastry, there are less flooding in the network. Therefore, less collision and network congestion.

Page 35: Foundation of Peer-2-Peer Computing

Case Study: MADPASTRY

➲ General Performance Evaluation● Total Generated Network Traffic

Clearly MADPastry produces less network traffic, since MADPastry was designed to reduce broadcast in the network by using passing packet information to update AODV routing table and overlay maintenance.

Page 36: Foundation of Peer-2-Peer Computing

Case Study: MADPASTRY➲ General Performance Evaluation

● Overlay StretchMADPastry performs better than the variant of Pastry that does not consider localization by using LandMarks (NO RLM).

This is because after identifying a LandMark in a different cluster of nodes, MADPastry uses its AODV table to route packets. However, it cannot perform better than Broadcast since, broadcast will flood the network and find the closest physical route.

Page 37: Foundation of Peer-2-Peer Computing

THE MAPNAS NAME SERVICEDistributed Service Discovery

➲ In MAPNaS, a resource (e.g. a file) is identified by a unique resource key that is mapped into the logical MADPastry ID space.

file123

Hash()

B7E9A578

Page 38: Foundation of Peer-2-Peer Computing

THE MAPNAS NAME SERVICE

➲ Nodes store the resource descriptors they are responsible for their local MAPNaS repository.

● The resource key along with the specific network address of the resource.

Page 39: Foundation of Peer-2-Peer Computing

THE MAPNAS NAME SERVICEResource Advertisement

➲ When a node in a MADPastry network wants to make a local resource (e.g. a file) available to other nodes in the network

● Assign a hash key to that resource● By hashing the resource's name.

➲ Node A will then construct a resource descriptor consisting of

● The resource key ● The physical network address (e.g. IP address) of the

resource provider.

➲ Using MADPastry, the descriptor is routed to the node currently responsible for the resource key.

➲ That recipient node will then store the resource descriptor in its local repository.

Page 40: Foundation of Peer-2-Peer Computing

THE MAPNAS NAME SERVICEResource Advertisement

file123

Hash()

B7E9A578

{B7E9A578, 17}

Node 79 is responsible for resource key B7E9A578

Node 17(75A1FFE2) send the packet to node 4(B207D11F) using MADPastry routing table. As indicated in the overlay hop. This first overlay hop takes 5 physical hops.

Node 5(B207D11F) will then consult its MADPastry routing table to determine the next node to forward the advertisement packet. So the next overlay hop will be at node 35(B7E1C101) and takes 2 physical hops.

In the final hope, Node 35(B7E1C101) will then consult its MADPastry leaf set to forward the packet to node 79(B7E1C101) and takes 1 physical hops. Upon reception of this advertisement, node 79 will store the resource descriptor {B7E9A578,17} in its local repository.

Page 41: Foundation of Peer-2-Peer Computing

THE MAPNAS NAME SERVICEResource Discovery

➲ Node A wants to find a resource➲ Node A does not know who has the

resource desciptor➲ Node A

● Assign a hash key to that resource eg. Filename ● By hashing the resource's name.

➲ Using MADPastry, the key is routed to the node currently responsible for the resource key.

➲ The node currently responsible for the resource will respond to node A request by sending a resource descriptor

Page 42: Foundation of Peer-2-Peer Computing

THE MAPNAS NAME SERVICEResource Discovery

file123

Hash()

B7E9A578

{B7E9A578, 17}

Node 63(A101D11F) is interested in the file123. Node 63 does not know which node provides the file. So node 63 produces the key for the filename.Node 63(A101D11F) sends a request for a matching resource descriptor

towards the hash key B7E9A578 using MADPastry. The first overlay hop, the request will be delivered to node 35(B7E1C101) with 3 physical hops.Node 35(B7E1C101) will then forward the request to its leaf set member

node 79(B7E9A014) who is responsible for the given hash key. Node 79 will check its local repository and send a response containing the descriptor {B7E9A578,17} back to the requester, node 63.

OverlayPhysical OverlayPhysical

Page 43: Foundation of Peer-2-Peer Computing

THE MAPNAS NAME SERVICEHandovers

Cluster 1 Cluster 2

N

75A1F552

L1 R1

Resource descriptors

Resource descriptors

75A1F532 75A1F623

B573AB63

L2 R2

Resource descriptors

Resource descriptors

B573AA10 B573AD88

In MANETs, nodes are mobile. Therefore, one node, could be moving from one cluster to another. So a node will eventually have a different overlay Node ID as it joins another cluster.So what happens to the resource descriptors in a node?

The moving node, have changed its cluster membership, and need to pass the resource descriptors that are in its local repository to its old left, and right leaf set members as those two nodes will now be responsible numerically closest to the corresponding descriptor keys.

Page 44: Foundation of Peer-2-Peer Computing

THE MAPNAS NAME SERVICEHandovers

➲ Since a handover packet could be lost. ● A node can potentially end up having some

resource descriptors in its local repository that it is actually not responsible for.

➲ Each node periodically checks its local repository for such descriptors and hands them over.

Page 45: Foundation of Peer-2-Peer Computing

MAPNaS (Performance Evaluation)

MASNaS is compared to two different kinds of resource discovery service:

● Using the simple broadcast-based approach, where service discovery request are broadcast throughout the network.

● Using the expanding ring search, where in order to avoid unnecessary network-wide broadcast, a service discovery request is first propagated within a local scope of 3 hops, and increase the number of hops if the request gets no response.

MAPNaS outperforms the other discovery methods in producing lower traffic in the network. This is because: The expanding ring tend to send more hops in the network if it does not get a response after a few initial request. Broadcast-based would flood the whole network with a request. MAPNaS will use MADPastry routing to selectively choose the cluster numerically and physically closest to the responsible node for the resource by using the hash key.

Page 46: Foundation of Peer-2-Peer Computing

MAPNaS (Performance Evaluation)Clearly MAPNaS outperforms the other discovery methods in success rates. This is because: The expanding ring tend to send more hops in the network if it does not get a response after a few initial request. This will cause congestion and collision, hence reducing success rate. Similar, broadcast-based would flood the whole network with a request. This will cause congestion and collision in the network and reduce the success rate. MAPNaS will use MADPastry routing to selectively choose the cluster numerically and physically closest to the responsible node for the resource by using the hash key. The low traffic generated will result in less congestion and collision, thereby, giving better success rate.

Page 47: Foundation of Peer-2-Peer Computing

Conclusion

➲ 5 design principles were introduced as a considerations when designing structured overlays to be use on top of MANETs.

➲ In very volatile networks (e.g. high node velocities), it becomes more and more challenging to maintain the DHT structures

➲ In smaller networks, one does not necessarily need to maintain DHT structures but could use less complex approaches as well.

➲ Approaches with small structural overhead – such as broadcasting – might be preferable over DHT-based approaches.

Page 48: Foundation of Peer-2-Peer Computing

My thoughts

➲ Assume that nodes moves slowly, if nodes were moving around faster, how does it perform for resource discovery, since handover delay time might cause resource not found.

➲ No study on contention of a particular node.➲ Will it work in a sparse network? Where

clusters are small and separated far from each other.

Page 49: Foundation of Peer-2-Peer Computing

Extended thoughts?

• The experiments were done with the following parameters:

• Node Density is 100 nodes/km2

using the random distribution model.

• Radio range is 250m.• If we consider the unit disc model

in simulations on ns2, the unit density is 25 nodes per unit.

• The issue of routing may not be as important as contention in this case.

• Since most nodes won’t have problems in finding the next hop for most protocol.

1km

1km

In one unit radius of transmission,The nodes are too many.

0.5m

0.5m

Page 50: Foundation of Peer-2-Peer Computing

The End

Thank You For Listening

Page 51: Foundation of Peer-2-Peer Computing

Quiz

1. Give 2 reason why unstructured DHT will not work in MANETs?

2. How does the ever changing routing in MANETs affects network traffic?

3. How does MADPastry handles the introduction of a new node?

4. Give an example of an application using MADPastry?

5. What is the major drawback in using MADPastry where nodes move from one cluster to the other?