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 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?