ee689 lecture 13
Skip this Video
Download Presentation
EE689 Lecture 13

Loading in 2 Seconds...

play fullscreen
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