390 likes | 588 Views
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
E N D
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 • Applications: relief operations, warfront!!
Warfront BAS
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.
The Model B C A
Salient Features • Dynamic Topologies • Bandwidth Constrained Links • Energy Constrained Operation • Limited Security
A Future Network Base Station Fixed Network Ad Hoc Network Switch Mobile Host Wired Link Wireless Link Ad Hoc Network
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
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
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
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
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
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
Desired Properties • Improved delivery rate • Reduced variation in the number of packets received by the group members.
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.
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.
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?
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?
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.
Anonymous Gossip C B D E A
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.
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.
Example H 2 C 3 2 2 3 B G D 1 1 2 2 E A F
Probability Function k1 k2 k0 . . . kN Probability that nbr(i) is chosen as the next hop for gossip: 1 – ki/(k1+k2+....kN)
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!!!
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.
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’.
Cached Gossip C B D E A (E, 2) (C, 2)
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.
Data Structures Example: History Table: Msg1, Msg5, Msg7, … Msgn Lost Table: 2 3 4 6 ……. Lost Buffer: 2 3 Expected Sequence Number: n+1
Gossip Request Message • Group Address • Source Address • Lost Buffer • Size of Lost Buffer • Expected Sequence Number
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
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
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.
Packet Delivery vs Transmission Range Low transmission power => less connectivity and hence reduced performance.
Packet Delivery vs Maximum Speed Increased Speed => frequent link breakages and hence reduced performance
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.
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?