Subject: MBone services

From: Headbanger <[email-masked]>
Date: Wed, 7 Oct 1998 15:25:29 -0700 (PDT)

Hello, I work for an ISP that is considering offering MBone feeds to our 
customers.  After doing a little research and actually getting a feed 
online, I have come to the conclusion that most if not all MBone users 
are not charged for these services from their upstream provides...

Does the MBone community discourage/encourage/don't care if ISPs charge 
additional for this service?

-Lance

---

From: Andy McConnell <[email-masked]>
Date: Wed, 7 Oct 1998 17:25:06 -0700 (PDT)

Like a lot of ISPs who offer news and dns secondaries at no additional
charge, MBONE should be a part of that suite of services.  

-Andy

--
Andy McConnell      真向練 安堵龍
NTT America IP Headquarters

G:   "If we do happen to step on a mine, Sir, what do we do?"
EB:  "Normal procedure, Lieutenant, is to jump 200 feet in the air
and scatter oneself over a wide area."
                               -- Somewhere in No Man's
                                  Land, BA4

---

From: John Meylor <[email-masked]>
Date: Wed, 07 Oct 1998 17:46:59 -0700

> additional for this service?

Lance,

Quite a few ISPs are now provisioning for production multicast services,
using PIM internally and PIM with BGP or MBGP externally. The quality
of these services is exceptional, and as some of these ISPs have already shown, 
customers don't mind paying for quality multicast services.

 John

---

From: Chris Rapier <[email-masked]>
Date: Wed, 07 Oct 1998 23:03:19 -0400

Lance, 

I would have to agree with agree with Andy on this under the assumption that
your users would just be recipients and not originators of content. To be
perfectly honest there is still some question as to MBONEs ability to compete
against Real Video and its ilk in a commercial environment. While it is, for
the most part, effective for talks, classes and the like it would have limited
usefulness for most internet consumers. However, providing MBONE broadcast
connectivity for corporate presentations or as some sort of value added
service might be feasible.

Chris Rapier
Network Programmer
NCNE

---

From: John Meylor <[email-masked]>
Date: Wed, 07 Oct 1998 20:56:29 -0700

Chris Rapier wrote:

To be
> against Real Video and its ilk in a commercial environment. 

These are not competing technologies - multimedia applications can and do utilize 
multicast services - and the better quality these multicast services are - the better off the
quality of the transmission, whatever the application.

While it is, for
> usefulness for most internet consumers.

Wrong. Do you want to pass 10,000 copies of the next Starr report or just one?
How about the daily news? Stock quotes? The John Glenn mission?, your next
app upgrade? a training class?   Lot's of people are using multicast in
innovative ways to conserve network resources wisely, this can be done even
without an external business reason, it's just smart engineering.

 However, providing MBONE broadcast
> service might be feasible.

Multicast is being used widely in the enterprise space already.

- John

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 08 Oct 1998 08:55:23 +0100

>>quality of the transmission, whatever the application.
exactly - well said

i would have a hard time seeing how significant amounts of Real Video
would be allowed to be _unicast_+ to multiple simulataneous receivers
on any sensibly run ISPs net....certainly we wouldn't allow it on ours
and we have 155Mbps access per site and >1M hosts....

 >>without an external business reason, it's just smart engineering.

great - couldnt say better...

 >>Multicast is being used widely in the enterprise space already.
 
absoultely - e.g. share dealing...

 cheers

   jon

---

From: Peter Parnes <[email-masked]>
Date: Thu, 08 Oct 1998 10:45:41 +0200

> and we have 155Mbps access per site and >1M hosts....

Quite right. I just wanted to share some real-life information about a 
"broadcast" we (Marratech AB) did a number of months for a customer. The 
situation was a asymmetric media-broadcast where audio, video and HTML slides 
was sent out from a large auditorium. The total seminar was over four days 
with electronic reruns in the afternoons.  This broadcast was transmitted over 
the company's internal network and was done using two different tools 
simultaneously, RealMedia (unicast) and Marratech mPlayer (multicast). During 
the second day of the broadcast the number of simultaneous RealMedia listeners 
increased to 73 at which point the network department of our client freaked 
out as they saw the network load increase way above the normal level and they 
just shut of the connection the RealMedia server internally and the guys doing 
the RealMedia boradcast were only allowed to record the media for later 
retrieval. During the broadcast we (with Marratech mPlayer) peaked at above 
400 listeners out of potentially 1500 which had the mPlayer client installed.

Also note, that the RealMedia session included audio from the presenter and 
video which 99% of the time showed the projector screen (to get the slides). 
On the other side the Marratech session included the same audio but instead of 
showing the slides by filming the projector screen we sent the slides out 
using HTML pages (we had access to all presentation material before the 
sessions started so we could quickly convert the PowerPoint presentations to 
HTML) and finally we broadcast a video feed of the presenter instead of the 
slides.

Just thought someone might be interested in this. If not, just ignore my 
babbling (I still haven't had any coffee today :-)

/P

---

From: Chris Rapier <[email-masked]>
Date: Thu, 08 Oct 1998 09:29:05 -0400

My apologies for disagreeing. I'll just blame it on the fever.

I still do not think MBONE and MBONE applications are a mature technology nor
do I think there currently exists the business incentive to develop them
fully.

This does not mean that I feel MBONE technology is a waste or stupid or
useless only that it is not a serious competitor in most markets. If someone
is planning on charging for MBONE services *and* expects to make any profit
off of it they better have a good way to convince people to install vic and
vat or other multicast aware software (eg. get microsoft or real networks to
include support for it in their next version of their network media foo (or in
the channels or whatever)). However, please prove me wrong. Show me it is a
serious competitor. I would rather that it was and that I am misinformed.

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 08 Oct 1998 15:01:07 +0100

In message <[email-masked]>, Chris Rapier typed:

i think we need an Mbone business case FAQ

1/ multicast is in use
2/ the public domain mbone tools (vic, vat, wb, rat, ivs etc) are in
use
3/ the mbone is a virtual overlay net -= parts of the internet are
runnign "full metal jacket service ip multicast" and using multicast
for applications today
4/ real time is orthogonal to multicast - ip realtime (int-serv,
diffserv) is not a mature technology - it is 7 years younger than ip
multicast......
5/ overprovisioned pieces of the internet run both multicast and
realtime just fine - few are overprovisioned enough to allow much
unicast real time video just yet - real audio, yes, but not video
6/ a lot of the CODECs in mbone tools and a lot of the playout
adaption algorithms are WAY better than allegedly commercial products
(esp. in ip telephony) - there are a few notable exceptions....someone
ought to list these....
7/ see 1

cheers

 cheers

   jon

---

From: Patrick De Muynck <[email-masked]>
Date: Thu, 08 Oct 1998 16:38:15 +0200

In message <[email-masked]>,
Jon Crowcroft writes:

>(esp. in ip telephony) - there are a few notable exceptions....someone

I've seen the quality that a PictureTel H.320 terminal at 3xISDN can
achieve (that is 384 Kbit/s for video *and* audio).

Then coding the same content with vic on a Digital-alpha Workstation
(500MHz) was a very disappointing experience.  Even at 600 Kbit/s you
cannot obtain the same quality.

I think that the absence of motion estimation in vic's H.261
implementation is probably most responsible for this, but I don't
really have the expertise to make a final judgment on this matter.

I understood that the motivation of vic's authors not to include
motion estimation was to make the codec more robust in the face of
packet losses.  I wondered if this is the case in the H.261
implementations of the new H.323 conferencing products (which will be
susceptible to the same packet losses) ??

I think that the way to go for both commercial and non-commercial
software is to use "hardware" H.261 compression (or whatever standard)
on the video-capture board.  I also guess that then I wouldn't be
so annoyed with the delay that the video has with respect to the
audio (very annoying on my SGI-O2, or am I doing something wrong?).

Patrick De Muynck

BELNET, the Belgian National Research Network

[email-masked]  |	DWTC - BELNET
Tel : +32/2/238.36.76	    |	Wetenschapsstraat, 4
Fax : +32/2/513.57.30	    |	B-1000 Brussel

---

From: Ken Carlberg <[email-masked]>
Date: Thu, 08 Oct 1998 10:42:10 -0400

jon,

> i think we need an Mbone business case FAQ

one may want to add the following to your list...

7) existance of different monetary charging models
8) some/most providers still have a bandwidth cap per session
9) deering/cheriton model service model is the de facto / default 
   model in use today

-ken

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 08 Oct 1998 16:01:18 +0100

>>cannot obtain the same quality.

thats not com>>paring like with like

try a PC with an H263+ codec  over 384kbps worth of IP

actually , yo umust be using an old Vic too - motion JPEG or MPEG or
other codecs in Vic can do very well albeity at higher bandwidth, but
thats nothing to do with multicast

 >>susceptible to the same packet losses) ??

sure - there are experimental h.263+s in vic too they arent bad  - the
mbone tools (public domaon) are catching up again, but 
this is orthogonal to network serice

 >>audio (very annoying on my SGI-O2, or am I doing something wrong?).

well the SGI O2 isnt really a lightning machine.....note there are
better audio systems around as well as video - 

but i was responding to critique of the network, not of the
toolsets...

 cheers

   jon

---

From: Doug Pasko <[email-masked]>
Date: Thu, 08 Oct 1998 11:10:14 -0400

I feel I must jump in here.  Multicast networking is very much in use in
a production environment.  Audio and Video may be what everyone sees and
talks about,
but do not underestimate the market for data distribution.  There are a
growing
number of customers who buy numerous connections, to run multicast.  They 
need to shovel around data, reports, audio and video clips.  Many times
it's cheaper to
get Internet connections than to create a private network... and we take care
of the packet replication.  This ranges from Retail stores pumping around
price lists to major broadcasters moving audio and video clips to their
affiliates.
This is why they made MFTP.  ;)  These customers pay good money to save
money.  

But... while we're talking about audio and video.  Real Networks has
implemented
multicast in their servers and clients.  It's been around since Real Server
5.0.
We use it.  You can't tune in with Vic and Vat last I checked, but
you can with a Real Player.  You multicast to anyone who can join and unicast
to the rest.

Do we charge for multicast?  No.  I don't know that it makes sense.  If we
charge our customers, you charge your customers, and we interconnect in
multicast...
do we charge each other?  A domain I don't want to touch with a 1000' pole.  
I personally don't want to wall off my multicast network.

Just my opinions.  Multicast can make you money, even when you don't charge
for it.

Doug Pasko
Cable & Wireless Internet Engineering
	...the network formerly known as internetMCI  :)

---

From: Chris Rapier <[email-masked]>
Date: Thu, 08 Oct 1998 12:14:44 -0400

> but i was responding to critique of the network, not of the

Ahhh, that might be the problem then. I think the MBONE is perfectly fine and
very useful as a network. I should have said that I do not think the golden
application, the one that will get the average network consumer (say Bob in
NYC who just signed up with Netcom) to stand up and say, hey! Multicast
rocks!, exists. However, the fact that Real Video 5.0 has multicast support
changes much of this. The goal now would be to get content providers to
distribute more than IETF meetings and technical conferences.

NB: I know that there are several mbone based radio station feeds and probably
a non tech video feed or two. However, more are needed if MBONE and MBONE
technology are going to gain the lead (eg. overtake traditional ip network
models for distributing media feeds). 

I think a business case FAQ is an excellent idea.

---

From: John Meylor <[email-masked]>
Date: Thu, 08 Oct 1998 09:15:43 -0700

> do I think there currently exists the business incentive to develop them
[clip] 
 However, please prove me wrong. Show me it is a
> serious competitor. I would rather that it was and that I am misinformed.

Remember when folks said the same thing about Mosaic 
and that web thing?
:-)

- John

---

From: Andy McConnell <[email-masked]>
Date: Thu, 8 Oct 1998 09:21:35 -0700 (PDT)

On Thu, 8 Oct 1998, Chris Rapier wrote:

>the channels or whatever)). 

M$'s Windows Media Player has support for Multicasting.  IN the default
setup, there's support for Streaming Real Video and Windows Media.. Both
default to Multicasting as the option of choice if available.  So, it its
there.

Hearing this discussion, it reminds me of another reason NOT to charge for
it - reduced backbone bandwidth.  Why discourage your customers from using
a higher-quality service that costs you LESS b/w to provide ?

$.02

-Andy

The mind is not a vessel to be filled but a fire to be kindled.
                               -- Plutarch

---

From: Peter Parnes <[email-masked]>
Date: Thu, 08 Oct 1998 18:46:33 +0200

[email-masked] said:
> Remember when folks said the same thing about Mosaic  and that web
> thing? :-) 

Hey, I still miss Mozilla versions 0.6 and 0.8. Great tool and you actually 
got your questions answered and bugs fixed by the author :-) :-) :-)

/P

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 08 Oct 1998 13:37:45 -0400

> Remember when folks said the same thing about Mosaic

Interesting comparison, as both emerged into the "technical public" at
roughly the same time (1992). Care to compare relative success :-)?

---

From: Magnus Danielson <[email-masked]>
Date: Thu, 08 Oct 1998 20:04:39 +0200

>>>>> "H" == Headbanger  <[email-masked]> writes:

Hi Lance!

 H> Hello, I work for an ISP that is considering offering MBone feeds to our 
 H> customers.  After doing a little research and actually getting a feed 
 H> online, I have come to the conclusion that most if not all MBone users 
 H> are not charged for these services from their upstream provides...

 H> Does the MBone community discourage/encourage/don't care if ISPs charge 
 H> additional for this service?

I guess that you could get many answers on this one.

Traditionally things just happend without money changing hands.

Ultimately you would not see a 'feed' as direct as you would with news
or something. The ultimate goal is to drop the tunnels and use native
multicast supported with the necessary routing protocols.

Now, if you would charge extra for enabling multicast on their tap,
they would search for someone to give them a tunneled multicast feed
for free. This is not exactly what you would like to see, cause now
that traffic is traversing your network in a possibly not so neat way.
If you see a lot of this you could even end up having virtually the
same traffic multiple times over the same link. This would eat up
bandwidth that your other customers could be using. With the current
load of a Mbone feed this might not be a great problem, but when more
and fatter channels is becomming more common you might see that you
are upgrading your links earlier than you would otherwise.

So, it may not be such a great thing to charge, at least not much.

BTW. A similar discussion can done on resource reservation.

I would not look on multicast as yeat another great service to take in
great money (such as in Video, No Demand) but rather as a smarter way
to do networking for some applications and thus keeping the company in
shape to be competive.

Also, look on trends... things like Linux is passed around for free,
yeat people can make good money on it by using it. Sure, you pay a few
USD for the CD, but this is handling cost as compared to other OSes.

I think that my personal preference is clear by now...

Cheers,
Magnus

---

From: Bill Fenner <[email-masked]>
Date: Thu, 8 Oct 1998 11:04:30 PDT

In message <[email-masked]> Jon Crowcroft wrote:
> >> ... I also guess that then I wouldn't be

But this is an application issue - vic and vat don't even bother trying
to synchronize the audio and video streams together.  Although video is
still fairly difficult, particularly because of the variability in
decoding time, very precise timing of the audio is possible - I have
seen an O2 so well synchronized with specially designed network audio
hardware (just using the RTP timestamp and NTP synchronization) that
you don't hear any phase difference if you pipe both audio streams
through the same amplifier.

  Bill

---

From: [email-masked]
Date: Thu, 8 Oct 1998 11:24:16 -0700

>a higher-quality service that costs you LESS b/w to provide ?

The reduced bandwidth argument is a little bit tricky.  I.e., "reduced" in
comparison to what?  If you compare to the load that n unicast receivers
would place on the net, there is an obvious reduction.  But, if you compare
to the load that 1 unicast source can place on the net, there is an obvious
increase.

This suggests that receiving multicast might be free, but sending it might
cost extra.  On the other hand, the additional sending cost probably gets
passed on to the receivers in some fashion anyway, e.g., by making them
view advertising.  If the ISP doesn't collect it, the sender probably does.
Not sure how a transit carrier fits in economically, since it is both
sender and receiver (from the point-of-view of different parties it
contracts with).  Perhaps it all balances out.

Also, important not to neglect the additional routing state that a
multicast session creates.  Since multicast addresses cannot be aggregated,
I guess the effect of an active multicast group is roughly the same as a
new network attaching to the Internet for a while?

Tim

Tim Dorcey
iXL-Los Angeles
[email-masked]
(310) 235-3928

---

From: Beau Williamson <[email-masked]>
Date: Thu, 08 Oct 1998 13:13:14 -0500

>roughly the same time (1992). Care to compare relative success :-)?

I think this is an apples to orangutans comparison.  Mosaic was an
extremely compelling application that could use an existing infrastructure
(unicast Internet) to become widely popular.  

Once we get a multicast Internet infrastructure in place to some degree,
some multicast application is likely to do the same.  I personally don't
think that the application will be video.  I've long held that an
audio-conference app with WB or other similar data-sharing, multicast
application is a much more possible candidate for the "killer" app.  If and
when Microsoft bundles this sort of simplistic multicast-based, meeting
application into WinXX, I think the demand for multicast will really take
off.  Given the current bandwidth of the Internet, widespread use of
multicast video applications seems like a nonstarter to me.

Beau Williamson

---

From: John Meylor <[email-masked]>
Date: Thu, 08 Oct 1998 11:27:27 -0700

> roughly the same time (1992). Care to compare relative success :-)?

The web required development of an application which used
existing unicast services.

Multicast requires the development of both the applications
as well as deployment of the underlying multicast services,
this is a far greater engineering challenge, but certainly
offers no less opportunity, perhaps more, for those who
understand this.

- John

---

From: Stephen Casner <[email-masked]>
Date: Thu, 8 Oct 1998 15:43:21 -0700 (Pacific Daylight Time)

> additional for this service?

It's really up to you whether you want to charge for this service or
not.  If you did decide to charge, the harder question might be to
figure out how much.  As has been expressed in the discussion
following Lance's post,

  - it's not clear how charging should work to make revenues follow
    costs.

  - it's hard for you assure some level of service on an MBone feed,
    in particular if the sender and receiver aren't both within your
    network.

But if your customers are asking for non-assured MBone service and are
willing to pay you extra for it, that's between you and them.

You may also want to explore implementation of native multicast
instead, where you are likely to be able to provide a better quality
and higher capacity service.  This can be connected to the MBone,
too, though there are some subtle issues when interworking multiple
multicast routing protocols.

As I read through this discussion, I think there has been a problem
with confusion among

  - IP multicast routing and service in general;

  - the MBone as the experimental deployment of IP multicast routing
    on a global scale;

  - a set of applications made popular on the MBone.

The are all quite distinct.  As others have said, IP multicast is
being used already and its use is critical to the wide-scale depoyment
of a number of existing and future applications.  Whether or not the
deployment of multicast in the MBone achieves the desired level of
service is not necessarily relevant (except that I think the MBone has
served to demonstrate some possibilities).  But in particular,
comparing research applications to commercial applications is not
useful because they are not intended to be competitive.

							-- Steve

---

From: "Jeffrey S. Young" <[email-masked]>
Date: Thu, 08 Oct 1998 13:18:54 -0400

Dear John,

You're calling our baby ugly.  Please stop :-) Cable & Wireless internet
run a Joint Venture with Real Networks called the Real Broadcast Network.
We source quite a bit of unicast traffic from this network.  By comparison our
network is currently between 5 and 13 by OC-12 per pop.  I don't know how
many millions of customers it ultimately serves.

There is a very good reason to build a service which delivers unicast video
content.  It's called 'on-demand' delivery.  Multicast is a poor medium for
on-demand delivery of content.  The game in on-demand is to move the
content to the edges of your network thereby giving the end user a low-latency,
'quality' service.  It's difficult to talk in terms of quality video when most users
are connected to the network at 56kbps :-) Quality is moving forward as fast as the
internet can peddle and i expect it to be a service that will someday rival current
broadcast mediums.

Let's remember that multicast is a tool, not a holy grail.  We certainly use
multicast to link the unicast delivery sites, long-haul bandwidth is expensive,
intrapop bandwidth is free.  Multicast is a rather important tool in my toolbox.
I value it greatly as such but i'm not about to let the notion of  'ubiquitous
multicast deployment' stand in the way of offering real products.  In 1995,
while we were MCI, I and others built one of the largest multicast networks
in service.  It may still be one of the largest.  It does not run on the same
routers that route unicast traffic, it is an overlay network.  Why?  because one
of the biggest issues that face ISP's today is platform reliability.  We cannot
afford to introduce another service into an already 'unstable' platform (if
you read between the lines here, platform=router).  My
point is that we are driving multicast deployment as fast as we feel we can.

Through the RBN, we also multicast live content for those few users that are
able to receive it.  our experience with this network shows
that 50-70% of traffic is on-demand. That's a rather large segment of the
service that one can't afford to ignore.

---

From: "Jeffrey S. Young" <[email-masked]>
Date: Thu, 08 Oct 1998 23:47:03 -0400

tough comparison,

when mosaic hit the streets everyone instantly understood it
and it exploded onto the network.  multicast is a wonderful
technology but it's proponents have been searching
for an mass appeal application for years.  it's elegance is
lost on the common man so let's declare victory and get on with
it already.  i'm quite happy to use it as a support
tool as well as a tool to deliver real time audio/video and mass
file distribution.

---

From: "Jeffrey S. Young" <[email-masked]>
Date: Thu, 08 Oct 1998 23:48:21 -0400

because that's what marketing people do?
sorry, couldn't resist.

---

From: Victor Reijs <[email-masked]>
Date: Tue, 13 Oct 1998 14:37:36 +0200

Hello all of you,

Great this discussion about the maturity of Mbone services. I think lots
should be possible with the services in the network and with the tools
at the end stations (even Windows95/NT have now mature Mbone tools, like
the UCL/ISI ones, Real, etc.). But the main problem I stil see is the
connectivity to an multicast service.
At this moment I am trying to do an experiment with broadcasting (using
multicast); doing such an experiment is not that difficult, but getting
your viewers connected to the Mbone services is quiet difficult. I am
looking not only at viewers on fixed IP lines, but also towards dial-in
users. In most instances dial-in users are not able to get IP multicast
(becasue most dial-in ISP don't know yet what IP multicast is [remember
I am only talking about multicasting up to 20 kbit/s, so LOW quality]).

In my tests I want to see if I can get enough viewers, by supporting
them with help and possible software solutions (tools and
unicast-muliticast gateways, like UTG, liveGate and others). The tests
will be in November, so enough preparation time for ISP and viewers. I
wonder how wide spread Mbone will be then...

More info on this project:
. see sdr session (Testing live broadcasts from Maes Howe)
. http://maeshowe.mypage.org/

If you have ideas how to support IP multicast in a wider environment,
please let me know them off line.

All the best,

Victor