2. Gossip protocol Michael Gustus Dmitriy Mosheyev Supervisor : Roie Melamed

3. Introduction

4. Introduction Consider the problem of designing a protocol that broadcasts messages to all of the processors in a network. One can be interested in different metrics of a broadcast protocol, such as:  the number of messages it generates,  the time needed for the broadcast to complete,  or the reliability of the protocol.

5. Introduction  Gossip protocols are probabilistic in nature: a node chooses its partner node with which to communicate randomly.  They are scalable because each node sends only a fixed number of messages, independent of the number of nodes in the network.

6. Introduction  In addition, a node does not wait for acknowledgments nor does it take some recovery action should an acknowledgment not arrive.  They achieve fault-tolerance because a node receives copies of a message from different nodes.  No node has a specific role to play, and so a failed node will not prevent other nodes from continuing sending messages. Hence, there is no need for failure detection or specific recovery actions.

7. Project Definition

8. Goal  The goal of this project is to implement the Gossip protocol in the GloMoSim network simulator.

9. Gossip Structure  Araneola dynamically constructs an overlay network, and spreads information by gossiping over this overlay. Network

10. Gossip Structure Neighbors: The immediate neighbors of the peer (the peer it is connected to). Receiving this vector of neighbor allows each peer to easily calculate vector-2, a vector of all the peers within a radius of two from the peer (the immediate neighbors of the peer are one link away from the peer where each neighbor of one of its immediate is two links away from it).

11. Gossip Structure Local View: Each peer maintains a local view, which contains random peers it is not connected to. These random peers are gossiped in order to: 1.avoid graph partition. 2.calculate the number of disjoint paths between any two peers.

12. The Join Mechanism  Each connection in the overlay is a duplex connection.  The number of duplex connections of a peer is called the peer’s rank.  Each peer strives to achieve a small constant rank, independent to the number of peers in the system. Typical values for this rank are 4 or 5.  A duplex connection in the overlay is created when one peer sends a join request to another peer and this request is accepted by the other peer.

13. Join? OK The Join Mechanism There are two opposite tendencies: integrate a peer into the system as fast as possible;integrate a peer into the system as fast as possible; maintaining a small rank by every peer.maintaining a small rank by every peer. Araneola defines two kinds of requests with different priorities:  URGENT JOIN request  JOIN request

14. JOIN URGENT JOIN The Join Mechanism  An URGENT REQUEST will most likely be accepted where a “regular” JOIN request may be rejected.  Typically, upon joining the system, a peer will issue one URGENT JOIN request in order to integrate into the system and several other JOIN requests in order to achieve a higher reliability. Network

15. The Join Mechanism  Araneola defines four thresholds: URGENT LOWURGENT LOW LOWLOW HIGHHIGH URGENT HIGHURGENT HIGH  Every peer strives to achieve a rank equals to LOW.  Typical values for URGENT LOW is 1 and for LOW is 4-5, which means that the first request is an URGENT JOIN request while the following requests are JOIN requests.

16. The Join Mechanism  Accepting URGENT JOIN request: If the rank of the peer who received the urgent request is lower than URGENT HIGH threshold, then the request is accepted.If the rank of the peer who received the urgent request is lower than URGENT HIGH threshold, then the request is accepted.  Accepting JOIN request: The rank of the peer who received the JOIN request is lower than HIGH threshold.The rank of the peer who received the JOIN request is lower than HIGH threshold. To avoid partitions in the overlay graph, the peer that receives the join request checks if accepting this request will create a “small” circle in the graph (a circle which consists of four or less peers connecting to each other).To avoid partitions in the overlay graph, the peer that receives the join request checks if accepting this request will create a “small” circle in the graph (a circle which consists of four or less peers connecting to each other).

17. Disconnecting Circles  Periodically, though in small frequency, every peer exchanges its vector-2 with every other peer that is two links away from it.  Exchanging these vectors enables each peer to calculate vector-4, a vector, which includes every peer within a radius of four links from the specific peer. Network Whenever a peer’s rank exceed the LOW threshold, the peer tries to disconnect several of its connections until it reaches to a rank of LOW.

18. Disconnecting Circles  A connection to a specific peer is removed only if there is a known other path to this peer (i.e., if there is a circle which contain the two peers in vector-4).  If such a circle is discovered, a disconnect request is issued trying to disconnect the circle.  Upon receiving a disconnect request, the peer checks if accepting this request will not result in truncation of vector-4. This check is done in order to avoid a situation where simultaneously disconnect requests partition the graph. Network

19. GloMoSim simulator

20.  GloMoSim is a scalable simulation environment for wireless and wired network systems.  It is being designed using the parallel discrete-event simulation capability provided by Parsec. Parsec  GloMoSim currently supports protocols for a wired, purely wireless network and hybrid network with both wired and wireless capabilities.

21. GloMoSim simulator  Most network systems are currently built using a layered approach that is similar to the OSI seven layer network architecture. The proposed protocol stack will include models for the channel, radio, MAC, network, transport, and higher layers. Layers Protocols MobilityRandom waypoint, Random drunken, Trace based Radio PropagationTwo ray and Free space Radio ModelNoise Accumulating Packet Reception ModelsSNR bounded, BER based with BPSK/QPSK modulation Data Link (MAC)CSMA, IEEE 802.11 and MACA Network (Routing)IP with AODV, Bellman-Ford, DSR, Fisheye, LAR scheme 1, ODMRP, WRP TransportTCP and UDP ApplicationCBR, FTP, HTTP and Telnet The protocols being shipped with the current library include the following:

22. Parsec Language  PARSEC - for PARallel Simulation Environment for Complex systems is a C-based discrete-event simulation language. It adopts the process interaction approach to discrete- event simulation. An object (also referred to as a physical process) or set of objects in the physical system is represented by a logical process.is a C-based discrete-event simulation language. It adopts the process interaction approach to discrete- event simulation. An object (also referred to as a physical process) or set of objects in the physical system is represented by a logical process. Interactions among physical processes (events) are modeled by timestamped message exchanges among the corresponding logical processes.Interactions among physical processes (events) are modeled by timestamped message exchanges among the corresponding logical processes.

23. Parsec Language  One of the important distinguishing features of PARSEC is its ability to execute a discrete-event simulation model using several different asynchronous parallel simulation protocols on a variety of parallel architectures. PARSEC is designed to cleanly separate the description of a simulation model from the underlying simulation protocol, sequential or parallel, used to execute it.  PARSEC provides powerful message receiving constructs that result in shorter and more natural simulation programs.  File Extensions:.pc – C source code.h - C header files.pi – Message file created and maintained internally by Parsec (don’t edit)

24. Project Structure

25. Main Modules  The program is divided into four main modules: Gossip - the Gossip protocol implementation in the single node. Includes all the connectivity and lifetime implementation of Gossip algorithm.Gossip - the Gossip protocol implementation in the single node. Includes all the connectivity and lifetime implementation of Gossip algorithm. Gossip_LinkedList - the data structures used in the program to implement the LocalView and other different data bases stored in the single node.Gossip_LinkedList - the data structures used in the program to implement the LocalView and other different data bases stored in the single node.

26. Main Modules Gossip_TX_Data - in this module we implemented the data sharing algorithm as it was defined in the Gossip protocol. This is the flow of data packets over the network in order to reach every node in the system.Gossip_TX_Data - in this module we implemented the data sharing algorithm as it was defined in the Gossip protocol. This is the flow of data packets over the network in order to reach every node in the system. Gossip_utility - this is the master module from which we control the processes in the Gossip network, like:Gossip_utility - this is the master module from which we control the processes in the Gossip network, like:  to know when the connectivity stage of the protocol is over.  when to start sending packets.  who produces new data packets and all its parameters.  of packets to be sent by each producing node.

27. Gossip Module  The protocol behavior defined by the messages each node sends and receives.  There are 8 different message types: MSG_APP_UrjentJoin – urgent join request from another node.MSG_APP_UrjentJoin – urgent join request from another node. MSG_APP_Join – join request from another node.MSG_APP_Join – join request from another node. MSG_APP_WakeUp – when received this message the node if it is not participating in the Gossip will try to enter the Gossip network by throwing a coin. This message can be sent by the utility node or the node itself.MSG_APP_WakeUp – when received this message the node if it is not participating in the Gossip will try to enter the Gossip network by throwing a coin. This message can be sent by the utility node or the node itself. MSG_APP_Accept_Join – the message is received when node’s Join request was accepted by another node.MSG_APP_Accept_Join – the message is received when node’s Join request was accepted by another node.

28. Gossip Module MSG_APP_Decline_Join – the message is received when node’s Join request was declined by another node.MSG_APP_Decline_Join – the message is received when node’s Join request was declined by another node. MSG_APP_Disconnect – the message is received when the node was disconnected from other node from any reason.MSG_APP_Disconnect – the message is received when the node was disconnected from other node from any reason. MSG_APP_ProduceDataPacket – the message is received by the producing node then it is time to produce a new data packet.MSG_APP_ProduceDataPacket – the message is received by the producing node then it is time to produce a new data packet. MSG_APP_DataPacket – the message is received when a new data packet is arrived.MSG_APP_DataPacket – the message is received when a new data packet is arrived.

29. Gossip_TX_Data Module  In this module we define the structure that each node holds when sending/receiving data packets: typedef struct gossip_tx_data_str { FILE* recFile;// pointer to log-file of received packets FILE* prodFile;// pointer to log-file of produced packets int** packetSeqNum; // seqNums of received packets from other nodes other nodes BOOL producePackets;// do I produce my own packets int packetsToProduce;// number of packets I need to produce int mySeqNum;// next seqNum of my packet double produceDelay;// delay between packets in seconds } GossipTXData;

30. Gossip_utility Module  This module uses one network node as the utility node. This node doesn’t participate in the Gossip protocol and it is used only to control the processes in the Gossip network. We use it to know when we have reached the static mode after the connectivity stage of the protocol is over.We use it to know when we have reached the static mode after the connectivity stage of the protocol is over. When to start sending packets.When to start sending packets. To set the parameters of the producing nodes.To set the parameters of the producing nodes.

31. User Guide

32. Environment To run the simulation on the Microsoft Windows platform, first we need the following products to be installed on the computer:  Microsoft Visual Studio 6  Parsec compiler  GloMoSim simulator The Parsec compiler and GloMoSim simulator you can download here: http://pcl.cs.ucla.edu/projects/glomosim/obtaining _glomosim.html http://pcl.cs.ucla.edu/projects/glomosim/obtaining _glomosim.html http://pcl.cs.ucla.edu/projects/glomosim/obtaining _glomosim.html

33. Installing Parsec and Glomosim  Download the compressed Parsec and Glomosim files to your machine.  Uncompress the Parsec file into some directory: unzip parsec.zipunzip parsec.zip Move the platform specific Parsec directory tree to the desired place on your disk.Move the platform specific Parsec directory tree to the desired place on your disk.

34. Parsec environment using VC++  Set global environmental variables: set PATH = %PATH%;set PATH = %PATH%;......\parsec\windowsnt-4.0-vc6\bin......\parsec\windowsnt-4.0-vc6\bin set PCC_DIRECTORY =......\parsec\windowsnt-4.0-vc6set PCC_DIRECTORY =......\parsec\windowsnt-4.0-vc6  Set environmental variables of Visual Studio 6 by running the file VCVARS32.BAT that is found in the Visual Studio folder.

35. Installing Glomosim  Uncompress the Glomosim library.  Change the directory to main.  make (or “makent” on NT), to build Glomosim.

36. Compiling the project  To compile the program: open the cmd session.open the cmd session. run the VCVARS32.BAT file from the Visual Studio.run the VCVARS32.BAT file from the Visual Studio. go to directory main in the glomosim.go to directory main in the glomosim. compile the project by running the file make.bat.compile the project by running the file make.bat.

37. Running the project  If the compiling stage finished successfully the main executable file glomosim.exe is created in the bin directory.  To run the project you need 2 configuration files to be set as will be explained later.  The configuration files are: config.inconfig.in app.confapp.conf  To run the program: go to directory bin in the glomosim.go to directory bin in the glomosim. configure the config.in and app.conf to your needs.configure the config.in and app.conf to your needs. in the cmd session run: “glomosim config.in”in the cmd session run: “glomosim config.in”

38. Configuration files  There are two configuration files containing the project parameters that can be changed. config.inconfig.in NUMBER-OF-NODES - This parameter represents the number of nodes being simulated. app.confapp.conf GOSSIP GOSSIP where: – number of nodes that produce new packets. – number of nodes that produce new packets. – number of new packets each producing node must send. – number of new packets each producing node must send. – delay between packets in seconds. (NanoSecond = 0.000000001 sec). – delay between packets in seconds. (NanoSecond = 0.000000001 sec). – the probability for data packet to be lost, and not to get to its destination. Probability range is 0-100: 0 - no loses, 100 - 100% loses. – the probability for data packet to be lost, and not to get to its destination. Probability range is 0-100: 0 - no loses, 100 - 100% loses.

39. Results Processing During the execution, the program generates two output files for each node in the network. One file is for the received packets, and the other file is for the new packet that this node produced and sent. These files are located in the results directory. We used the Perl script calc.pl to process these result files. calc.pl usage: perl calc -orr all output.csv

40. Results

41. Protocol performance with packet loss  Test purpose: To show the loss packet probability affect on reliability of the protocol.To show the loss packet probability affect on reliability of the protocol.  Test parameters: Thresholds:Thresholds:  Urgent Low = 1  Urgent Low = 4  High = 10  Urgent High = 15 Number of sending nodes = 1Number of sending nodes = 1 Number of sent packets for each sending node = 50Number of sent packets for each sending node = 50 Number of nodes = 100Number of nodes = 100

42. Protocol performance with packet loss  Results: In the following table we collected the results from the tests with different packets loss probability.In the following table we collected the results from the tests with different packets loss probability.  The first row indicates the loss packet probability.  The first column indicates the number of rounds it took to protocol to distribute the packets.

43. Protocol performance with packet loss

44. Explanation:  Here we can see that the bigger percentage of packet loss probability the less reliability, moreover the protocol remain pretty reliable even with 50% packet loss.  The number of rounds it takes to distribute packets is bigger for packets with high packet loss probability.  More than 80% of the packets arrive to their destination at the fourth round. This happens due to the fact that the protocol builds graph, and for current configuration (the thresholds and number of nodes) the depth of the spanning tree of this graph is ~4, so it takes ~4 rounds to distribute packets to their destination. Protocol performance with packet loss

45. Probability dependence of packets loss This is another way of looking on how the packet loss probability affects the reliability. For the packet loss probability less than 50%, the reliability is pretty good (~90%).

46. Packet loss between 0% and 30%  Test purpose: To show the packet loss probability affect on reliability of the protocol in the range 0f 0 to 30%. This is very interesting due to the fact that real internet conditions are quite similar to these values.To show the packet loss probability affect on reliability of the protocol in the range 0f 0 to 30%. This is very interesting due to the fact that real internet conditions are quite similar to these values.  Test parameters: Thresholds:Thresholds:  Urgent Low = 1  Urgent Low = 4  High = 10  Urgent High = 15 Number of sending nodes = 1Number of sending nodes = 1 Number of sent packets for each sending node = 50Number of sent packets for each sending node = 50 Number of nodes = 100Number of nodes = 100

47. Protocol performance with packet loss  Results: In the following table we collected the results from the tests with different packets loss probability.In the following table we collected the results from the tests with different packets loss probability.

48. Protocol performance with packet loss

49. The results in the range of 0-30% packets loss show pretty good reliability of the Gossip protocol.

50. Thresholds effect  Test purpose: To show the affect of thresholds on the reliability results. In this test we set the thresholds to be lower then the original, this means that every node will strive for not more than 2 neighbors.To show the affect of thresholds on the reliability results. In this test we set the thresholds to be lower then the original, this means that every node will strive for not more than 2 neighbors.  Test parameters: Thresholds:Thresholds:  Urgent Low = 1  Urgent Low = 2  High = 5  Urgent High = 8 Number of sending nodes = 1Number of sending nodes = 1 Number of sent packets for each sending node = 50Number of sent packets for each sending node = 50 Number of nodes = 100Number of nodes = 100

51. Thresholds effect In the following table we collected the results from the tests with different packets loss probability.

52. Thresholds effect

53. Explanation:  The number of rounds it takes to distribute the packets is higher. It can be explained due to the fact that in this configuration each node have less neighbors, thus the tree depth the protocol builds is bigger, so the distribution time is larger.  Same works for reliability: if each node have less neighbors, the probability that this node won’t success to promote the information is higher, thus the overall reliability is lower.

54. Thresholds effect Here we can see that already from 30% packet loss probability the reliability is fewer than 80%. These results are much worse than the original.

55. Network size effect  Test purpose: To show the affect of number of nodes in the gossip network on the number of rounds it takes the protocol to distribute the packet to all the recipients.To show the affect of number of nodes in the gossip network on the number of rounds it takes the protocol to distribute the packet to all the recipients.  Test parameters: Thresholds:Thresholds:  Urgent Low = 1  Urgent Low = 2  High = 5  Urgent High = 8 Number of sending nodes = 1Number of sending nodes = 1 Number of sent packets for each sending node = 50Number of sent packets for each sending node = 50 Packets loss probability = 30%Packets loss probability = 30%

56. Network size effect Here we can see that the number of rounds it takes the protocol to distribute the packets depends on number of nodes. Moreover the dependency is logarithmic (depends on the depth tree that protocol builds.)