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

About This Presentation
Title:

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) – PowerPoint PPT presentation

Number of Views:74
Avg rating:3.0/5.0
Slides: 40
Provided by: Ranveer
Category:

less

Transcript and Presenter's Notes

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


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
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
D
G
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/(k1k2....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 n1
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
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 gt less connectivity and
hence reduced performance.
36
Packet Delivery vs Maximum Speed
Increased Speed gt 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?
Write a Comment
User Comments (0)
About PowerShow.com