Multicast Internet Route table.

Tue Sep 2 17:10:51 UTC 2014

I'll try to be brief-ish..

Interdomain Multicast suffered from three fundamental problems:

1) Deering's original use cases are far different from what it's used for
today. His original intent was to create a broadcast domain overlay over an
L3 topology. With this came reqs which today are largely nothing more than
unnecessary complexity with limited security and stability. The primary bit
of baggage is network based source discovery - the idea that anyone can
send and everyone will get those packets. Today all we want are explicit
trees. SSM solves these issues, but requires IP stacks, apps, and networks
to all support SSM. BUT, the one bit that Deering got right which the
community ditched was overlay. He knew not all boxes would support it so
DVMRP included tunneling (which I think is the first RFC to use overlay
encapsulation, but I'm willing to be wrong here.) When PIM replaced DVMRP
we unfortunately retained network based source discovery (RPs, MSDP, etc..)
but ditched encapsulation. This caused number 2 below.

2) Everyone must enable it or nobody can really benefit from it. The push
for native multicast (PIM) at the end of the last century was well
intended, but failed. If we had made IGMP multi-hop or something similar to
provide jumping over unicast-only networks we may be in a different place
today. But today we do have AMT which is trying to solve this problem. Some
venders do support it and some networks have already rolled it out in
trials. This may have some hope in changing the game.

3) Multicast is UDP. Many of the "multicast" problems people have stated
here on the list can more accurately be classified as UDP problems. When
using UDP rather than TCP, congestion control and reliability need to be
addressed at the application layer. Some solutions have capitalized on this
requirement by engineering solutions for each independently rather than
being stuck trying to game TCP (see unicast ABR).

So, with SSM only, an overlay layer like AMT, and a resilient application
layer CC and reliability we may have the right tools to see a larger global
multicast footprint. Or we may have figured all this out a bit too late.

Greg

On Tue, Sep 2, 2014 at 9:48 AM, Dale W. Carder <dwcarder at wisc.edu> wrote:

> Thus spake Mikael Abrahamsson (swmike at swm.pp.se) on Tue, Sep 02, 2014 at
> 06:05:42PM +0200:
> > On Tue, 2 Sep 2014, Octavio Alvarez wrote:
> >
> > >I have never used interdomain multicast but I imagine the global
> m-routing
> > >table would quickly become large.
> >
> > I have set up interdomain routing connecting both to a few peers and a
> Tier1
> > transit provider. Not many non-research networks to be seen.
> >
> > Also, since we didn't use it it kept breaking and I had to fix it every
> two
> > years or so, where it probably had been down for months.
> >
> > I don't believe in Internet-wide multicast happening in current
> incarnation,
> > it's just too fragile and too few people are using it. It wouldn't scale
> > either due to all the state that needs to be kept.
>
> Inter-domain multicast was largely replaced in practice by CDN's.
>
> In addition to scale issues in keeping state, large wireless L1
> environments
> are hostile to functioning multicast.
>
> Dale
>