Re: MBone

Franck Martin wrote:

> You can see multicast is not popular by the amount of conferencing
> applications developed which are not multicast but unicast only.
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.
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.
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.
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.
--
/=============================================================\
|John Stracke      |jstracke(_at_)centivinc(_dot_)com                    |
|Principal Engineer|http://www.centivinc.com                  |
|Centiv            |My opinions are my own.                   |
|=============================================================|
|Q: What goes "Pieces of 7! Pieces of 7!"? A: A parroty error.|
\=============================================================/