Multicast ad hoc networks

Multicast in ad hoc nets Review of Multicasting in wired

networks Tree based wireless multicast Mesh based wireless multicast – ODMRP Performance comparison

Scalable multicast M-LANMAR Backbone

Reliable, congestion controlled multicast RALM, RALM with M-LANMAR

Overview

Reliable multicast in ad hoc networks Scalable Reliable Multicast (SRM)

case study Reliable Adaptive Lightweight

Multicast (RALM) protocol Conclusion Combining RALM with M-LANMAR

Reliable Multicast in Ad Hoc Networks Challenges in MANETs

Node mobility Hidden terminals make MANET

sensitive to network load and congestion

Our goal: design a multicast transport protocol that achieves both reliability and congestion control

Case Study of the Scalable Reliable Multicast (SRM) Protocol Representative of “wired” reliable

multicast protocols Negative acknowledgements

(NACKs) Multicasting of NACKs Nack’ed packets are

retransmitted NACK suppression Local recovery

Scalable Reliable Multicast (SRM) Representative of “wired” reliable

multicast protocols Receivers use repair request

messages to request retransmission of lost data Repair requests are generated until

the lost data is recovered Any multicast group member that has

the requested data may answer by sending a repair message.

NACKs and data retransmissions are multicast to the entire group

Suppresses repair request and repair messages

Traffic Rate vs. Packet Delivery Ratio

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

500ms 400ms 300ms 200ms 100ms

Packet Interdepature Interval

Packet

Deli

very R

ati

o

UDP

SRM

SRM Performance: packet delivery ratio

50 nodes in 1500m x 1500m area 5 sources and 10 receivers Traffic rate varies from 2 packets per

second to 10 packets per second SRM degrades as traffic rate increases

SRM Performance: control overhead

SRM degrades as traffic rate increases Retransmissions increase packet loss (since

sources maintain sending rate) which further triggers more retransmissions (as control overhead graph) which leads to even more packet loss

Packet loss caused by increased load in the first place. Retransmission without slowing down the sources just adds more load to the network

Traffic Rate vs. Control Overhead

0

5

10

15

20

25

30

500ms 400ms 300ms 200ms 100ms

Packet Interdepature Interval

Co

ntro

l O

verh

ead

UDP

SRM

Lessons Learned Confirmed that ad hoc networks are

extremely sensitive to network load Reliability can not be achieved by

retransmission requests alone SRM under-performed plain UDP

Strong indication that some form of congestion control in conjunction with retransmissions is also needed to accompany reliability

Lessons Learned (cont’d)

Losses may not be correlated: downstream nodes may still receive packets even if upstream nodes do not, especially considering mobility

Packet loss may be due to wireless medium error rather than simply congestion

Rate-based transmission Transmit at “native rate” of

application as long as no congestion/loss is detected

When congestion/loss (via NACKs) is detected, fall back to send-and-wait

In send-wait mode control congestion and perform loss recovery

Reliability achieved with congestion control AND retransmissions

Reliable Adaptive Lightweight Multicast (RALM) Highlights

Node E and node F detect loss Node E detects loss of packet with seqno 5 Node F detects loss of packets with seqno 5

and 6 All receivers receive seqno 7 Both E and F unicast NACK to node S

Node E and node F are now recorded in Receiver List for round-robin send-and-wait loss recovery

RALM Example

S

DC

B

F

A

E

G

NACK

NACK

seqno 5seqno 6seqno 7

{5, 6}

Node S selects node E as the feedback receiver to reliably transmit seqno 8 Only node E may respond (using NACK)

Node S then selects node F to reliably transmit seqno 9 Only node F may respond (using NACK)

Since there are no more receivers in Receiver List, revert to multicasting at the application sending rate

RALM Example (cont’d)

S

DC

B

F

A

E

G

NACK 5

NACK 6

seqno 10seqno 11

ACK

ACK

seqno 8{5, 6}

seqno 5{5, 6}

seqno 6{6}

seqno 9{6}

Feedback Receiver Only a single (feedback) receiver

acknowledges data Feedback receiver list: list of nodes

that have sent NACKs The source specifies the feedback

receiver in the multicast data Feedback receiver is rotated in round

robin order Unicast ACK or NACK to the source If feedback receiver fails to respond

to source after specified number of times, receiver is skipped until the next round

Loss Recovery When the feedback receiver detects loss

packets, it unicasts a NACK to the source for retransmission Lost packets are requested one at a time

until it has all the up-to-date packets It slows down the source transmission when

congestion is detected The source multicasts both new and

retransmitted packets Other nodes who may have lost those

packets will receive the retransmission The feedback receiver unicasts ACK to the

source once it receives all the packets The source chooses a new feedback receiver

from the Receiver List Repeats this process until the list is empty

Simulation Environment QualNet for network simulation Compare UDP, SRM and RALM on top of

ODMRP/AODV/IEEE802.11DCF in various scenarios UDP: no congestion control or error control SRM: error control without congestion

control RALM: congestion control and error recovery

50 nodes in 1500m by 1500m area Channel capacity: 2 Mb/s Propagation range: 375 meters Two-ray ground reflection model

Free space path loss for near sight Plane earth path loss for far sight

Random waypoint mobility model Constant bit rate “application-driven” traffic

Simulation Environment (Cont’d) Metrics

Packet delivery ratio: Effectiveness and reliability

Control overhead The total number of data and control packets sent by routing and transport layer protocols: the number of data packets received by the receivers

Efficiency End-to-end latency: Timeliness

Traffic Rate Experiment

5 sources and 10 receivers, No mobility Vary inter-departure rate from 500ms (2 packets

per second) to 100ms (10 packets per second) RALM: 100% reliability, RALM is better than SRM (degrades as traffic rate increases)

Traffic Rate vs. Packet Delivery Ratio

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

500ms 400ms 300ms 200ms 100ms

Packet Interdepature Interval

Packet

Deli

very R

ati

o

RALM

UDP

SRM

Traffic Rate Experiment

Vary inter-departure rate from 500ms to 100ms

RALM: low control overhead and delay

Traffic Rate vs. Control Overhead

0

5

10

15

20

25

30

500ms 400ms 300ms 200ms 100ms

Packet Interdepature Interval

Co

ntr

ol

Overh

ead

RALM

UDP

SRM

Mobility ExperimentsMobility vs. Packet Delivery Ratio

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 m/s 10 m/s 20 m/s 30 m/s 40 m/s 50 m/s

Mobility

Packet

Deli

very

Rati

o

RALM

UDP

SRM

5 sources and 10 receivers, 2 packets per second Random waypoint from 0 m/s to 50 m/s UDP outperforms SRM 100% data delivery with RALM

Same as traffic rate experiment On average, 25% more packets delivered than

TCP RALM performance differential grows with

increase in receiver set

RALM vs. Multiple Unicast TCP Experiments

RALM vs. Multiple Unicast TCP

0

5000

10000

15000

20000

500ms 400ms 300ms 200ms 100ms

Packet Interdeparture Interval

To

tal D

ata

Pa

ck

ets

Re

ce

ive

d

RALM

TCP

Conclusion Traditional wired network approach

to reliable multicast does not work well in ad hoc networks (i.e., SRM) Mobility Hidden-terminal problems Contention-based MAC protocols

Must take into account also congestion control, not simply error control (i.e., SRM)

RALM utilizes congestion control in conjunction with reliable delivery /error control to achieve reliability

Ongoing Work

Discriminate loss from mobility and congestion

Simulate on top of M-AODV Compare performance against

other ad hoc reliable transport multicast protocols (e.g., anonymous gossip)

Look at congestion control and reliability at various layers

Combining RALM with M-LANMAR Reliable Adaptive Lightweight Multicast

(RALM) Source continually monitors the channel

condition No congestion: the source transmits at

“native” rate Congestion detected (i.e., packet loss

feedback via NACK): the source falls back to “send-and-wait” mechanism (source stops upon receiving a NACK; it resumes when it receives an ACK )

Combining with M-LANMAR Only landmarks return feedback (e.g.

NACK/ACK) to the source Prevents unnecessary feedback implosion

Simulation: M-LANMAR with RALM (1000 nodes, 3 teams for each group, 5 multicast groups)

Delivery Ratio

0

0.2

0.4

0.6

0.8

1

1.2

512 1024 1280 1689.6 2560 5120

Offered Load (Bytes/sec)

Del

iver

y R

atio

M- LANMAR w/ UDP ODMRP w/ UDP

M- LANMAR w/ RALM ODMRP w/ RALM

M-LANMAR with RALM: 100% reliability

ODMRP with RALM: suffers from feedback implosion congestion is unacceptable

•?