Re: MBone

First, for the record...  there is no MBone.  The MBone was an overlay
experiment in the early 90s.  It is now gone.  No more tunnels...  now just
native multicast deployment in a fair number of backbones and some regional
ISPs.

Unfortunately that makes tunnels harder.  Fortunately it makes the 
infrastructure less like spag.

One thing I personally thing is needed is reflector software to enable
any unicast-only user to receive multicast content.  The "pain" of
replication is felt only where it happens and is a greater motivator
to deploy native multicast.  But I digress...

It's not quite that simple; multicast ought to be a great technology for 
conferencing, but there are problems that would inhibit its use even if 
it were widely deployed.


Like?

First of all, the IETF-style pure-multicast conferencing apps are fine 
for IETF meetings, but not so hot for most business use.  In these apps, 
a conference corresponds more or less directly to a multicast group; 
anybody who joins the group joins the conference.  This means that all 
you have to do is assign and publish the multicast group in advance, 
which scales up well.  However, it means that you *always* have to 
assign and publish the multicast group in advance, which scales down 
poorly--for a 3-person conference, a UI where you say "call this person 
and that person" is much simpler.


First, what are IETF-style apps?  Are you talking vic/vat?  The content
sent from the IETF can be received with Real, Media Player, Quicktime,
IPTV, vic/vat, etc.

Also, there are plenty of (surviving) companies offering non-conferencing
but still multicast-based solutions.  See http://www.digitalfountain.com/

Now, multicast can be a useful adjunct to a small-scale conference.  I 
used to work on an app where we would save bandwidth by using multicast 
if it was available, and fall back to unicast if not.  But, in this 
case, you start having to worry about security.  We never really 
addressed the problem, in part because we never ran over the public 
Internet (this was 1995), but consider: once you start running a 
multicast session over the Internet, anybody who's within the TTL range 
can intercept it.  They might not be able to pick up the TCP signalling 
that's setting up the session; but they can just start scanning, joining 
groups until they get something.  This means you absolutely have to 
start encrypting your traffic, which gets into all the usual problems of 
key exchange, regulation, etc.


Same with UDP traffic.  Same with TCP traffic.

And then there's the problem of making sure that multicast groups don't 
collide and start picking up each other's traffic--even if it gets 
filtered out at the application level, it means wasted bandwidth.  If 
you're using a modem, and you've got a 3-way 28kbps session going, and 
you stumble on the same group address as someone within TTL range who's 
running a 10-way 1Mbps session, your line is going to be swamped. 
Worse, most users won't know what's going on, and they'll just decide 
the application is lousy.  IPv6 should make this easier to avoid, with 
at least 2^32 multicast groups.


See SSM.

-Kevin