Ee689 lecture 13
This presentation is the property of its rightful owner.
Sponsored Links
1 / 17

EE689 Lecture 13 PowerPoint PPT Presentation


  • 91 Views
  • Uploaded on
  • Presentation posted in: General

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.

Download Presentation

EE689 Lecture 13

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


  • Login