Subject: mbone feed information request

From: [email-masked]
Date: Thu, 19 Sep 96 18:58:04 -0400

Greetings,

I appologize in advance if this is not the proper mailing list for my
request.

We (Philips Research) currently get our mbone feed from ANS, our ISP.
We can save ~$2K / month by switching ISP's and go with IBM.
Unfortunately, we have been told that IBM will not provide us with
mbone. Is their some other way we get an mbone feed (tunnel) if not
from our local ISP?  Any information would be appreciated.

Best Regards,
Bill

--------------------------------------------------------------------
Bill Friday 		    email:  [email-masked] 
Philips Research			       Voice: (914) 945-6087
Senior Network Administrator			 Fax: (914) 945-6511
Communications and Computing Resources
345 Scarborough Road
Briarcliff Manor, NY USA 10510
--------------------------------------------------------------------

---

From: George Michaelson <[email-masked]>
Date: Fri, 20 Sep 1996 09:07:10 +1000

I don't work for either of the ISP you use or the one you might choose
to use, but I do work for an ISP. I'd like to make some comment around
the topic.

MBONE is not exactly like other IP. It has poor backoff-under-congestion
behaviour, tends towards semi-constant dataflow, contains data which
is pre-compressed and thus provides few if any "aggregation" opportunities
for other services to share bandwidth. It also tends to come in from
costly sources (typically overseas, or beyond the immediate ISP core network
which implies a peer/transit cost for the bitstream albiet hidden in some
other budgetary process)

Technically, MBONE is just IP. Its IP of a particular type, and detectably
so, but in principle you could find a way to tunnel MBONE over IP-in-IP
such that your ISP couldn't *easily* block it. Thats a bit like an
escalating war of tit-for-tat in the final analysis.

However, you really want to think hard about why you might want not to 
do this. Making IBM offer MBONE is a better way to go. It also will make
them and you confront the scaling and resourcing issues which you will
effectively be "peverting" if you use a sub-optimal delivery path via
some other party in the IBM link.

Another alternative is to retain a low bandwith mbone-only pipe from the
current ISP but again, that has cost and resource implications.

Maybe your current ISPs datarate reflects loadings that help to justify
making MBONE available?

I am sure there are many other technical comments that may be more 
constructive: I think frame relay PVC's offer a way to statmux mbone
into normal IP that should provide for better resource usage, much
as an explicit IP resource sharing method like CBQ does, but I don't
think you will find ISPs offering that kind of novel service soon either.

Please accept my apologies if I have misunderstood the possible solution
you alluded to in your posting.

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

---

From: Jon Crowcroft <[email-masked]>
Date: Fri, 20 Sep 1996 09:12:57 +0100

>which implies a peer/transit cost for the bitstream albiet hidden in some

we've had this debate before - most SERIOUS web users require the same
time/latency throughput as Mbone audio tools, in fact. Some ISPs
resell bandwidth at a high leverage, and rely on most their users
being domestic internet surfer wannabes who don't mind 5-10 secs per
web page, and are prepared to work in offline hours, but as things get
more serious, this is seen as not much use for the person used to a
dirdectory service or home banking down the end of a phone line with
minimal delays - so
at 13-16 packets per ave www transaction, and a human response time of 1 sec
you have a data rate of 8kbytes per sec, or 64kbps - SAME as
uncompressed mbone audio

yes, TCP backs off, but lots of mbone UDP tools do, a BIT (enough to
tolerate transients caused by other TCPs or Mbone tools starting and
stopping)....
 
IMHO, the reasons some ISPs don't offer Mbone really are:
1/ it requires router upgrades to do it native and this is outside
their current deployment (in really large ISPs - e.g. UKERNA,
stability of routing is a critical decision)
2/ it requires new expertise - this costs
3/ they don't have good diagnostic tools yet (well, they're nearly
there, but this is a new IETF work item, so its fair to hold off a
dfew more months)
4/ they haven't seen a good analysis of Mbone traffic
5/ they'd rather wait for mbone AND RSVP, so they can use RSVP for
anything (including bounded delay web access) and BILL for 
it as a premimum service

i don't think the reason for most large ISPs is really the difference
in traffic characteristics - except in some cases, as mis-perceived
difference!

but of course you're an ISP, and I'm not, so you know more about your
ISPs decisions (but of course as a non competitor, its just possible i
am told more about other ISPs than they'd tell a competitor:-)

cheers

 jon

---

From: dave pratt <[email-masked]>
Date: Fri, 20 Sep 1996 14:29:19 +0100 (BST)

Dear mbone folk

If I can add one important and perhaps obvious thing to Jon's excellent
summary:

The key with MBone/multicast is that each byte that passes through expensive
and congested long distance links can be forwarded to many, perhaps hundreds
or thousands of end users. This is not the case for typical WWW traffic where
each users traffic must be carried seperately over these expensive links. 

The business case for running MBone is similar to that for running a news or
caching service: To provide a service to users which increases their
perceived performance and reduces expensive long distance capacity
requirements.

Cheers
--------
WWW - doesn't that stand for "Wait a Week Word" ?
BEER - so much more than just a breakfast drink. 
Dave Pratt      (tel: +44 1473 643840 )
[email-masked]

On Fri, 20 Sep 1996, Jon Crowcroft wrote:

->Date: Fri, 20 Sep 1996 09:12:57 +0100
->From: Jon Crowcroft <[email-masked]>
->To: George Michaelson <[email-masked]>
->Cc: [email-masked], [email-masked]
->Subject: Re: mbone feed information request
->
->
-> >MBONE is not exactly like other IP. It has poor backoff-under-congestion
-> >behaviour, tends towards semi-constant dataflow, contains data which
-> >is pre-compressed and thus provides few if any "aggregation" opportunities
-> >for other services to share bandwidth. It also tends to come in from
-> >costly sources (typically overseas, or beyond the immediate ISP core network
-> >which implies a peer/transit cost for the bitstream albiet hidden in some
-> >other budgetary process)
->
->
->we've had this debate before - most SERIOUS web users require the same
->time/latency throughput as Mbone audio tools, in fact. Some ISPs
->resell bandwidth at a high leverage, and rely on most their users
->being domestic internet surfer wannabes who don't mind 5-10 secs per
->web page, and are prepared to work in offline hours, but as things get
->more serious, this is seen as not much use for the person used to a
->dirdectory service or home banking down the end of a phone line with
->minimal delays - so
->at 13-16 packets per ave www transaction, and a human response time of 1 sec
->you have a data rate of 8kbytes per sec, or 64kbps - SAME as
->uncompressed mbone audio
->
->yes, TCP backs off, but lots of mbone UDP tools do, a BIT (enough to
->tolerate transients caused by other TCPs or Mbone tools starting and
->stopping)....
-> 
->IMHO, the reasons some ISPs don't offer Mbone really are:
->1/ it requires router upgrades to do it native and this is outside
->their current deployment (in really large ISPs - e.g. UKERNA,
->stability of routing is a critical decision)
->2/ it requires new expertise - this costs
->3/ they don't have good diagnostic tools yet (well, they're nearly
->there, but this is a new IETF work item, so its fair to hold off a
->dfew more months)
->4/ they haven't seen a good analysis of Mbone traffic
->5/ they'd rather wait for mbone AND RSVP, so they can use RSVP for
->anything (including bounded delay web access) and BILL for 
->it as a premimum service
->
->i don't think the reason for most large ISPs is really the difference
->in traffic characteristics - except in some cases, as mis-perceived
->difference!
->
->but of course you're an ISP, and I'm not, so you know more about your
->ISPs decisions (but of course as a non competitor, its just possible i
->am told more about other ISPs than they'd tell a competitor:-)
->
->cheers
->
->
-> jon
->

---

From: George Michaelson <[email-masked]>
Date: Sat, 21 Sep 1996 10:47:30 +1000

I certainly don't disagree with this commentary, but from an ISP
perspective, if you have chosen not to (or in some wierd demorgan rule
not (yet) chosen to, which is not exactly the same, unlike boolean algebra)
have MBONE then having people achieve what looks to YOU the provider
like constant bitstream, does truly weird things to your scaling.

Now I got the message several years ago as many of you will know. I don't
need to be told MBONE saves more bandwidth than it wastes, nor that many
existing apps like news can and should use RMP or similar to achieve
the same kind of advantage, but folks, we ain't there yet. Right now,
MBONE means multimedia in virtually all cases, and I suspect some if
not all of the big players who haven't yet switched it on have yet
to make their minds up about what scaleable multimedia they want to flow.

Certainly in a wub context when we are asked if your virtual web offerings
can do VOD or realaudio we get into some twisty passages

I think when RSVPlike stuff is out there the ISP's will put a premium
on it. We'll have econometric policy routing/flowcontrol. It aint gonna
be a flat tarrif its-all-just-ip world. When CBQ is discussed, two
themes come out for us people who pay $1.5m p.a for a 2mb IPLC 

	(1) will we be able to boost effective saturation point/utilization
		== squeeze more bits out of the wire before users complain
		== save money

	(2) can we split the pipe into cheap/medium/expensive classes
		== make an edge for the rich people but not leave the
		   poor trash entirely disconnected
		== one pipe for 224.x and charge for access...

I'd certainly agree about the routing stability thang. Being forced
into an IOS upgrade have definate ramifications. Likewise the premium
on skilled routern configure-eers.

Whatever, I don't think its a good idea to "go behind" your provider.
Talk to them. Make them understand why they *need* to feed you this
product.

-George