Subject: Re: the mbone experiment

From: [email-masked]
Date: Mon, 4 Aug 1997 16:58:18 -0700 (PDT)

"Mike O'Dell" <[email-masked]> writes: 

> the current multicast technology and it's most visible experiemental
> implementation (MBone) have several problems when it comes
  ^^^^^^^^^^^^^^^^^^^^^

But, the core of "the Mbone" is using a routing technology, 
DVMRP, which everyone knows will not scale.  However, DVMRP 
does not comprise all of "current multicast technology".

> to implementing a general multi-point multicast service:
> 
>         (1) the current known multicast routing protocols have deeply
>                 pathological scaling behavior for anything approaching
>                 an interesting scale

Your telegraphic style is too cryptic for me.  I need 
things spelled out more.  Is this referring to DVMRP?  
If so, I can only point out that much more is known 
today than just DVMRP.  I agree that the multicast 
equivalent of BGP doesn't exist yet.

> 
>         (2) there is no viable business model 

I find this incomprehensible.  If there is demand for
a service, users will ask their providers to give them 
the service, and, if their provider can't give it to 
them and another can, they will switch. 

Are you saying that there is no demand for such service?

> so, it doesn't work, and you can't get paid.

Multicasting does work.  It just doesn't (yet) scale 
to 10^8 systems on 10^6 subnets, or whatever the numbers 
are today.  The IPMI proposal doesn't seek to connect 
up everybody with a PC to "the Mbone" today.  Apparently
you don't think anything less than 10^6 households is
an "interesting scale".  But, for some purposes, 1000
corporate and educational sites with T1's-T3's could 
also be "interesting".  

"The Mbone" is an experiment, and, as an experiment,
it works.  The next step is to go on to expand the base
of "early adopters".  In the meantime, roadblocks that 
prevent multicast from being ubiquitously deployed will
have to be eliminated.  Automobiles and telephones were 
frivolously expensive for ordinary people, when they were 
first deployed, too, and it wasn't really until the 
mid-1980's, 100 years after the development of the
internal-combustion-engine-automobile, that cars became
reasonably pollution-free, non-balky, mostly trouble-free,
relatively safe "appliances".  Computers are now 50 years
into their development, and IP-based networks about 16 years.
The pace of development has accelerated considerably since 
1885, but, you still don't normally expect any new technology 
to go from "experimental" stage to the fully-developed state
overnight.  In this case, we have a successful experiment,
"The Mbone", and some technology suitable for "early adoption".  
Ubiquitous deployment will come later.

> Now what was it that is so attractive about it??

More efficient use of WANs.  The ability to provide
real-time information to large numbers of users 
simultaneously.

>         -mo
> 
> PS - this does not mean the technology cannot be salvaged for
> some useful purpose, but it's not exactly what people seem
> to have in mind.

I'm not sure what you think I have in mind.  However, I'm not
afraid to be explicit about it.  I think that eventually the 
unicast routing world and the multicast routing world can be 
made to coincide mostly, and that to do so will enable more 
efficient use of WANs.

I'm not under the delusion that all the problems have already
been solved.  There are lots of interesting problems to be
solved, although, obviously, I think the technology is more 
mature than you do.

In a subsequent post, "Mike O'Dell" <[email-masked]> writes:

> Ah yes,  you have come to the nub....
> 
> We don't talk about unannounced products
>
>         cheers,
>         -mo

If the word is "products", perhaps you think that some
part of the experiment was a success after all?

-Hugh LaMaster

  Hugh LaMaster, M/S 258-5,     ASCII Email:  [email-masked]
  NASA Ames Research Center     Or:           [email-masked]
  Moffett Field, CA 94035-1000  No Junkmail:  USC 18 section 2701
  Phone:  415/604-1056          Disclaimer:   Unofficial, personal *opinion*.

---

From: [email-masked]
Date: Mon, 4 Aug 1997 16:58:18 -0700 (PDT)

^^^^^^^^^^^^^^^^^^^^^

-Hugh LaMaster

---

From: [email-masked]
Date: Mon, 4 Aug 1997 16:58:18 -0700 (PDT)

^^^^^^^^^^^^^^^^^^^^^

-Hugh LaMaster

---

From: [email-masked]
Date: Mon, 4 Aug 1997 16:58:18 -0700 (PDT)

^^^^^^^^^^^^^^^^^^^^^

-Hugh LaMaster

---

From: [email-masked]
Date: Mon, 4 Aug 1997 16:58:18 -0700 (PDT)

^^^^^^^^^^^^^^^^^^^^^

-Hugh LaMaster

---

From: [email-masked]
Date: Mon, 4 Aug 1997 16:58:18 -0700 (PDT)

^^^^^^^^^^^^^^^^^^^^^

-Hugh LaMaster

---

From: [email-masked]
Date: Mon, 4 Aug 1997 16:58:18 -0700 (PDT)

^^^^^^^^^^^^^^^^^^^^^

-Hugh LaMaster

---

From: [email-masked]
Date: Mon, 4 Aug 1997 16:58:18 -0700 (PDT)

^^^^^^^^^^^^^^^^^^^^^

-Hugh LaMaster

---

From: [email-masked]
Date: Mon, 4 Aug 1997 16:58:18 -0700 (PDT)

^^^^^^^^^^^^^^^^^^^^^

-Hugh LaMaster

---

From: [email-masked]
Date: Mon, 4 Aug 1997 16:58:18 -0700 (PDT)

^^^^^^^^^^^^^^^^^^^^^

-Hugh LaMaster

---

From: [email-masked]
Date: Mon, 4 Aug 1997 16:58:18 -0700 (PDT)

^^^^^^^^^^^^^^^^^^^^^

-Hugh LaMaster

---

From: [email-masked]
Date: Mon, 4 Aug 1997 16:58:18 -0700 (PDT)

^^^^^^^^^^^^^^^^^^^^^

-Hugh LaMaster

---

From: [email-masked]
Date: Mon, 4 Aug 1997 16:58:18 -0700 (PDT)

^^^^^^^^^^^^^^^^^^^^^

-Hugh LaMaster

---

From: [email-masked]
Date: Mon, 4 Aug 1997 16:58:18 -0700 (PDT)

^^^^^^^^^^^^^^^^^^^^^

-Hugh LaMaster

---

From: [email-masked]
Date: Mon, 4 Aug 1997 16:58:18 -0700 (PDT)

^^^^^^^^^^^^^^^^^^^^^

-Hugh LaMaster

---

From: [email-masked]
Date: Mon, 4 Aug 1997 16:58:18 -0700 (PDT)

^^^^^^^^^^^^^^^^^^^^^

-Hugh LaMaster

---

From: [email-masked]
Date: Mon, 4 Aug 1997 16:58:18 -0700 (PDT)

^^^^^^^^^^^^^^^^^^^^^

-Hugh LaMaster

---

From: [email-masked]
Date: Mon, 4 Aug 1997 16:58:18 -0700 (PDT)

^^^^^^^^^^^^^^^^^^^^^

-Hugh LaMaster

---

From: "Yves Lepage" <[email-masked]>
Date: Fri, 15 Aug 1997 21:04:06 -0400

Hi Kevin,

Basicly my opinion as well.

Check out Precept's new MBone receiver. It has tunnelling capabilities. It
may be possible to do something with that.

There are a number of neat little pieces fo software that will let peecee's
tunnel to an MBone router.

From there, all that's left to build is an auto tunnel config scheme on the
mrouter.

Yves Lepage
[email-masked]

-----Original Message-----
From: Kevin C. Almeroth <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Friday, August 15, 1997 8:00 PM
Subject: Re: the mbone experiment

>The current usage model says that if you have MBone
>connectivity you get MBone content.  If you don't have
>multicast capability you don't get it.  There is no
>motivation for an ISP to add multicast capability
>because it does not reduce traffic.  In fact, adding
>multicast capability will actually increase traffic.
>
>What we really need is a way for users who don't have
>multicast capability to still get MBone content.  The
>model I'm thinking of is similar CU-SeeMe.  Multicast
>from sender to as close to the receiver as possible,
>and then send it via unicast.
>
>Imagine an ISP that does not have multicast capability
>but has increasing numbers of users requesting MBone
>content via individual unicast streams...  from a couple
>to more then 10, to maybe a hundred.  Now that is
>MOTIVATION for an ISP to provide multicast capability
>and reduce intra-ISP traffic.
>
>-Kevin Almeroth
>
>

---

From: [email-masked]
Date: Wed, 27 Aug 1997 19:21:59 +0200

>    The problem with your suggestion that you're trying to unseat an
>    existing technology which performs the taks you describe, yet performs
>    them 'better'.  What advantage does a 'digital' porn channel have over
>    cable?
> 
> Make it cheaper.  ;-)  Free would work.  Note the amount of free porn
> floating on the net now...
> 
> Tony
> 
> 
I haven't read all of this thread, but I take it [email-masked] is
an all-male-no-female list, is it?

just curious,
edgar

---

From: "Chris A. Icide" <[email-masked]>
Date: Wed, 27 Aug 1997 12:57:44 -0500

Just to toss a couple cents into the kitty....

using flow exporting, I've seen quite a bit of traffic on ports 26000, 27500 and
some very close varients.  This appears to be "Quake" traffic.  My instincts
tell me that multiplayer gaming should fit the bill also.

But just because a killer ap exists doesn't mean mcast will be used to support
it.  As long as we continue to build larger faster pipes, and the programmers
out there can continue to program in the unicast frame of mind, all this will be
unicast.  

IMHO, most application developers are not viewing bandwidth as a resource,
and until they do, the applications will use a proven technology, unicast.

Chris

----------
From: 	Tony Li[SMTP:[email-masked]]
Sent: 	Wednesday, August 27, 1997 10:35 AM
To: 	Jeff Young
Cc: 	[email-masked]
Subject: 	Re: the mbone experiment

[email-masked] (Jeff Young) writes:

> what the mbone needs is a killer app.  

I would agree.  Further, using the postulate that sex is what drives the
development of the net, the obvious killer app is mcast sex.  This might
take one of many forms:

1) The 24-hour porn channel.  Requires someone with a VCR and a large
library of tapes.  Rife with interesting copyright/broadcast issues...

2) The porn feed.  The number and volume of the of alt.binaries groups
seems to continue to grow.  Seems like an app which took binaries and
trickled them out would be popular.  Folks would need a Win95 app that
absorbed the binaries with some filtering based on alleged content and disk
space limitations.

3) Live mcast porn.  At least there are no copyright issues...  The
business case here is chargeback, so you'd wanna encrypt the stream and
then pay-per-view for the decryption key.

Other ideas?

Tony

---

From: Jim Lowe <[email-masked]>
Date: Wed, 27 Aug 1997 12:59:40 -0500 (CDT)

> > what the mbone needs is a killer app.  
Isn't the killer app[aratus] already known as Kevorkian's van (sorry :-)?

---

From: [email-masked]
Date: Thu, 28 Aug 1997 08:54:30 -0400

>     > what the mbone needs is a killer app.
	Another killer multicast application (from an ISP's perspective)
is 
	netnews feed.  This application will drastically reduce the
bandwidth 
	needs of the routed backbone to carry multiple streams of the
same 
	newsfeed to network nodes.

	Seyhan Civanlar