Ee689 lecture 13
1 / 17

EE689 Lecture 13 - PowerPoint PPT Presentation

  • Uploaded on

EE689 Lecture 13. Review of Last Lecture Reliable Multicast. 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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' EE689 Lecture 13' - star

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Ee689 lecture 13
EE689 Lecture 13

  • Review of Last Lecture

  • Reliable Multicast

Reliable multicast
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
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 multicast1
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 multicast2
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 multicast3
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
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
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 multicast1
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 multicast2
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
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
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 receivers1
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 receivers2
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
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
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
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