Subject: Re: MBone

From: "Kevin C. Almeroth" <[email-masked]>
Date: Wed, 11 Sep 2002 06:21:20 -0700 (PDT)

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

---

From: John Stracke <[email-masked]>
Date: Wed, 11 Sep 2002 09:23:04 -0400

>>>conferencing, but there are problems that would inhibit its use even if 
Like the entire rest of my message.

>First, what are IETF-style apps?  Are you talking vic/vat?
>
Yes.

>The content
Most of those are not multicast--and they certainly aren't conferencing.

>Also, there are plenty of (surviving) companies offering non-conferencing
I was talking about conferencing.

>>>but consider: once you start running a 
>>>can intercept it.
No, those can be intercepted only by tricking the routers.  Multicast 
specifically permits anyone to pick up the traffic just by asking for it.

-- 
/===========================================\
|John Stracke      [email-masked]  |
|Principal Engineer|http://www.centivinc.com|
|Centiv            |My opinions are my own. |
|===========================================|
|Brought to you by the letter Q.            |
\===========================================/