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