multicast ad hoc networks
DESCRIPTION
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 - PowerPoint PPT PresentationTRANSCRIPT
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
•?