Subject: Re: Multicast

From: [email-masked] (Sean Doran)
Date: Wed, 7 Mar 2001 18:28:34 +0100 (CET)

Brad Hunting writes:

| It even uses fewer resources for network providers.
|
| "The real difficulty of multicast" is that it's much more difficult
| for ISP's (and presumably router venders) to support than unicast.

These two statements are, unfortunately, mutually exclusive.

IP multicast does not scale well for S,G state; it may scale OK
for *,G for reasonable numbers of groups; it is not known whether
it will scale at all for little things like customer support.

Several backbones (including Ebone) offer native multicast "for free";
all a customer has to do is configure things up: 

	for source-active/rendezvous:  use our (anycast) RP, talk MSDP to us
	for RPF: use mBGP
	for joins/prunes: use PIM in sparse mode

It's not so difficult to set up, but not many people actually do it.

A sister network which has a pretty similar overall architecture to ours
offers multicast "for free" with a transmissions cap of a few hundred kbps
or so from a customer to the rest of the world through that network.
I don't think that this threshold has ever been in the way of anyone so far...

Why?  Poor client support springs to mind.  I've always wanted to
have someone throw together a web page that downloads a Java applet
equivalent to vic/vat/rat/etc., joins the right group, and puts content
into the face of the clicker, perhaps for a fee.  However, in the absence
of compelling content (sadly we don't have Vint to strip for us :) ), I 
haven't suggested that this be a priority.

Also, not all routers at/near the edge can even do native multicast...

	Sean.

P.S.: A long time ago there was a very interesting discussion (probably
      on NANOG) involving Vadim Antonov and many others; the argument
advanced by Vadim's side (include me here) is, roughly, that if you consider 
multicast to be a degenerate form of caching, where the cache is purged
immediately after servicing the implicit cache requests made by the 
listeners who have joined below the current router, then native multicast,
particularly reliable native multicast, is being approached in fundamentally
the wrong fashion.  In other words, rolling (maybe short term) content
caching into (some) routers is likely to be a more useful generalized
service than deploying actual native multicast, all while being able
to reuse some join/prune, SA and RPF state handling to optimize the
"network-based Content Distribution Network" (to use a set of buzzwords).

---

From: Greg Shepherd <[email-masked]>
Date: Wed, 7 Mar 2001 13:31:21 -0800 (PST)

> haven't suggested that this be a priority.

I often thought of the same, but the current Java Applet security model
prevents applets from joining mcast groups; or at least did last I looked. 

Greg

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 07 Mar 2001 18:05:48 -0500

Greg;

The multicast test button we wrote :

http://www.multicasttech.com/mt/
http://www.on-the-i.com/mt/test_ns.html

is a Java applet, and it joins a group.

The secret was in getting the right certificates and authorizations. This
seems to still be the problem with the Mac.

Marshall

-- 

   Multicast Technologies, Inc.
   10301 Democracy Lane, Suite 410
   Fairfax, Virginia 22030
   Phone : 703-293-9624          Fax     : 703-293-9609     
   e-mail : [email-masked]     http://www.on-the-i.com

---

From: Greg Shepherd <[email-masked]>
Date: Wed, 7 Mar 2001 15:16:12 -0800 (PST)

Okay, so signed applets work? Good.

Thanks,
Greg