1 / 15

CIS679: Multicast and Multimedia (more)

CIS679: Multicast and Multimedia (more). Review of Last Lecture More about Multicast. Review of Last Lecture. Multicast basics Motivation and Issues Addressing Routing. Reliable Multicast. In unicast, receiver ACKs give feedback ---Sender takes responsibility in transmitting data

lis
Download Presentation

CIS679: Multicast and Multimedia (more)

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. CIS679: Multicast and Multimedia (more) • Review of Last Lecture • More about Multicast

  2. Review of Last Lecture • Multicast basics • Motivation and Issues • Addressing • Routing

  3. 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

  4. Receiver-driven Multicast • Sender based schemes don’t scale well as number of receivers increase • Receiver based schemes scale better • Receivers can decide the level of reliability needed as well as the level of quality desired etc.

  5. Send NAKs • Sender keeps no information of receivers’ status • Receivers send NAKs to reduce ACK implosion problem • How to send NAKs? • Unicast NAKs to sender • Multicast NAKs

  6. 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

  7. Multicast NAKs • Others missing packets need not send 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 • Could cause burden on receivers if only one receiver doesn’t get the packet

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

  9. Hierarchical Multicast • More scalable than other multicast protocols • Specially useful when multicast over wide geographic boundaries, keep one DR in each country for example • DR nodes may need more power than other receivers • Need mechanisms to find out DR • Need mechanisms to delegate DR function to another node as primary DR node leaves multicast • RMTP: Reliable Multicast Transport Protocol - Bell Labs

  10. Congestion control • Layered multicast • Arrange layers in an exponentially increasing data rates • TCP-friendly Multicast • In steady state, packet drop => congestion, drop a layer • If layers are doubling in data rates, dropped layer = reducing multicast rate by half => TCP friendly

  11. QoS-Sensitive Multicast • The key issue is to construct a multicast tree with QoS constraints • Goal is to build a tree of paths to destinations such that sum of link costs (e.g. consumed bandwidth) is minimum and QoS constraints (e.g. delay) are satisfied • Exact solutions to such multi-constrained optimization problems are prohibitively expensive • Need heuristics that provide fast solutions of high quality

  12. An Example for Constructing A Tree • Application QoS requirements: end-to-end delay 13, jitter 7 • example 1 10 10 10 • example 2 2 6 6 10 10

  13. Mbone • Multicast Backbone • Consists of all the multicast-enabled routers • If two multicast routers are not directly connected, uses tunneling over non-multicast routers • Allows gradual deployment

  14. Video Conferencing • Vic is a video conferencing application developed by UC Berkeley • It is a real-time, multimedia application for video conferencing over the internet. • It is based on Real-time Transport Protocol (RTP). • To run vis, the system must support multicast, ideally, support Mbone. • An “Intra-H.261” video encoder is combined. • Further reading: Steven McCanne and Van Jacobson, “A Flexible Framework for Packet Video”, ACM Multimedia 95

  15. Conclusion • Reliable multicast • Congestion control • QoS Multicast • Mbone • Videoconferencing

More Related