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) rnor@cs.kent.edu Foundation of Peer-2-Peer Computing

This papers tries to introduce several ideas in implementing structured overlays networks using DHT which will help create better P2P applications over MANETs. Purpose of Paper

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.

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?

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.

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

Overly Stretch Overlay Hop Physical Hop Node D Shortest Path Node C Node T Node B Node S 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

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.

Physical Route Discovery Flood the network again! To find new physical route Node D Node C Node T Node B Node S The lost of two nodes, almost flood the whole network twice. Imagine in MANETs, where nodes move constantly in and out of a network. Flood the network

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.

DHT Routing Table Maintenance Node D Node C Node T Node B Node S Similarly, moving nodes will make overlay maintenance, as well as flooding the network for discovering the new physical route. Have to update DHT Table

Solution • MADPastry: A new structured overlays (DHT) with added design goals: • Consideration of physical locality • Provide standard DHT interface and functionality • Avoid physical route discoveries • Minimize overlay maintenance • Exploit any available packet information

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

MADPastry and the concept of Landmark MADPastry define its Fixed Landmark Keys • Fixed Landmark keys are chosen by dividing the logical overlay id space into equal sections • 0800..00, 1800..00, ......., F800..00 However, in MANETs, nodes are highly dynamic, then how can a Landmark sustain for long? Answer: Employed a technique called Random Landmarking (RLM)

75A1FFE2 MadPastry Random Landmark (RLM) Nodes 1) Initially, all nodes assigns itself overlay IDs 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 72A1FF21 B5A1FEE2 75A1FEE2 78000050 75A1FFE2 74A1FFE2 3) Node currently closest to a landmark key, becomes temporary landmark Node (RLM) 75A1FFE2 A0594822 4) The temporary Landmark Node periodically issue beacon messages 6) If need be, a node assigns itself a new overlay id sharing the same prefix with the new closest temporary landmark node. 5) Node associates itself with closest temporary landmark if have the same prefixed

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.

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

MADPASTRY • MADPastry maintains three different routing tables: Node 3BBA1234 Stripped down Pastry routing table that only contains Landmark Key AODV routing table for actual physical routes of overlay hops. Standard Pastry Leaf Set for Indirect Routing

Considerations of Physical Locality • 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 Spatial Distribution of overlay ID prefixes

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)

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.

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.

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.

MADPastry Routing Virtual Overlay ID ring Node 17 which intends to send a packet with key prefixed B, will be forwarded to the cluster with B prefixed. (B7E9A014,17) B7E1C101 B7E9A014 B207D11F 75A1FFE2 79 B7E9A014 35 B7E1C101 47 17 54 4 75A1FFE2 32 B207D11F 90 39 Physical Network

Intermediate nodes on the physical path of an overlay hop consult their AODV table for the corresponding next physical hop. MADPastry Routing Virtual Overlay ID ring B7E1C101 B7E9A014 B207D11F 75A1FFE2 79 B7E9A014 35 B7E1C101 47 17 54 4 75A1FFE2 32 B207D11F 90 39 Physical Network

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. MADPastry Routing Virtual Overlay ID ring B7E1C101 B7E9A014 B207D11F 75A1FFE2 79 B7E9A014 Leaf Set 35 B7E1C101 47 17 54 4 75A1FFE2 32 B207D11F 90 39 Physical Network

Consults its AODV routing table for the physical route to execute this overlay hop. MADPastry Routing Virtual Overlay ID ring B7E1C101 B7E9A014 B207D11F 75A1FFE2 79 B7E9A014 35 B7E1C101 47 17 54 4 75A1FFE2 32 B207D11F 90 39 Physical Network

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. MADPastry Routing Virtual Overlay ID ring B7E1C101 B7E9A014 B207D11F 75A1FFE2 79 B7E9A014 Leaf Set 35 B7E1C101 47 17 54 4 75A1FFE2 32 32 B207D11F 90 39 Physical Network

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.

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.

Case Study: MADPASTRY • General Performance Evaluation • Overlay Stretch MADPastry 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.

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

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.

THE MAPNAS NAME SERVICEResource Advertisement • When a node in a MADPastry network wants tomake 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.

file123 Hash() B7E9A578 THE MAPNAS NAME SERVICEResource Advertisement Node 79 is responsible for resource keyB7E9A578 {B7E9A578, 17} 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. 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.

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

file123 Hash() B7E9A578 THE MAPNAS NAME SERVICEResource Discovery {B7E9A578, 17} Overlay Physical Overlay Physical 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.

Resource descriptors Resource descriptors Resource descriptors Resource descriptors L1 R1 L2 R2 75A1F532 75A1F623 B573AA10 B573AD88 THE MAPNAS NAME SERVICEHandovers Cluster 1 Cluster 2 75A1F552 B573AB63 N 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. 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 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.

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.

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.

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.

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.

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. Extended thoughts? 1km 0.5m 0.5m 1km In one unit radius of transmission, The nodes are too many.

The End Thank You For Listening

Foundation of Peer-2-Peer Computing