150 likes | 324 Views
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
E N D
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 • In Multicast, many receivers -- too difficult for sender to keep track of every receiver’s status • ACK Implosion
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.
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
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 • 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
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
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
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
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
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
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
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
Conclusion • Reliable multicast • Congestion control • QoS Multicast • Mbone • Videoconferencing