Multicast

0. Goal

Q: What's the goal of multicast?

Efficient delivery to multiple members compared to N unicasts
-publish/subscribe model -sender doesn't need to know receivers -use
for, e.g., video broadcast of the superbowl, smaller scale video
conference,

Other use (doens't need data efficiency) is as a coordination mechanism
(a level of indirection).

Q: How would you achieve it on a wireless network?

IP Multicast service model is based on LANs (anyone can join a group,
anyone can send to it whether a member or not, membership is dynamic and
not known to members, best effort like unicast) ... it all seemed so
simple in LANs!

1. Basic extensions to LS/DV

Q: How would you achieve it on a campus network?

-MOSPF: distribute member location information and crunch on shortest
path trees
-DVMRP: use reverse path forwarding w/ prune messages for a truncated
broadcast to members

Q: Why aren't these good solutions for the wide-area Internet?

Problem: These approaches don't scale. Let G be the number of groups, M
the number of members in a group, and N the number of nodes in the
network. As N grows large, we expect groups to become sparse, i.e., M/N
grows small. As G grows large we get O(G) messages and maintain O(G)
state at every one of these N nodes, even though most nodes have nothing
to do with a particular group as M/N is small.

2. PIM paper - Multicast Routing

IGMP: traditionally, routers route and hosts don't. IGMP (group
management protocol) is the way that hosts tell their nearby router
which groups they are members of. It's a soft-state protocol with hosts
sending join and leave messages to routers using randomized timers to
suppress redundant messages when multiple local hosts are members of the
same group.

Goal of PIM is to build the multicast routing trees. Data packets are
then forwarded along them, replicated at a router as indicated.

Concept of a source-based tree vs a shared tree. Why source-based?
Better performance. Why shared? More scalable as less router state.

PIM is a well worked through design that is more scalable than earlier
protocols for dense groups.

3.RLM paper - Multicast Transports

Q: Suppose we had PIM and it worked. What then, would conferencing work?
What problems would we face?

Enter real-world issues as soon as you start using multicast for real
applications: bandwidth heterogeneity.

This paper provides bandwidth adjustment by having receivers subscribe
to different groups and using layered source codes so that the
information is useful. Receivers conduct shared join experiments.

Needs no router support; this is argued as a better approach in terms of
incentives.

Later this is generalized into TCP-friendly transports that compete with
TCP in a reasonable manner.

4. Why Has Multicast Failed?

Applications
-are CDNs and P2P sufficient for most media uses, even digital fountains
(a dissemination tree over time)?
-need much more than best effort multicast for typical apps, e.g.,
bandwidth sharing, reliability w/ heterogeneity.
-groups aren't lightweight enough for casual use as rendezvous
mechanisms, e.g., web page invalidation

Economics and ISPs
-why would an ISP want to deploy multicast?

Complexity
-is there a simpler solution?
-more restrictive models, e.g., single source multicast -less router
involvement, e.g., end system multicast

Deployment Paths
-can't change all the routers at once
-MBONE was an early, large overlay, but much overhead and now there are
better overlay maintenance tools