CSE679: Multicast and Multimedia

1. CSE679: Multicast and Multimedia • Basics • Addressing • Routing • Hierarchical multicast • QoS multicast

2. Multicast -motivation • Point-to-point delivery not efficient for events/transmissions of general interest • Examples • News multicast • IETF sessions/rock concerts • Many receivers may share the same path • Point-to-point delivery too expensive

3. Multicast motivation

4. Multicast issues • In point-to-point delivery, receiver address is known => routing is straightforward • In Multicast, many receivers • How to transmit data to all the receivers? • How to identify the group of receivers? • At the sender? • In the network?

5. Multicast issues • Identify multicast by a group/multicast address • The membership changes as the receivers join/leave the group • Routers/Network need to recognize the multicast address • Receivers need to receive on their own IP address and on the multicast address

6. Multicast addressing • A multicast sender uses the group address as the receiver’s address when sending packets • Network/routers keep track of actual receiving subnets/paths for this group address (not the actual receivers) • Receivers can reply to sender’s address or to group address

7. Multicast addressing • Part of IP address space reserved for multicast • Multicast routers recognize multicast addresses • Need to get a multicast address for a transmission before multicast can start • Protocols exist for obtaining multicast addresses and finding out a multicast address

8. Class D addresses • High order 4 bits = 1110, followed by a 28-bit multicast group ID. 224.0.0.0 - 239.255.255.255 • 224.0.0.1 - all systems on this subnet • 224.0.0.2 - all routers on this subnet • 224.0.0.4 - all DVMRP routers • 224.0.0.5 - all OSPF routers

9. IGMP • Internet Group Membership Protocol • Used to join a multicast group and to check on the current status of receivers on a subnet • IGMP -join message propagated up the routers until the multicast tree reached. • Routers periodically poll hosts on subnets to see if any active receivers remain • If no active receivers remain, routers propagate leave messages upstream to reduce unnecessary traffic • Frequent polling can increase overhead • Separate protocols for finding group membership address - sd

10. Multicast routing • For point-to-point delivery, a router looks up routing table and knows how to forward • For multicast, many receivers • may have to forward packets on multiple outgoing links • too hard to keep track of individual receivers at each router for each multicast group • remember just the links on which to be forwarded - change as receivers join/leave

11. Multicast routing • Need to recognize multicast addresses • The routing tables change as the receivers join/leave a multicast group • Every router keeps track of “downstream” links on which to forward a packet • Routing table and multicast address “expire” at the end of session

12. Multicast Routing Protocols • DVMRP - Distance Vector Multicast • MOSPF - Multicast Extensions to OSPF • PIM - Protocol Independent Multicast

13. Multicast routing approaches • Flooding • send on all links to reach the receivers • not efficient • Spanning tree • efficient • could concentrate traffic on a few links

14. Spanning tree based routing • Spanning trees rooted at the sender • When a receiver wants to join a group, may have to broadcast on all upstream links to find a path to the sender • could cause a lot of overhead in sparse groups • need better solutions

15. Sparse Mode routing • Use a Core-based tree (CBT) • Use a rendezvous point or a core router • Direct all joins to RP which knows how to reach the sender • can avoid broadcasting multicast group information to all routers in the network • can result in non-optimal paths • would need to modify multicast tree over time

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

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

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

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

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

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

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

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

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

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

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

27. Conclusion • Multicast basics • Motivation and Issues • Addressing • Routing • Hierarchical multicast • QoS multicast