MBone services
Headbanger
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
Andy McConnell
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
John Meylor
> Does the MBone community discourage/encourage/don't care if ISPs charge
> 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
Chris Rapier
Andy McConnell wrote:
>
> 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.
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
John Meylor
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.
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
> the most part, effective for talks, classes and the like it would have limited
> 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
> connectivity for corporate presentations or as some sort of value added
> service might be feasible.
Multicast is being used widely in the enterprise space already.
- John
Jon Crowcroft
In message <361C37...@cisco.com>, John Meylor typed:
>>> perfectly honest there is still some question as to MBONEs ability to compete
>>> 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.
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....
>>While it is, for
>>> the most part, effective for talks, classes and the like it would have limited
>>> 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.
great - couldnt say better...
>> However, providing MBONE broadcast
>>> connectivity for corporate presentations or as some sort of value added
>>> service might be feasible.
>>Multicast is being used widely in the enterprise space already.
absoultely - e.g. share dealing...
cheers
jon
Peter Parnes
J.Cro...@cs.ucl.ac.uk 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....
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
Ken Carlberg
> 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
John Meylor
>
> 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.
[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
Doug Pasko
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 :)
At 09:29 AM 10/8/98 -0400, Chris Rapier wrote:
>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
Chris Rapier
Jon Crowcroft
In message <361CBE21...@tyranny.com>, 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
Peter Parnes
jme...@cisco.com 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
Andy McConnell
>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)).
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
--
Andy McConnell 真向練 安堵龍
NTT America IP Headquarters
The mind is not a vessel to be filled but a fire to be kindled.
-- Plutarch
Henning Schulzrinne
>
> Chris Rapier wrote:
> >
> > 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.
> However, please prove me wrong. Show me it is a
> > serious competitor. I would rather that it was and that I am misinformed.
>
> and that web thing?
Interesting comparison, as both emerged into the "technical public" at
roughly the same time (1992). Care to compare relative success :-)?
Magnus Danielson
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
TDo...@ixl.com
>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 ?
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
tdo...@ixl.com
(310) 235-3928
Beau Williamson
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
John Meylor
>
> Interesting comparison, as both emerged into the "technical public" at
> 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
Stephen Casner
> Does the MBone community discourage/encourage/don't care if ISPs charge
> 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
Jeffrey S. Young
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.
Jon Crowcroft wrote:
> In message <361C37...@cisco.com>, John Meylor typed:
>
> >>> perfectly honest there is still some question as to MBONEs ability to compete
> >>> 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.
> 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....
>
sukumar sivaram
Jeffrey S. Young wrote in message <361CF3FE...@cw.net>...
>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.
The real limitation for Mbone has been availability of Bandwidth - the
current access speeds of 56Kbps do little to encourage the development of
Multimedia Broadcasts on the Net using Mbone Tools. Applications will
rapidly emerge if the limitation is removed. Two technologies offer this
promise now - Satellite Broadcasts using the DVB/MPEGII transport overlay
and the Cable Modems.
I have been demonstration the ICAST software in London and without exception
everyone agreed that the quality of sound and vision is acceptable.
When we break the bandwidth Barrier - the applications will blossom - think
of Spring!
Cheers
suki
http://www.stns.com
News Across Space means...
Jeffrey S. Young
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.
John Meylor wrote:
> Chris Rapier wrote:
> >
> > 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.
> [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
Jeffrey S. Young
sorry, couldn't resist.
Andy McConnell wrote:
> On Thu, 8 Oct 1998, Chris Rapier wrote:
>
> >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)).
>
> 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 ?
>