Skip to Content.
Sympa Menu

wg-multicast - RE: Why don't we use multicast more often?

Subject: All things related to multicast

List archive

RE: Why don't we use multicast more often?


Chronological Thread 
  • From: "Richard Mavrogeanes" <>
  • To: "John Zwiebel" <>, <>
  • Cc: <>
  • Subject: RE: Why don't we use multicast more often?
  • Date: Thu, 13 May 2004 16:24:36 -0400

My two cents:

Multicast is not used more often because:

1. The default condition of virtually all routers is to disable multicast.

2. The default condition of virtually all switches is for igmp-snooping to be
off, if it is supported at all.

3. The default condition of virtually all firewalls is to block multicast
(and in fact, UDP).

4. Local IT staff is reluctant to turn on anything they don't understand (if
it ain't broke don't fix it).

5. ISP's don't understand the real economic incentive for supporting it,
wondering why they should use *their* network to distribute content to
*their* subscribers for the benefit of a sender on a *different* network. At
least unicast makes the sender suffer, they reason (that ISP gets to make
more money by charging for more unicast bandwidth).


rich


-----Original Message-----
From: John Zwiebel
[mailto:]
Sent: Thursday, May 13, 2004 4:11 PM
To:

Cc:

Subject: Re: Why don't we use multicast more often?



On May 13, 2004, at 11:19 AM, William F. Maton wrote:

> Conference calls will probably be the magic application that will push
> multicast out from it's sheltered existence, but even then, I don't see
> that many people wanting to do that


Apple already has iChat which supports both audio and video
over unicast. And your going to see many more unicast applications
that do this. And this seems to work just fine. IMHO conference
calls that have fewer than 10 participants can be done via
unicast just fine. And if there are more than 10, then you need
some kind of moderator, which means unicast to the moderator and
then perhaps multicast back out, but probably not. There's no
need for it.

There is also a very old powerpoint that was multiuser capable. It
was available as a beta on Macs. Hmmm... wonder why it died? :-)

I agree with Tom that multicast isn't going to take off until
there are high-BW applications.

Moving on, those high-BW applications are -NOT- going to use
ASM.

So, the barriers to multicast are:
-- last-mile
Where is AMT or how do we break the monopoly that the
home providers have.
-- no source discovery protocol that doesn't depend on multicast
(ie, sdr doesn't scale to an interdomain environment and
continued attempts to make it do so will not work. Storing
this information "in the network" by pushing it out via multicast
is OK in a dense environment, but the Internet is not a dense
environment.) This has to be an application level protocol
like DNS (ie, putting the SDP file on a web page, although not
elegant, does work. Perhaps a discussion of why this isn't
"good enough" is in order?)
-- MLDv2 and IGMPv3. Its in KAME so "soon" will be in FreeBSD and
therefore OSX (I hope). Perhaps a little lobbying of the FreeBSD
folks to incorporate the KAME IGMPv3 and MLDv2 would be in order?
(I don't know the process)

This forum has been wondering about the sasser attacks on MSDP. SSM
would eliminate this kind of an attack. SSM does open up for a
"reverse"
attack where a "evil-doer" could join every IP address in the world
causing
creation of lots of state.

I'm often accused of being unrealistic because I keep saying "kill asm"
and
"Kill MSDP". Perhaps I should change my mantra to "allow it to wither".
I keep seeing efforts (I think) wasted on making ASM better because we
have
to support all those legacy hosts that don't support IGMPv3 so can't do
SSM. Yet, I sure don't see the explosion of multicast that was suppose
to
happen because we maintained that backward capability.




Archive powered by MHonArc 2.6.16.

Top of Page