Subject: Re: Raising the bar on the MBone

From: Ross Finlayson <[email-masked]>
Date: Fri, 01 Aug 1997 00:35:05

At 01:21 PM 7/31/97 -0700, Stephen Casner wrote:
...
>At the same time, we do want to
>push on the MBone a bit and raise the bar in multiple dimensions:
>
>  - Demonstrate higher quality by transmitting part of the time at
>    higher data rates than the 128Kb/s that has typically been used
>    for video on the MBone.
>
>  - Reduce loss rates by engineering sufficient multicast capacity in
>    at least a "core" portion of the network.
>
>  - Expand the number of networks and the reach of multicast using
>    satellite networks to provide low-loss feeds, and also bringing in
>    cable networks and xDSL trials.
>
>  - Reach larger audiences.

Steve (et al),

To help satisfy that last bullet, I'd like to strongly encourage that you
also try to include some content that's appropriate for *low bandwidth*
Internet connections.  By "low bandwidth", I don't mean ISDN - I mean 28.8
kbps!  Like it or not, this is where most of the Internet lives, and the
bulk of the most innovative content on the Internet in recent years has
been for this level of bandwidth.  Progressive Networks and others have
demonstrated that audio (& even video, if you squint hard enough :-) can
work at this level.  Plus there are other multicast-based applications -
besides A/V - that can work well at these bandwidths.

One of the necessary steps for IP multicast to become ubiquitously deployed
is for more dialup routers to implement multicast routing, and the best way
for this to happen is to create more demand for it.

	Ross.

---

From: Stephen Casner <[email-masked]>
Date: Fri, 1 Aug 1997 09:35:27 -0700 (PDT)

Thanks to all for the comments on my announcement message.  There are
a few points I'll quickly respond to:

Andrew Patrick said:
> First, I know of at least two organizations that have tried to build a
> high-quality multicast network that is, at the same time, connected to
> the global MBone.  These are the MERCI consortium in Europe and Canada,
> and the Canadian CANARIE NTN network. Neither of these attempts have
> been very successul, and there may be some interesting lessons in what
> they have tried.

I would very much like to hear those lessons.  I welcome advice from
those involved.

> The other point concerns you plans to generate the content from a
> central "head end".  You may want to re-think this as there may be a lot
> more compelling content available if it can be inserted from various
> locations.

We may reconsider this idea, but it seems that for the content that
IPMI will be directly coordinating, it would be much easier to manage
from one location (assuming we can get it there).  If we are trying to
control the scope of transmissions using the limited route filtering
tools available, having one source point greatly simplifies the
problem.  I would expect the number of content sources and locations
to grow over time.

Louis Mamakos said:
> Demand for what?  I suspect there's unlimited demand for free Internet
> connectivity, yet that's not compelling enough to build a network to
> offer free service.  There must be demand for a credible multicast-IP
> based service offering.

I agree IP multicast service will only become widely available if
the appropriate revenue can be generated from it.  It is IPMI's goal
to help build a credible business around IP multicast service, for
ISPs, for content providers, for application vendors, and for users.

However, it is also my hope that ISPs don't try to apply more
stringent rules and business requirements to multicast than they do to
unicast.  The bandwidth of streaming media may be the primary concern,
then that concern should apply no more to a multicast stream than to a
unicast stream -- and maybe less because the unicast streams must be
replicated.

Ross Finlayson said:
> To help satisfy that last bullet [reach larger audiences], I'd like
> to strongly encourage that you also try to include some content
> that's appropriate for *low bandwidth* Internet connections.  By
> "low bandwidth", I don't mean ISDN - I mean 28.8 kbps!

It is part of our plan to transmit at different bandwidths at
different times, or perhaps with a low bandwidth simulcast.  However,
there's another level of infrastructure required to get to the dialup
user, so we expect that initially it will be easier to target
enterprises with higher bandwidth access.  But to the extent that
dialup multicast access is available, we don't intend to ignore it.

> Plus there are other multicast-based
> applications - besides A/V - that can work well at these bandwidths.

Yes, non A/V applications are part of the plan, too.
							-- Steve