Subject: RE: MBone

From: Franck Martin <[email-masked]>
Date: Tue, 10 Sep 2002 15:43:55 +1200

I have progressed on this front... I found out that multicast is part of the
kernel in 2.4 and that the kernel can take care of routing too.

However on the MBone in general, it seems that it is not well deployed or
let's say "popular". I don't think it is configured by default by ISPs. I
will talk about it to our ISP here in Fiji and see what comes out...

You can see multicast is not popular by the amount of conferencing
applications developed which are not multicast but unicast only.

Now it seems that the multicast backbone use PIM while mrouted uses DVMRP.
The backbone uses PIM because that's what cisco has implemented (in short).
As for the Linux kernel I have no clue which routing protocol is
implemented. My guess it is all static routes, which is fine for a end user,
except when you want to do a tunnel...

Also www.mbone.org links to a search engine and mcast.net does not have a
web site. It would be nice to do www.mcast.net and have there a forum for
talking about multicast applications. I think ISI.EDU is the owner of this
domain which is in use for reverse multi-cast IP.

Just a few thoughts...

Cheers.

Franck Martin
Network and Database Development Officer
SOPAC South Pacific Applied Geoscience Commission
Fiji
E-mail: [email-masked] <mailto:[email-masked]> 
Web site: http://www.sopac.org/
<http://www.sopac.org/> Support FMaps: http://fmaps.sourceforge.net/
<http://fmaps.sourceforge.net/> 
Certificate: https://www.sopac.org/ssl/ 

This e-mail is intended for its addresses only. Do not forward this e-mail
without approval. The views expressed in this e-mail may not be necessarily
the views of SOPAC.

-----Original Message-----
From: Joe Abley [mailto:[email-masked]]
Sent: Tuesday, 10 September 2002 7:23 
To: Franck Martin
Cc: [email-masked]
Subject: Re: MBone

> Most documents on the Internet are very old.

The mboned page at

  http://www.ietf.org/html.charters/mboned-charter.html

seems reasonably recent.

---

From: Simon Leinen <[email-masked]>
Date: 10 Sep 2002 13:49:20 +0200

> The backbone uses PIM because that's what cisco has implemented (in short).

That's at least a gross oversimplification.  There are fundamental
scaling problems with DVMRP, such as its use of "flood and prune" and
a RIP-like single-domain routing protocol.
-- 
Simon.

---

From: John Stracke <[email-masked]>
Date: Tue, 10 Sep 2002 09:16:15 -0400

>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      [email-masked]                    |
|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.|
\=============================================================/

---

From: Michael Richardson <[email-masked]>
Date: Wed, 11 Sep 2002 11:10:49 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Simon" == Simon Leinen <[email-masked]> writes:
    >> The backbone uses PIM because that's what cisco has implemented (in short).

    Simon> That's at least a gross oversimplification.  There are fundamental
    Simon> scaling problems with DVMRP, such as its use of "flood and prune" and
    Simon> a RIP-like single-domain routing protocol.

  Yes, and a result of having pre-maturely adandoned it, and it near
impossible for people to even bridge from one to another, we may never
actually have to worry about this scaling problem.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [