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

example 2

10

10

10

2

10

6 6

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