EE689 Lecture 13 Review of Last Lecture Reliable Multicast

In unicast, receiver ACKs give feedback --- Sender takes responsibility in transmitting data In Multicast, many receivers -- too difficult for sender to keep track of every receiver’s status ACK Implosion

Receiver-driven Multicast Sender keeps no information of receivers’ status Receivers send NAKs to reduce ACK implosion problem Several receivers may not get a packet on a loss - still possible to get many replies from receivers

Receiver-driven Multicast Unicast NAKs to sender –Reduces overhead when packet losses are isolated and rare –Packet loss early in the tree will result in too many NAKs Multicast NAKs to sender –Others missing packets need not send NAKs –Could cause burden on receivers if only one receiver doesn’t get the packet

Receiver-driven Multicast Multicasting NAKs –if every receiver, sends a NAK immediately after getting an out-of-sequence packet, too many NAKS at once! –Wait for a random time, send a NAK –If some one else sends a NAK, suppress your NAK –Getting random timers tricky business

Receiver-driven Multicast More scalable than sender-driven Loss recovery times may be larger –Receiver may not know if last packet is lost –Realizes packet loss after receiving an out-of- sequence packet –Has to send a NAK and then reply from sender –May be faster if sender times out if ACK is not received in time

Loss Recovery Sender remulticasts packet to everyone Possible to organize packet retransmissions into another multicast group Receivers listen to the loss-multicast groups only on packet losses –could be more scalable

Hierarchical Multicast Organize multicast into a number of groups One Designated Receiver takes responsibility for reliability On packet loss, NAK propagated to DR If DR has data, retransmits or remulticasts with limited scope to the group If DR doesn’t have data, sends NAK to sender

Hierarchical Multicast More scalable than other multicast protocols Need mechanisms to find out DR Need mechanisms to delegate DR function to another node as primary DR node leaves multicast Specially useful when multicast over wide geographic boundaries, keep one DR in each country for example

Hierarchical Multicast RMTP: Reliable Multicast Transport Protocol - Bell Labs DR nodes may need more power than other receivers Extra overhead in protocol Quicker recovery times when losses are local

Token-ring Multicast Pass a token around a local group Have token => DR for that packet/segment Distribute responsibility over time Need protocol for passing token around Need protocol for associating a receiver with data segments Again more scalable than flat multicast

Heterogeneous Receivers Not all the receivers may have same Bandwidth connectivity Normally would result in sending data at the lowest quality that everyone can receive At higher qualities –Too many packets dropped – Too much load on sender on retransmissions –everyone suffers delays or loss in quality

Heterogeneous Receivers Send video in multiple layers Base layer and enhancement layers Base layer provides the least quality –For example, at 28.8 kbs Enhancement layers can be added if higher BW connectivity available –Higher quality video for some

Heterogeneous Receivers Layered video - use multiple multicast groups Subscribe to all of them or some of them based on BW connectivity This strategy works well with dynamic network conditions –congestion ( or BW availability) changes over time

Network dynamics -multicast When BW is plentiful (low loss rate), subscribe to all layers As loss rate increases, subscribe to few layers Sender transmits at the maximum level subscribed by the receiver group Different layers will have different trees of distribution

Multicast - Compression Multi layer video coding popular Some applications adjust rates on the layers dynamically RLM - UC Berkeley, Café Mocha - TAMU Vxtreme, RealVideo Number of other tools

Multicast Summary Reliability poses interesting challenges Receiver-driven multicast more scalable Hierarchical multicast more scalable Receiver Heterogenity forces video multicast to be layered –allows flexible QOS /distribution of video