CIS679: Multicast and Multimedia (more) r Review of Last Lecture r More about Multicast

Review of Last Lecture r Multicast basics m Motivation and Issues m Addressing m Routing

Reliable Multicast r In unicast, receiver ACKs give feedback ---Sender takes responsibility in transmitting data r In Multicast, many receivers -- too difficult for sender to keep track of every receiver’s status r ACK Implosion

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

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

Unicast NAKs to sender r Reduces overhead when packet losses are isolated and rare r Packet loss early in the tree will result in too many NAKs

Multicast NAKs r Others missing packets need not send NAKs r if every receiver, sends a NAK immediately after getting an out-of-sequence packet, too many NAKS at once! r Wait for a random time, send a NAK r If some one else sends a NAK, suppress your NAK r Getting random timers tricky business r Could cause burden on receivers if only one receiver doesn’t get the packet

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

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

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

QoS-Sensitive Multicast r The key issue is to construct a multicast tree with QoS constraints r 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 r Exact solutions to such multi-constrained optimization problems are prohibitively expensive r 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  example

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

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

Conclusion r Reliable multicast r Congestion control r QoS Multicast r Mbone r Videoconferencing