Subject: RealNetwork, MCI, @Home, Icast

From: Amancio Hasty <[email-masked]>
Date: Mon, 03 Nov 1997 00:07:27 -0800

Out of the blue I  decided to buy a copy of the magazine, Red Herring,Nov 1997.

On page 30 , the article "Stream On" had a few comments on the mbone :

A few things caught my eye:

"Jeff Huber, director of server and network products for @home, understands
why RealNetwork is reluctant to use the Mbone. Mr Huber claims that the 
majority of the Mbone traffic at the backbone layer is in fact unicast and,
as a result, is not scalable". In addition, he says that the mbone is mainly
the preserve of academics and computer enthusiasts , not a viable 
commercial medium. Jeff Young, an MCI engineer, add that the Mbone also
does not permit users to access recorded content, which is a significant
drawback to consumers. 

----

The article goes on with lots of politically loaded statements. Like :

"Vinay Kumar, president and chief technology officer of Icast, ...
suspects that MCI and Progressive goal is to set a propieratory 
multicasting standard"

----

First , I can't believe that someone from a company like @home can 
claim that the mbone is not scalable and on a minor point I don't
see why Yeff Young will state that the mbone does not permit 
plackback of recorded events. There are other interesting 
statements and naturally controversial statements on this
article .

I just have a simple question : Whats going on? 8)

	Cheers,
	Amancio

---

From: Petri Helenius <[email-masked]>
Date: Mon, 3 Nov 1997 14:56:39 +0200 (EET)

At least it's good to know where your "enemies" of open standards
are. Is the article available online somewhere?

Pete

---

From: Jim Boyle <[email-masked]>
Date: Mon, 03 Nov 1997 08:33:22 -0800

I haven't read the article or seen the direct quote, but I believe what
Jeff's comments are in reference to are "on-demand" viewing.  Mbone does
allow rebroadcast (such as Munich IETF rebroadcast for US audiences).
However, I can't think of the advantage of using mbone for on-demand
content like music clips, unless you can corral several users' requests
together into one multicast.  This is an old can of worms though, nothing
new here.

Jim

---

From: Petri Helenius <[email-masked]>
Date: Mon, 3 Nov 1997 16:06:22 +0200 (EET)

> together into one multicast.  This is an old can of worms though, nothing
This is a kind of application where you need to evaluate when to
switch over or if you want to be efficient, code that into your piece
of software. I would imagine that a popular on-demand site would have
enough requests for any single piece of media that if it would
consolidate all requests from one minute the average viewership would
be at least hundreds if not more. Remember that for example Netscape
sends out their home page hundreds of times every second. (just a
statistic, no other point intended) That translates to tens of
thousands of transmissions of same content every minute. One hundredth
of that would be enough to warrant a multicast tranmission of a
higher-bandwidth stream.

Pete

---

From: Mark Handley <[email-masked]>
Date: Mon, 03 Nov 1997 10:05:45 -0500

>allow rebroadcast (such as Munich IETF rebroadcast for US audiences).

Also see the IMJ (Interactive Multimedia Jukebox) sessions in sdr, and
the Mbone VCR work.  But I'm preaching to the converted here...

Cheers,
	Mark

---

From: "Jeff Young" <[email-masked]>
Date: Mon, 03 Nov 1997 11:23:00 -0500

If you've ever talked to someone in the press about anything remotely
technical and then read the article later, you know how frustrating this
can be.  Writers seem to have their own agenda, one they've developed
before they even talk to you.  You can hear it in their questions.  They
reduce a 30 minute interview into sound bytes that, woven together with
their own theme, produce the type of quote you've referenced.  

During this particular interview I stressed the fact that the Real Network
could make use of multicast.  The fact that MCI was a proponent of the 
widespread use of multicast technology.  Because there had been so much
press comparing uucast to the Real Network, I was trying to point out that
they are completely different systems (one a closed loop multicast system
on which one could base a broadcast network and one a turnkey broadcast 
system that can reach Internet users as multicast or as unicast).  The 
'access to recorded ...' misquote comes from the explanation of how the
two systems differ.  Obviously the MBONE is capable of delivering recorded
media.  What it doesn't do, what it wasn't designed to do, was ON-DEMAND!
Somehow ON-DEMAND got left out of the sound byte.  Because the Real Network
is made up of machines that have large cache space, ON-DEMAND is possible.

As for Vinay's quote, the word 'ridiculous' comes to mind.  Real Networks
has just done a great job of distribution.  If there is a 'brand' in this 
industry with name recognition it is Real Audio.  I don't know how a company
like Real Networks could protect their investment in software development if 
they chose to make their transmission platform and payload format completely
open.  There are also some (RTCP) open protocols that simply don't fit their
model.  In the end, if the MBONE and other broadcast services are to make it
on the internet the game will become less about formats and more about 
content anyway.  Probably a tough thing for us engineers to swallow, but the
rest of the world just doesn't care until it doesn't work.

-- 
Jeff Young
[email-masked]

---

From: "Jeff Young" <[email-masked]>
Date: Mon, 03 Nov 1997 11:25:35 -0500

and just where would that be?

-- 
Jeff Young
[email-masked]

---

From: "Jeff Young" <[email-masked]>
Date: Mon, 03 Nov 1997 11:32:06 -0500

Or perhaps the deployment of a caching system to cache the 
web pages closer to the requestors.  Users tend to vote with
their 'feet' (or mice as the case may be) and you need to 
balance your savings (multicasting the data) with their inconvenience
(longer wait times).

-- 
Jeff Young
[email-masked]

---

From: Petri Helenius <[email-masked]>
Date: Mon, 3 Nov 1997 19:37:06 +0200 (EET)

> and just where would that be?
At the same places where people deploy substandard content "because
Internet cannot be used to do better".

Pete

---

From: "Jeff Young" <[email-masked]>
Date: Mon, 03 Nov 1997 13:40:15 -0500

geez petri,

if you see a problem, at least be man enough to say exactly what the problem
is and with whom you have the problem.  or is the object of the game to string
the audience along with inane riddles?

-- 
Jeff Young
[email-masked]

---

From: "Jeffrey C. Ollie" <[email-masked]>
Date: Mon, 03 Nov 1997 13:20:43 -0600

Amancio Hasty wrote:
> "[...] Jeff Young, an MCI engineer, add that the Mbone also
> drawback to consumers."

IMHO, this comment is fairly accurate.  While it is technically possible
to multicast recorded content, the software for doing so isn't widely
available (or at least not that I've found).

Personally, I'd find it kind of cool if someone would write an
application that would read an auido CD and multicast the digital audio
data across a LAN to multiple receivers.  If I didn't already have a
million other things to do I'd look into it myself.

Jeff

---

From: Petri Helenius <[email-masked]>
Date: Mon, 3 Nov 1997 21:25:04 +0200 (EET)

> the audience along with inane riddles?
I intially wrote a lengthy response with names and all but decided on
not submitting it since it would fairly easily pollute the list for
a week or so. If anyone wants to know a specific list companies whose
marketing or operating practices I have a problem with, feel free to
drop me an email and I'll tell you.

On the more general side of things, I've problem with people who let
themselves to be quoted by clueless press people (as you so well
describe) without telling them that you need to see how you are quoted
before it goes out on print. Some press people refuse this and I just
send them away, others adhere and usually the quote is fairly accurate
and not the bullshit where this thread originated on. I think it hurts
the industry much less _NOT_ to talk than get your name on a paper
regardless what they tell you've said.

I'd rather like to see the available content to drive the network
forward, rather than the network drive the content backward, as it
seems to be the case today. That's why I specially like the idea of
IMC. Idea, because as of today, it has not been realized into bits and
bytes yet. I'm anxiously waiting for the day when I get quality
content over the *DSL line I have. Quality that matches the bandwidth
available. I've yet to see any of the replication-server based systems
to do that.

Pete

---

From: Petri Helenius <[email-masked]>
Date: Mon, 3 Nov 1997 21:54:44 +0200 (EET)

> million other things to do I'd look into it myself.
That's already commerically available. My personal approach to this is
not to go and swap CD's but instead record them to MPEG-audio and play
that out as a RTP stream which can be then received and played out by
any standards-compliant RTP-receiver having a MPEG decoder.

Pete

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 4 Nov 1997 07:16:46 +0100 (MET)

> any standards-compliant RTP-receiver having a MPEG decoder.

Which applications do you use for this ? I'd like to have them too ;-))

Toerless

---

From: Karl Auerbach <[email-masked]>
Date: Mon, 3 Nov 1997 22:38:48 -0800 (PST)

> Which applications do you use for this ? I'd like to have them too ;-))

After seeing other company names being used, I figure the following won't
be considered too commercial...

Check out Precept's server -- It does IP multicast using RTP/RTCP and can
do live MPEG encoding and transmission or scheduled replay of pre-recorded
MPEG sources, including audio.  (It also handles other encodings as
well.):

	http://www.precept.com/

By-the-way, if you do transmit commercial material, make sure you have the
right copyright permissions.   As someone said, it will be content that
drives what happens on the net.  And the best way to scare away good
content is to trample on the rights of the content owners.

		--karl--

---

From: Amancio Hasty <[email-masked]>
Date: Tue, 04 Nov 1997 01:22:05 -0800

Can someone do a summary spread sheet of mbone apps for win95 and winnt 
and place it in a web page?

Is just that the question of mbone apps or functionality of mbone apps
keeps surfacing in this mailing list and it will be nice to just point 
people to a web page --- hopefully not hosted by an mbone company.

	Cheers,
	Amancio

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 4 Nov 1997 12:13:20 +0100 (MET)

> together into one multicast.  This is an old can of worms though, nothing

That might be sensible only if we had some bigger caching built
into mrouters. %-)
Actually there could be one way caching, that would synchronise users 
requests, and the other way - 'object caches' that would cache the popular
contents that's frequently demanded. this way transmissions 'on-demand'
would not pollute 'the whole mbone'.
but this is probably not about mbone any more ...

--w

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 04 Nov 1997 09:04:42 -0500

I've started an OS-based table of RTP-speaking "Mbone" applications at
http://www.cs.columbia.edu/~hgs/rtp . Obviously, this needs filling in.
Your help is appreciated.

Henning

---

From: Roy Bennett <[email-masked]>
Date: Tue, 04 Nov 1997 14:32:43 +0000

Henning
Graeme Wood is maintaining a Multimedia Conferencing Applications Archive
at Edinburgh at
 http://ugwww.ucs.ed.ac.uk/mice/archive/
which may fill some gaps and also be of interest to people on this side of 
the pond....

Roy

---

From: Peter Tebault <[email-masked]>
Date: Tue, 04 Nov 1997 10:18:08 -0800

Another place to look:

http://www.merit.edu/net-research/mbone/index/windows95.html

http://www.merit.edu/net-research/mbone/index/platforms.html

-Pete-

---

From: [email-masked] (Scott Michel)
Date: Tue, 4 Nov 1997 10:51:27 -0800 (PST)

It seems to me that one could play funny games with the playout speed
on individual streams, so that eventually one or more playout streams
could be aggregated (i.e. speed one up, slow another down, until they
both play the same content.)

-scooter

---

From: Petri Helenius <[email-masked]>
Date: Tue, 4 Nov 1997 21:27:03 +0200 (EET)

> both play the same content.)
I've been playing with ideas along these lines for a while and I
haven't gotten far enough to check if RTSP would be suitable to do
this with it's current state.

With today disk-spaces, although they usually tend to be fairly full,
one can easily buffer at least 10 minutes worth of full rate MPEG-1
stream (about 100 megabytes) and keep buffering what comes from the
network while playing from the buffer that has been received 10
minutes ago. This can also be used to implement basic pause and
movement controls in a receiver application.

Pete

---

From: Andrew Pimlott <[email-masked]>
Date: Tue, 4 Nov 1997 15:01:01 -0500 (EST)

The "Index of MBone Software by Title" at
http://www.merit.edu/~mbone/index/titles.html seems to be pretty
up-to-date (modified 10/24) and complete (over 50 titles).  Hopefully you
can coordinate with the maintainer of that page to keep both lists
current.

Andrew

---

From: Ross Finlayson <[email-masked]>
Date: Tue, 04 Nov 1997 19:00:19

FYI, I discovered that the "Red Herring" article is now online:

	http://www.herring.com/mag/issue48/points.html

    Ross.