anonymous gossip: improving multicast reliability in mobile ad-hoc networks
DESCRIPTION
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 - PowerPoint PPT PresentationTRANSCRIPT
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
A
B
C
Salient Features Dynamic Topologies Bandwidth Constrained Links Energy Constrained Operation Limited Security
A Future Network
Ad Hoc Network
Fixed Network
Base Station
Mobile Host
Wired Link
Wireless Link
Ad Hoc Network Switch
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 TreeGroup MemberTree 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 TreeGroup MemberTree 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 TreeGroup MemberTree Member
MAODV: Other Considerations Link breakages Partitioned Trees Leaving a group
Details in draft-ietf-manet-aodv-05.txtCharles 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-
protocolsi. Any existing protocol is used to
multicast messages (MAODV in our case)
ii. 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 MembershipMaintaining 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
A
BC
D
E
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.
Gossip locally with a very high probability and occasionally with distant nodes
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
A
BC
D
E21 1
3
2
32
22
F
G
H
Probability Function
k0k1
k2kN
.
.
.
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 sentCached 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 RequestsIn 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
A
BC
D
E(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
History Table: Msg1, Msg5, Msg7, … Msgn
Lost Table: 2 3 4 6 …….
Lost Buffer: 2 3
Expected Sequence Number: n+1
Example:
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
The Protocol
History table: msg1, msg4, msg5Lost Table: 2, 3
Lost Buffer: 3Expected Sequence Number: 6
History table: msg1… msg6
Lost Table: Lost Buffer:
Expected Sequence Number: 7
Gossip RequestA B
Gossip Reply Msgs 6, 3
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
Packet Delivery vs Number of Nodes
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?