1 / 39

Anonymous Gossip: Improving Multicast Reliability in Mobile Ad-Hoc Networks

Anonymous Gossip: Improving Multicast Reliability in Mobile Ad-Hoc Networks. Ranveer Chandra (joint work with Venugopalan Ramasubramanian and Ken Birman). What is an Ad-Hoc Network?. Wireless medium Mobile nodes No fixed infrastructure for communication

lynne
Télécharger la présentation

Anonymous Gossip: Improving Multicast Reliability in Mobile Ad-Hoc Networks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Anonymous Gossip: Improving Multicast Reliability in Mobile Ad-Hoc Networks Ranveer Chandra (joint work with Venugopalan Ramasubramanian and Ken Birman)

  2. What is an Ad-Hoc Network? • Wireless medium • Mobile nodes • No fixed infrastructure for communication • Applications: relief operations, warfront!!

  3. Warfront BAS

  4. The Model • A graph with ‘n’ nodes • A node can move in any direction with any speed • Connectivity is based on transmission power and land features • Frequently changing connectivity and neighborhood of the nodes.

  5. The Model B C A

  6. Salient Features • Dynamic Topologies • Bandwidth Constrained Links • Energy Constrained Operation • Limited Security

  7. A Future Network Base Station Fixed Network Ad Hoc Network Switch Mobile Host Wired Link Wireless Link Ad Hoc Network

  8. Issues in Multicast Routing • Minimize state stored in each node • Reduce the number of messages exchanged • Active adaptability of nodes to mobility, power • Local effect of link breakages

  9. Multicast Routing Protocols • Tree based: MAODV, AMRIS • Multicast performed over an underlying tree structure. • Mesh based: ODMRP, MCEDAR • Multicast over a mesh, or presence of alternate paths • None of them try to recover packets lost during reconfiguration

  10. MAODV: Route Discovery • Source Node sends RREQ • Sets ‘J’ Flag if joining • Retry for some time if unsuccessful • Become group leader if still unsuccessful • Other nodes set up reverse route entries Multicast Tree Group Member Tree Member

  11. MAODV: Route Reply • Only tree members can respond to a join request. • RREP is generated and unicast to the source • RREP has address of group member and distance from closest tree member • Intermediate nodes also update their tables on receiving an RREP. Multicast Tree Group Member Tree Member

  12. MAODV: Route Activation • Selects route based on seq # and hopcount • Unicasts a MACT to the selected next hop • On receiving MACT, the node updates entry in multicast route table • Unicasts its own MACT if it is not a tree member. Multicast Tree Group Member Tree Member

  13. MAODV: Other Considerations • Link breakages • Partitioned Trees • Leaving a group Details in draft-ietf-manet-aodv-05.txt Charles Perkins and Elizabeth Royer, March 2000

  14. Desired Properties • Improved delivery rate • Reduced variation in the number of packets received by the group members.

  15. A Modified Protocol • Borrows ideas from Bimodal Multicast • Proceed as a combination of 2 sub-protocols • Any existing protocol is used to multicast messages (MAODV in our case) • The Gossip Protocol recovers lost messages.

  16. The Gossip Protocol • A node randomly selects a group member. • Sends a message history • The receiver checks to see if it has any extra messages • The nodes then exchange messages and recover the ones that are lost.

  17. Gossip Protocol: Issues • How does a node know the group membership? • With whom does it gossip? • What is the direction of information exchange? • How is message history maintained?

  18. Group Membership Maintaining group membership: • Wired Networks: Easy because of domain sub-domain hierarchy • Ad-Hoc Networks: Very expensive to maintain information about all the group members. • Is it necessary to know the other group members?

  19. Anonymous Gossip • Randomly select one of the neighbors in the multicast tree. • Construct a gossip message and send it along the selected node. • On receiving a gossip message either forward it along the outgoing links or accept it with some probability if it is a group member.

  20. Anonymous Gossip C B D E A

  21. Gossip locally with a very high probability and occasionally with distant nodes Ensuring Locality of Gossip • Gossiping with a near member • Ensures reduced traffic • Gossiping with a distant node • Able to recover messages that were lost in an entire locality.

  22. Ensuring Locality of Gossip • Each node maintains a field called ‘nearest_member’ • Has the information of the nearest member by taking the link along the next hop node. • The probability of taking the next hop is inversely proportional to the ‘nearest_member’ value.

  23. Example H 2 C 3 2 2 3 B G D 1 1 2 2 E A F

  24. Probability Function k1 k2 k0 . . . kN Probability that nbr(i) is chosen as the next hop for gossip: 1 – ki/(k1+k2+....kN)

  25. Tree Overloading • All gossip messages are sent along the multicast tree: • Extra traffic on these links makes the tree congested • Shorter routes may exist • During tree repair no gossip messages can be sent Cached Gossip with some probability!!!

  26. Cached Gossip • Maintain a member cache: • Add a member on receiving a reply of an anonymous gossip request. • Delete a member if no route to it is known or it does not reply to a certain number of gossip requests. • Each entry is a three tuple of the address, distance and ‘last_gossip_time’ to the node.

  27. Sending Gossip Requests In each gossip round: • Use anonymous gossip with some probability. • If cached gossip is chosen: • Select near members with a very high probability. • Among them select the one with the least ‘last_gossip_time’.

  28. Cached Gossip C B D E A (E, 2) (C, 2)

  29. Other Data Structures Data Structures at each group member: • History Table: A bounded FIFO buffer of received messages. • Lost Table: Fixed size buffer to store sequence numbers of lost messages. • Lost Buffer: The most recent entries of the Lost Table.

  30. Data Structures Example: History Table: Msg1, Msg5, Msg7, … Msgn Lost Table: 2 3 4 6 ……. Lost Buffer: 2 3 Expected Sequence Number: n+1

  31. Gossip Request Message • Group Address • Source Address • Lost Buffer • Size of Lost Buffer • Expected Sequence Number

  32. The Protocol • Each group member periodically sends a gossip request message • On receiving a gossip request the receiver checks to see if it has a copy of the requested messages. • It then unicasts any messages found back to the requester. * Push would be expensive

  33. Gossip Reply Msgs 6, 3 Gossip Request The Protocol B A History table: msg1… msg6 History table: msg1, msg4, msg5 Lost Table: 2, 3 Lost Table: Lost Buffer: Lost Buffer: 3 Expected Sequence Number: 6 Expected Sequence Number: 7

  34. Simulation Results • Used GloMoSim • AG is implemented over MAODV and improvement is measured. • 200m x 200m area • 40 nodes and 13 group members • Random waypoint mobility model • One node sent 2201 packets to the multicast group over 440 seconds.

  35. Packet Delivery vs Transmission Range Low transmission power => less connectivity and hence reduced performance.

  36. Packet Delivery vs Maximum Speed Increased Speed => frequent link breakages and hence reduced performance

  37. Packet Delivery vs Number of Nodes

  38. Results • Gossip significantly improves the number of packets delivered. • The variation in the number of packets received by the different group members is reduced • Resulting protocol is more scalable.

  39. Conclusions and Future Work • A more reliable underlying multicast protocol would yield much better results. • Anonymous Gossip can be implemented over any multicast protocol without much overhead. • Is AG well suited for the internet?

More Related