Subject: RE: Raising the bar on the MBone

From: Yves Lepage <[email-masked]>
Date: Sun, 3 Aug 1997 10:00:42 -0400

Hi all,

I'd like to put my two cents worth in:

I think Stephen is right when he says that content is an issue here. Right now, the content of the Mbone, apart from the Shuttle missions can only attract CS scholars.

However, content is not everything. Even if more and better (redefinition: better == destined for a larger audience) content is made available, it will not have a major influence on the popularity
of the Mbone because the barriers for entering the Mbone are still too important. I'd like to go to the moon but I can't. 

One of the major ones is what gave birth to the MBOne: multicast. Multicast is still out of reach from 90% of the planet (guts based figure). ISP's don't support multicast (except the major ones) and I don't foresee them supporting it before Ipv6 gets into the picture. It's just too much
work for serving a group of marginal individuals. Assuming that, I'd advocate that only way we're gonna give the Mbone to the world will be via tunnels (unicast streams of some form anyway) for end users. I know this isn't the current way of looking at it these days and I know
my saying this will obviously give the "better work on IDMR" answers. Please don't, I know. :)

So, even if someone at an ISP that doesn't support the Mbone wanted to join anyway using a tunnel, it would still be a problematic journey because tunnels are currently handled by way 
of broadcasting a tunnel request to a mailing list. This process has proved to be less than reliable in the past; people having to send multiple requests to the list before he/she gets an answer.

Another barrier to the Mbone is the lack of low-bandwidth support. RealAudio can do it, why can't we?

I think that a good strategy for pushing the Mbone would be:

1- put more and better content onto it so that we can get new sites from ISP's
    that do support multicast

2-  Add support for low-bandwidth
3-  Add automated tunnel configuration (or develop the equivalent of a cusee-me reflector 
      so that we can get the bulk of the people who are interested to this.

When an ISP's service is threatened by hundreds or thousands of unicast streams traversing it, they'll start thinking about supporting multicast. IMHO, this is one type of 'demand' that 
ISP's are sensitive to. It goes a fair depth into anti-sociability but if it's what's require to push
multicast (native) then, by all means, let's do it.

Just my opinion,
Yves Lepage

----------
From:  Joseph Porrovecchio[SMTP:[email-masked]]
Sent:  Friday, August 01, 1997 4:28 PM
To:  Stephen Casner
Cc:  [email-masked]
Subject:  Re: Raising the bar on the MBone 

> 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.

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".  

> 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.

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: [email-masked] (Lukas Wunner)
Date: Sun, 3 Aug 1997 21:49:20 +0200 (MET DST)

Yves,

> ISP's don't support multicast (except the major ones) and I don't foresee
> them supporting it before Ipv6 gets into the picture.

Well I didn't make a representative survey but I imagine most ISPs
have at least experimented with the MBONE. I can only speak for the
German market; Xlink is using multicasting in a production environment
(at least that's what I gathered from Heiko W. Rupp's postings, please
correct me if I'm wrong), we (=Seicom) are experimenting with it, and
I'm pretty sure the colleages at EUnet and other ISPs here are doing so
as well. It's just that there's no real user demand right now for multi-
casting services because
a) Joe User can't afford the bandwidth
b) Joe User doesn't even know there is a thing called MBONE.

> When an ISP's service is threatened by hundreds or thousands of unicast
> streams traversing it, they'll start thinking about supporting multicast.
> IMHO, this is one type of 'demand' that 

This will probably be unnecessary. If customers ask for it,
and if scalability has improved, ISPs *will* offer multicasting.

	Lukas.

-- 
lukas wunner         unix, internetworking and security engineer
[email-masked]      LW26-RIPE      http://www.wunner.de/~lukas/
"Time is an illusion. Lunchtime doubly so."

---

From: George Michaelson <[email-masked]>
Date: Mon, 04 Aug 1997 09:12:45 +1000

Commercialized IP services bill either by access bandwidth or received data.
access bandwidth is loosing out to receiver pays because of the squeeze on
margins. Really, commercial IP is becoming a telco-only business and until
that process is completed, you have to bill 'smart' to find the margin.

Under receiver pays, multicast is hard to bill equitably. Its very EASY to
bill for worst-case import cost, but for num-of-receivers > some N where
N is a function of internal distribution costs and locations, the buy price
is obscenely adrift of the import cost, and clients feel rorted (Australian
word for ripped off) and complain. You can't sell it as reduced cost and
efficient transport if you charge it at the worst-case price!

We run it internally. As long as you don't have to sheet home costs then
its simple. 

We're looking into how we can use netflow and other methods to measure
usage. If there was a better fit between the session-id and some charging
model, then you could charge as a function of total listener poolsize inside
the charging cloud, modulo a time delta of checking so your cost varied
as the active listening pool changes. Hard part is making applications aware
of the charge implications and flash up:

	"you are sole listener: company cost is now obscenely high"

when required.

Finding good applications is only part of the problem. Somebody needs to work
on s/w which takes a given horizon of interest, and runs rtpmon or other
smarts to see who is using the damn thing, and calculate the billback so you
can at least do cost recovery.

I have floated models of averaged cost on a bill-in-arrears model to the
company I work for. Thats much more simple, you measure multicast IP as
an aggregate over long baselines, and then chop up the cost amongst 
'subscribers' instead of 'users' but it means shifting the charge model
back to 'community shared cost' from 'end user pays' and thats swimming
against the tide (in a very messy sewer I might add)

I applaud the Casner proposal. I think its good. I also think we have a very
short list memory because I seem to recall this coming up at least 2 years
ago. Damn hard to tell when the right time is sometimes.. you have to keep
trying.

cheers
	-George

--
George Michaelson         |  connect.com.au pty/ltd
Email: [email-masked] |  c/o AAPT,
Phone: +61 7 3834 9976    |  level 8, the Riverside Centre,
  Fax: +61 7 3834 9908    |  123 Eagle St, Brisbane QLD 4000