Subject: Raising the bar on the MBone

From: Stephen Casner <[email-masked]>
Date: Thu, 31 Jul 1997 13:21:05 -0700 ()

[I'm addressing this message to "the MBone community".  Since that
entity is somewhat amorphous and not necessarily represented by one
mailing list, I've sent this message primarly to the mbone list but
Bcc'd it to rem-conf and mboned.  Please excuse the duplicates.**]

The size of the MBone continues to grow more or less exponentially,
but the level and type of usage has grown much more slowly.  I think
we'd all like to see the MBone grow into a ubiquitous IP multicast
service across the Internet and fade away as a separate entity.  To
push this process, it is necessary to periodically "raise the bar", as
Carl Malamud did when he formed the Internet Multicasting Service and
initiated 24-hour transmissions.  Taking such steps is always a cause
for some concern, but in the end that's how we make progress.

The IP Multicast Initiative (IPMI, www.ipmulticast.com) was formed
with the explicit goal of accelerating the deployment of IP Multicast
on Intranets and the Internet.  IPMI addresses the business aspects of
this problem (education, marketing) while the IETF MBONED Working
Group addresses the technical issues.

IPMI is now planning a project called the "Internet Multicast Channel"
(IMC) to transmit compelling content over the MBone for a fixed number
of hours per day, several days per week.  By bringing together ISPs
and content providers the IPMI hopes to overcome the "chicken and egg"
problems that have so far have hampered development of commercial
multicast capabilities in the Internet: content providers need
assurance that the network will work; ISPs won't implement multicast
as a service if there is no content and no demand.  Our goal is to
transmit content that is sufficiently compelling to motivate users to
request a multicast feed from their ISP and to deploy multicast within
their internal networks.

This project includes several people who have been involved with the
MBone for a long time.  We want to make sure that it fits in with
other MBone activities, for example by limiting the bandwidth or scope
of transmissions during IETF week.  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.

We anticipate transmitting the IPMI IMC from a centralized "head-end"
where the content and transmission servers can be brought together.
The head-end will connect to one or more terrestrial backbones and
satellite networks that are participating in the project and have
sufficient multicast capacity to carry the traffic reliably.
Some of these may already constitute portions of the MBone and some
will be new.

I head the subgroup that is planning the network architecture from the
perspective of the head end.  I'm sending this message to the MBone
community to get feedback on what level of connection to or isolation
from the MBone we should establish.  Points between the two extremes
can be implemented using filtering of multicast route advertisements
(which is implemented in recent versions of mrouted in addition to
some commercial routers).  I believe it is useful to have both a core
portion of the multicast-capable network engineered with sufficient
resources to allow demonstrating the higher quality that will
eventually be available more widely, plus connectivity to the whole
MBone so that content at lower bandwidth can reach a larger multicast
audience.  The idea would be to grow that core until it consists of
the entire Internet!
							-- Steve

** In this age of spam,	I recommend installing an incoming mail
filter which as a side benefit can eliminate duplicate messages.
See http://www.best.com/~ii/internet/faqs/launchers/mail/filtering-faq/

---

From: Andrew Patrick <[email-masked]>
Date: Thu, 31 Jul 1997 16:41:26 -0400

Stephen Casner wrote:
...
> of hours per day, several days per week.  
...

I think this goal of "raising the bar" is good.  A couple of quick
reactions to your note.  

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.

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.  I know there is some pent-up demand here in Canada to try to
experiment with high-quality content, but the logistics of getting it to
your head end may be difficult.

-- 
Andrew Patrick, Ph.D.             Communications Research Centre
[email-masked]         Ottawa, CANADA
http://debra.dgbt.doc.ca/~andrew  Phone: +1 613 990-4675 (Voice)

---

From: [email-masked] (Jeremy Hall)
Date: Thu, 31 Jul 1997 18:46:21 -0400 (EDT)

Some sort of regional groups might do the trick. like if you have a group
for people homed to a specific provider, or homed to a specific continent,
and generated the signal from there, this might work.

---

From: "Louis A. Mamakos" <[email-masked]>
Date: Thu, 31 Jul 1997 18:57:47 -0400

> as a service if there is no content and no demand. 

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.

ISP's won't implement a large-scale multicast-IP based service if there's 
no compelling business case to do so.  "Content" is compelling only
to end users.  It would be good if that available content drives a service
which can support the infrastructure deployed to implement it.

How much bandwidth do you think that ISP's are willing to devote to the
(essentially free) MBONE experiment?  1 Mb/s?  10 Mb/s?  100 Mb/s?  At some
point the free ride is going to run up against financial realities when somone
is faced with having to buy another DS3 to carry traffic which produces
no revenue.  Either the overall cost of getting Internet service is going
to increase to cover (subsidize) these multicast infrastructure costs, or
people that "use" multicast traffic will end up having to cover the costs.  
Are these traffic sources or receivers?  I have my ideas, but eventually 
someone's gonna have to belly up to the bar to pay the bill.

Louis A. Mamakos, Manager, Strategic Technologies   [email-masked],  uunet!louie
UUNET Technologies, Inc.                            Voice: +1 703 206 5823
3060 Williams Drive                                 Fax:   +1 703 208 5390
Fairfax, VA 22031

---

From: Mark Kayser <[email-masked]>
Date: Thu, 31 Jul 1997 20:35:18 -0400

> 3060 Williams Drive                                 Fax:   +1 703 208 5390

I think the idea is to show the rest of the world that multicasting
works and more people should be creating applications for it.  Multicast
in the end is better for ISPs as it conserves bandwidth.  These quality
applications, if created in the without multicast would flood our ISP
backbones with individual unicast streams for each end user.  ISP's
should be building quality multicast infrastructures for improved
backbone performance, not just profit.  Although selling multicast
services, not multicast service, could be a good market.

Just my $.02

--Mark Kayser
MCI Technical Support

---

From: Jon Crowcroft <[email-masked]>
Date: Fri, 01 Aug 1997 09:08:21 +0100

>been very successul, and there may be some interesting lessons in what

actually, the UK Mbone is part of the UKERNA services, and works VERY
well indeed - the issue with mbone for multimedia is that remote
conferencign and viewing of video and audio is at maximum value when
at maximum distance (i.e. saving travel cost, or adding to meeting
frequencey) abut is also maximally at the MERCY (pun intended) or
expensive, poorly engineered international links

if anything, failure to implement ,multicast is a good measure of the
conservative nature of large commercial ISPs - thereis a perfectly
good busniess case for multicasting ftp/web mirror info even without
the arguments about pricing models for coninuous (non-adaptive-ish)
vidfeo/audio soruces-  the downside is the sability of mbone products

the time is about right to do what steve proposes, imho.
 
 >your head end may be difficult.

we can avoid this by seperating out the services

multicast is useful

multimedia may be more difficult to justify right nowq for some ISPs
(though in the UK university net we have no problem with it)

people who get these confused too often

in fact, if you have a service contract that rules out constant rate
UDP traffic, then you are LESS worried about multicast constant rate
traffic (but possibly still worried) than multiple unicast (reflector
or other) based streams now we have good pruning etc....and sparse
mode trees whose RPs could be policed.....

actually, i don't see steve's request as a problem anyhow - if an ISP
doesn't want to play, then they don't have to join the mbone - we don't care - 
we'll get their customers eventually:-)

 jon

---

From: Jim Dixon <[email-masked]>
Date: Fri, 1 Aug 1997 09:44:12 +0100 (BST)

> we'll get their customers eventually:-)

Given the difficulty of getting anyone in the UK MBONE community to 
even answer simple questions like "how do we connect to the UK MBONE?"
this is a remarkable statement.

--
Jim Dixon                  VBCnet GB Ltd           http://www.vbc.net
tel +44 117 929 1316                             fax +44 117 927 2015

---

From: Graeme Wood <[email-masked]>
Date: Fri, 1 Aug 1997 10:28:41 +0100 (BST)

> this is a remarkable statement.

Jon was actually refering to the JANET Mbone and not the UK Mbone. The
JANET Mbone connection policy is pretty clear and is contained in a
document on the JANET web site: http://www.ja.net/documents/mbone.html.
Admittedly it is a little out of date as it refers to the MICE National
Support Centres which no longer exist and have yet to be replaced.

=============================================================================
Graeme Wood                                 Email: [email-masked]
Unix Systems Support                        Phone: +44 131 650 5003
The University of Edinburgh                 Fax:   +44 131 650 6552
=============================================================================

---

From: Dave Barr <[email-masked]>
Date: Fri, 01 Aug 1997 09:10:43 -0400

>someone's gonna have to belly up to the bar to pay the bill.

By your argument, Usenet would never have grown to the immense size it
is today.  It was in the same state as as Mbone is now.  (Significant
but decreasing startup costs and significant but decreasing costs to maintain
communication links)

Usenet survived because it has content (despite all the jokes people
make about it).  It survived because people use it, and given the choice
between an ISP that had Usenet and one that didn't, people chose
the ones that had Usenet (or big ISPs that offered their own Usenet-like
system).

Content.  Content.  Content.  That is what is going to drive Mbone growth.
The only things holding Mbone back are bad service and good software
availablity.  (that, and a little bit of marketing)

--Dave

---

From: Beau Williamson <[email-masked]>
Date: Fri, 01 Aug 1997 11:01:12 -0500

>availablity.  (that, and a little bit of marketing)

Steve, et al,

I agree with Dave whole heartedly here. Content is the key!  

The second is that this compelling content really needs to fit in the
28.8kbps bandwidth space to generate the demand that is necessary to drive
ISPs to develop the business models and infrastructures necessary to
support the demand.

Point in case, as I sit here writting this, I am still trying to get a
decent set of MBONE tools for the WIN95 environment.  SDR and VAT seem to
be pretty well ported to this environment but there is no port of the
Whiteboard (WB) tool to the WIN95 environment.  This means I can't
participate in many of the most common multicast forums which use VAT and
WB as a simple but tremendously effective conferencing method.  If we could
could concentrate on providing the ability to perform this sort of
conferencing (audio & WB only) via 28.8kbps attached workstations I think
we could really create some serious demand for multicasting.  

I won't even go into the frustration of not being able to get a working
copy of VIC that will transmit video from my PC.  I know that there are
some versions out there will do some limited video sourcing but due to bugs
in the TCL/TK library with which it was built, it is virtually unusable for
a large majority of PCs.  

Having said that, I want to be clear that we are all grateful to those
souls that have given freely of their time to work on porting these MBONE
tools to the various platforms.  To those hearty souls we say, "Thank you,
thank you, THANK YOU!!!  Your efforts are appreciated by all."  However, my
point is that this is an area that could be addressed by members of the
MBONE community to help accelerate the use of multicasting and the MBONE in
general(or whatever the new multicasting infrastructure is called).

Beau Williamson

_____________________________________________________________________

"When I first started, what I didn't know filled volumes.
 Now, after years of network experience, what I don't know
 fills libraries!"

 G. Beau Williamson N5PY         ***************************
 Consulting Engineer, CCIE 1346  *      .           .      *
 Cisco Systems Inc.              *      |           |      *
 14160 Dallas Parkway            *     |||         |||     *
 Suite 400                       *    |||||       |||||    *
 Dallas,TX  75240                *  |||||||||   |||||||||  *
 Phone:  972.774.3317            *|||||||||||||||||||||||||*
 Fax:    972.774.3333            *      Cisco Systems      *
                                ***************************
_____________________________________________________________________

---

From: Amancio Hasty <[email-masked]>
Date: Fri, 01 Aug 1997 10:21:17 -0700

> availablity.  (that, and a little bit of marketing)

Additionally, we need a few things:
1.  Perhaps we are using the wrong media to drive the ip multicast 
    initiative . ip multicasting web pages or ftp sites is a perhaps
    a better content to force the industry to go to the MBONE.

2.  a cheap win95/winnt client capable of receiving audio/video at 28.8.
    For major events, the broadcasters should be able to point people
    to a free client. Better codecs, wider support for mpeg and h.323.
    The latter is tied with all sorts of patent royalty payments and
    there not much we can do about that. 
    
3.  a massive marketing drive -- must ISPs don't know what IP Multicast
    is nor how it can benefit them.

4.  increase the reliability of the mbone when ISPs do know about the
    MBONE the first thing that it usually surfaces is that the MBONE
    is not reliable.

	Enjoy,
	Amancio

---

From: Christopher Samuel <[email-masked]>
Date: Fri, 01 Aug 1997 20:14:53 +0100

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

/* Cc'd to the ID webmaster in case there is any interest there */

In message <[email-masked]>, 

>     a better content to force the industry to go to the MBONE.

I wonder how many people would start asking for multicast if games
such as quake had some low bandwidth multicast support for the
multiplayer scenarios ?

I realise that this isn't a new idea as the SGI Dogfight game already
has a reserved multicast address, but having Quake as an option on the
SDR session create menu does appeal to me. :-)

Thus you could have sessions with quake data and voice so that
you can chat to other players whilst trying to kill them; those
of us who can't play quake could just eavesdrop to the mayhem.

cheers,
Chris
- -- 
 Christopher Samuel,   IT Vulnerabilities Group,   [email-masked]
 N-115, Defence Research Agency, St Andrews Road, Great Malvern, England, UK
 DISCLAIMER: I write only for myself, not for DRA.    Phone: +44 1684 894644
 +   DRA is a division of DERA, an agency of the UK Ministry of Defence    +

---

From: Joseph Porrovecchio <[email-masked]>
Date: Fri, 1 Aug 1997 16:28:25 -0400

> for some concern, but in the end that's how we make progress.

What figures can you present to support your statement that
"The size of the MBone continues more or less exponentially"? 

IP multicast traffic can certainly be distinguished from unicast traffic, 
however, "it's all IP to me".  I certaingly have not been noticed an 
"exponential growth" of the Mbone or even anythnin gthat comes close to that. 

A ubiquitous IP multicast network already exisits.  
One merley needs to know how to "tune in".  

> request a multicast feed from their ISP and to deploy multicast within

I disagre with your statement "ISPs won't implement multicast as a service if 
there is no content".  In the words of the late Marshal McLuhan "the medium is 
the message".
When ONet decided to support IP Mulitcasting on Ontario (Canada) content ( ie. 
interesting broascasts) was not a major factor in our decision. 

regards,

-- 
Joseph Porrovecchio 
Network Support Specialist
------
External Networking Facilities Management  	
4 Bancroft Ave. Rm. 101			         
Toronto, Ontario M5S 1C1		   
Voice: 416.978.0188  Fax: 416.978.6620	   
http://enfm.utcc.utoronto.ca/~joseph / N.O.C.: 1.800.268.6324

---

From: "Henning Schulzrinne (BL)" <[email-masked]>
Date: Fri, 01 Aug 1997 20:22:50 -0400

I'm curious as to the 'compelling content'. Since the number of channels
you are transmitting simultaneously is about as large as the number of
TV networks in the 1950s, this has to be fairly broad-interest material,
but not readily available on cable, satellite or tape, reaching beyond
the NASA launch and IETF crowd. Movies on first release? The Playboy
channel? Given the limitations of the end systems, even ignoring the
28.8 issue, watching movies on a small part of a screen which is about
the size of a portable TV just doesn't seem all that appealing
(particularly given that I can only get this at work, where I have other
things to do...).

I would love to get the local traffic report or maybe news (and not just
the CNN version) just before I leave work - but that's on-demand, not
multicast. I doubt that most of the unicast media services that people
now listen to (since it's mostly audio) could be replaced by multicast,
even if the technology issues were to go away.

Given the number of cable/satellite channels, they seem to have pretty
well covered even niche markets. The audience for MSNBC and Fox News is
only about 10,000, after all, and I'd expect that some of the specialty
sports channels have fewer listeners than that [I hope]. (See
http://www.slate.com/itseemstome/97-07-31/itseemstome.asp for the
satellite line-up, a critique and some suggestions...)

Currently, the successful Internet services are on-demand (since there's
plenty of high-quality broadcast competition); multicast makes sense for
feeding caches to feed on-demand requests; I'm less certain in the short
run whether to expect it to be used for large-scale distribution to end
systems.

-- 
Henning Schulzrinne         email: [email-masked]
Dept. of Computer Science   phone: +1 908 949 8344 (at Bell Labs)
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

---

From: Christopher Samuel <[email-masked]>
Date: Fri, 01 Aug 1997 20:14:53 +0100

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

cheers,
Chris
- --

---

From: [email-masked] (Lukas Wunner)
Date: Sat, 2 Aug 1997 11:37:27 +0200 (MET DST)

Hi,

> 2.  a cheap win95/winnt client capable of receiving audio/video at 28.8.
[...]
>     is nor how it can benefit them.

On an aside note, why do people want a mass market for multicasting
so badly? It is my belief that the MBONE has about the same status
nowadays that the Internet had back in 1992/93. It was a great time.
Real content on the web. (on those few websites that existed, anyway)
Anonymous-ftp servers that were never busy. Users who knew how to use
the medium sensibly. Users who helped each other. People who were
grateful to simply have access to such a great medium, without any
jealousness and competition. Almost no spam. Good S/N ratio on Usenet.
No ISPs with dumping prices and non-existent service. No badly investigated
magazine articles about child-porn/Nazis/whatever.

Everything has become worse since then. We had to close down our public mail
relay because it was used to relay spam last Sunday. Almost 50% of Usenet
traffic is caused by spam (given that about 25% are cancels and under the
assumption that the cancels arrive after the spam).

Yes, I know it is inevitable that multicasting will be available to the
masses. But I hope it will stay for a while the way it is now. If it cannot
be avoided, maybe it can be delayed. It is quite obvious that multicasting
will be another killer application, once the current "problems" will be
tackled (e.g. routing protocols which scale well, and clients for
"industry-standard" OS'es).

The way I see it is that access to the MBONE is somewhat restricted because
most people cannot afford the bandwidth required (64 kbps cost about as
much in Germany as a T1 costs in the US), because there is no Windows95
client, and because there is no hype. Given that the quality of the medium
will deteriorate once these restrictions are removed, I do not understand
why people want them to be removed as quickly as possible.

Sorry for ranting, I just couldn't resist. Please do not misunderstand
this as flame bait.

Just my $0.02.

	Lukas.

-- 
lukas wunner         unix, internetworking and security engineer
[email-masked]      LW26-RIPE      http://www.wunner.de/~lukas/
"Those who do not understand Unix are condemned to reinvent it, poorly."
                                               --  Henry Spencer

---

From: "Mr J.C. Evans" <[email-masked]>
Date: Sat, 2 Aug 1997 10:20:48 +0100 (BST)

Hello all,

>even if the technology issues were to go away.

I think I would have to disagree here. Multicast and subscription
technologies like "Push Channels" could work very well together.
Obviously watching your on-demand morning news by multicast
wouldn't save any bandwidth if just you were watching the stream.

But how about using a VCR Time-Shift model ? You decide that you wish to
watch the morning news broadcast that is multicast streamed to the Net
at 7:00am. You have a subscription to this stream. Its stream is
therefore transported by multicast to those ISPs with at least one
customer with a subscription.

We have two choices at this point. "ISP holds" or "Timed log on".

In "ISP holds" a copy of the stream is held until you next log on, when
it is then delivered to you via (say) your dialup line. This is of
course similiar to E-Mail delivery, except that the ISP would only have
to hold one copy for all its customers with a subscription. Its does
need some kind of generic subscription server though.

In "Timed log on" your home machine simply logs on at 7:00am and records
the stream for you. The ISP does not need to hold any the data. This
type of model is already evolving in subscription services (obtaining
push feed of morning paper so it's ready for you when you wake). I
belive it will become increasily common as home PCs are left on
overnight and trusted to make calls to the Net unsupervised.

>satellite line-up, a critique and some suggestions...)

This may be true but the above model works for all subscription services
(morning paper example again). Push / Subscription services seem made
for multicast technologies to me.

Has anyone done any work on this type of model ?

Final point on software issue. Of course experimental high-quality feeds
are necessary to push the boundary. But I think it is important not to
get too hung up on getting the existing M-Bone *videoconfercing* tools
ported natively to the WinPC environment. Conferencing tools such as
VIC/VAT aren't really suited to one-way broadcasting.

What we need for the mass audience it to develop multicast-enabled
versions of the current streaming systems. I believe that Progressive
Networks have already started to experiment with this and that the
current Real Player is multicast enabled. 

How about someone like NASA broadcasting NASA TV or Shuttle missions via
multicast RealVideo (in parellel) ? Surely this wouldn't be too
difficult to arrange, and if the Mars Rover experience is anything to go
by, the is a potential *mass* audience waiting ...

Best wishes,

Jonathan

====================================================================
Jonathan Evans
Department of Electrical Engineering and Electronics
The University of Liverpool                  
PO Box 147                                E-Mail: [email-masked]
LIVERPOOL   L69 3BX                       Fax: (+44)-(0)151-794-4540
United Kingdom (UK)                       Tel: (+44)-(0)151-794-4609                        
====================================================================