Reliable Adaptive Lightweight Multicast Protocol Ken Tang, Scalable - - PowerPoint PPT Presentation

reliable adaptive lightweight multicast protocol
SMART_READER_LITE
LIVE PREVIEW

Reliable Adaptive Lightweight Multicast Protocol Ken Tang, Scalable - - PowerPoint PPT Presentation

Reliable Adaptive Lightweight Multicast Protocol Ken Tang, Scalable Network Technologies Katia Obraczka, UC Santa Cruz Sung-Ju Lee, Hewlett-Packard Laboratories Mario Gerla, UCLA Overview Ad hoc network introduction QualNet network


slide-1
SLIDE 1

Reliable Adaptive Lightweight Multicast Protocol

Ken Tang, Scalable Network Technologies Katia Obraczka, UC Santa Cruz Sung-Ju Lee, Hewlett-Packard Laboratories Mario Gerla, UCLA

slide-2
SLIDE 2

Overview

Ad hoc network introduction QualNet network simulator Reliable multicast in ad hoc networks

Scalable Reliable Multicast (SRM) case study Reliable Adaptive Lightweight Multicast (RALM)

protocol

Conclusion

slide-3
SLIDE 3

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

slide-4
SLIDE 4

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

slide-5
SLIDE 5

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

slide-6
SLIDE 6

Snippet of SRM Performance

  • 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
  • Retransmissions increase packet loss (since sources maintain sending

rate) which further triggers more retransmissions (as evident by control

  • verhead 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. Packet Delivery Ratio

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 Delivery Ratio UDP SRM

Traffic Rate vs. Control Overhead

5 10 15 20 25 30 500ms 400ms 300ms 200ms 100ms Packet Interdepature Interval Control Overhead UDP SRM

slide-7
SLIDE 7

Lessons Learned

  • Confirmed that ad hoc networks are extremely sensitive to

network load

  • Reliability cannot 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

slide-8
SLIDE 8

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

slide-9
SLIDE 9

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

slide-10
SLIDE 10

RALM Finite State Diagram

RecvNACK from feedback receiver IDLE TX RETX No packet to send Has packet to send Has packet to send RecvNACK (add receiver to list) RecvACK, (remove feedback receiver from list, list empty, has packet to send) RecvACK (remove feedback receiver from list, receiver list empty, no packet to send) RecvNACK (add receiver to list) RecvACK (remove feedback receiver from list, list not empty, choose next feedback receiver) Timeout

slide-11
SLIDE 11
  • 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 1
  • Node E and node F are now recorded in Receiver List for round-

robin send-and-wait loss recovery

RALM Example

S D C B F A E G

NACK NACK

seqno 5 seqno 6 seqno 7

{5, 7}

slide-12
SLIDE 12
  • Node S selects node E as the feedback receiver to reliably

transmit seqno 8

  • Only node E may respond
  • Node S then selects node F to reliably transmit seqno 9
  • Only node F may respond
  • Since there are no more receivers in Receiver List, revert to

multicasting at the application sending rate

RALM Example (cont’d)

S D C B F A E G

NACK 5 NACK 6

seqno 10 seqno 11

ACK ACK

seqno 8 {5, 7} seqno 5 {5, 7} seqno 6 {7} seqno 9 {7}

slide-13
SLIDE 13

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

slide-14
SLIDE 14

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

  • nce it receives all the packets
  • The source chooses a new feedback receiver from the Receiver List
  • Repeats this process until the list is empty
slide-15
SLIDE 15

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

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

slide-16
SLIDE 16

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
slide-17
SLIDE 17

Traffic Rate Experiment

  • No mobility
  • 5 sources and 10 receivers
  • Vary inter-departure rate from 500ms (2 packets per second) to

100ms (10 packets per second)

  • RALM: 100% reliability, low control overhead and delay

Traffic Rate vs. Packet Delivery Ratio

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 Delivery Ratio RALM UDP SRM

Traffic Rate vs. Control Overhead

5 10 15 20 25 30 500ms 400ms 300ms 200ms 100ms Packet Interdepature Interval Control Overhead RALM UDP SRM

slide-18
SLIDE 18

Mobility Experiments

Mobility vs. Packet Delivery Ratio

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 Delivery Ratio RALM UDP SRM

  • 5 sources and 10

receivers

  • 2 packets per

second

  • Random

waypoint from 0 m/s to 50 m/s with pause time

  • f 0 s
  • UDP outperforms

SRM

  • 100% data

delivery with RALM

slide-19
SLIDE 19
  • Same as traffic rate experiment
  • Compare RALM to multiple unicast TCP streams
  • 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

5000 10000 15000 20000 500ms 400ms 300ms 200ms 100ms Packet Interdeparture Interval Total Data Packets Received RALM TCP

slide-20
SLIDE 20

Conclusion

Traditional wired network approach to reliable multicast

does not work well in ad hoc networks

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 to achieve reliability

slide-21
SLIDE 21

Ongoing Work

Discriminate loss from mobility and congestion Simulate on top of MAODV Compare performance against other ad hoc reliable

transport multicast protocols (e.g., anonymous gossip)

Look at congestion control and reliability at various

layers