Subject: bandwidth (and other support) required for multicast

From: Keith Moore <[email-masked]>
Date: Thu, 29 Mar 2001 16:00:32 -0500

> Network connectivty is kinda hard...

This might be heresy, but I continue to wonder if all of that effort put
into multicasting meetings is actually being put to good use.  Last I 
knew, multicast connectivity was spotty all over the globe, the tools
for using the multicast were hard to come by for many platforms, and 
the quality of the experience for folks actually trying to use multicast
to participate in a meeting varied from barely usable to completely
unusable.

I'm very supportive of both trying to deploy multicast and trying to 
make it possible to participate in IETF meetings from remote locations.
But if the current effort isn't working, maybe we need to try something
different.

Or as a first step perhaps we could take some concrete and relatively 
easy steps to determine how well things are working:

1. poll WG chairs from the last IETF to see how many people contributed
things in real time from remote locations.  

2. if we have a list of email addresses of multicast participants from 
the last IETF, ask those folks how well it worked for them.

3. for the next meeting, update the IETF web pages to describe how to
attend the meeting via multicast - where to get the tools for your
particular platform, how to determine whether your ISP supports 
multicast, and so on.

Keith

---

From: David Meyer <[email-masked]>
Date: Thu, 29 Mar 2001 13:38:03 -0800 (PST)

> But if the current effort isn't working, maybe we need to try something

	Do you think the broadcasts aren't working or 
	multicast connectivity isn't working? Both? Something
	different?

> things in real time from remote locations.  

	Well, not relevant; most people listen, just as they
	do when they are present (and BTW, this is a completely
	legitimate reason to do the multicasts).

> the last IETF, ask those folks how well it worked for them.

	Surveys of this type are hard to do, but it would be
	interesting to understand what worked. Extrapolating
	from that to what the user problem is, however, is 
	likely impossible (after the fact), and so the data
	will be less useful that one might like.
		
> particular platform, how to determine whether your ISP supports 

	Much of this information is available on 
	http://videolab.uoregon.edu

	Finally, its our (IETF) technology. If its not good 
	enough for us to use, then we might want to think about 
	what we're doing and why. Its also important to note that 
	for the 1-to-many case of IETF broadcast,  the problems 
	that we face in todays multicast world will be somewhat 
	eased by SSM deployment.

	Dave

---

From: Keith Moore <[email-masked]>
Date: Thu, 29 Mar 2001 16:51:42 -0500

>         legitimate reason to do the multicasts).

I think it's somewhat relevant, as folks who aren't providing 
immediate feedback might prefer to time-shift anyway, and if
they're time-shifting they could download higher-quality video
than can feasibly be transmitted using multicast, use different
video formats, etc.
 
>         will be less useful that one might like.

again, it would provide at least some indication about how much this
facility is being used.

>         http://videolab.uoregon.edu

thanks for the pointer.  perhaps the IETF web pages regarding meetings
could be updated to include that pointer, or the information from that site?

>         what we're doing and why. 

quite true.  though multicast is hardly alone in this regard.

> 	  Its also important to note that

Keith

---

From: Daniel Senie <[email-masked]>
Date: Thu, 29 Mar 2001 17:31:30 -0500

I've gotten up at 2 or 3 plenaries and asked just who we were
multicasting to. I haven't been able to watch IETF on multicast in over
4 years. It's been that long since I've had access to a site which had
multicast enabled. The "broadband" world isn't enabled for multicast.
I've got plenty of bandwidth available, but since there's no way to
attach to the multicast world, it just doesn't matter.

I've also offered MANY times to pay a remote attendance fee to cover the
cost of using one of the technologies presently widely used on the
Internet. I wasn't able to make it to San Diego, but could have
participated remotely if I'd have been able to get the video and perhaps
had a way to fire questions into the rooms (email, IRC, etc.).

While I know the folks who do all the camera work and such spend a lot
of effort doing it, I'm not sure that effort is worth it. I was able to
watch the San Diego plenary via RealVideo some time after the event. If
that's the only use, though, we could just have folks taping (in ALL
rooms) and later upload that footage.

Feeding a video stream out from each room to one of the CDN companies
would seem quite workable. When not on-site for meetings, I'd be happy
to contribute the same fee as is paid for cookies and danish, only have
that money go to the video distribution effort.

Bottom line: either reformulate this aspect of the meetings to make it
more usable, or make the video available after the fact only.

-- 
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.                    http://www.amaranth.com

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 29 Mar 2001 14:49:26 -0800 (PST)

> than can feasibly be transmitted using multicast, use different

currently we encode and source in two formats. mpeg-1 video w layer 2
audio and h.261 video and audio... by infeasable do you mean the bitrate
is to high? for talking heads/slides/regular motion I think the 1Mb/s
mpeg-1 streeam is more than adequate.

for archiving, which  we are working on now, the files are available in
mpeg-1 and a low bit-rate realvideo format. They'll be available as soon a
we  finish... ideally they'd be up as soon as we get done recording but
it's a bit hecktic while we're there. rebroadcasting the mpeg-1 source
time-delayed is a priority for london...

> again, it would provide at least some indication about how much this

we have data, rtcp data isn't in our opinion extremely reliable however.
some clients don't provide feedback at all, and various network
environments seem to have a detrimental effect on our ability to get rtcp
back from all the joiners.

> could be updated to include that pointer, or the information from that site?

The multicast webpage (which has come down with the rest of the meeting
webpages had a link I beilve. There are a number of changes I want to make
to that webpage for the next time.

-- 
--------------------------------------------------------------------------
Joel Jaeggli				       [email-masked]
Academic User Services			     [email-masked]
     PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E
--------------------------------------------------------------------------
It is clear that the arm of criticism cannot replace the criticism of
arms.  Karl Marx -- Introduction to the critique of Hegel's Philosophy of
the right, 1843.

---

From: "Ole J. Jacobsen" <[email-masked]>
Date: Thu, 29 Mar 2001 14:56:15 -0800 (PST)

Just out of curiosity: Why aren't we using something like a RealAudio
stream? This seems to work well for everything from radio stations to
ICANN meetings. I know it only works ONE way, but I also know that
"questions from the multicast audience" are rarely heard anyway.

The thing about Real (and I guess the Windows Media Player) is that it is
widely available and used, while the multicast tools seem tied to
high-end workstations. Maybe that's just my impression?

Ole

Ole J. Jacobsen 
Editor and Publisher
The Internet Protocol Journal
Office of the CTO, Cisco Systems
Tel: +1 408-527-8972
GSM: +1 415-370-4628
E-mail: [email-masked]
URL: http://www.cisco.com/ipj

---

From: John Hawkinson <[email-masked]>
Date: Thu, 29 Mar 2001 18:24:51 -0500

> multicasting to.

It is not as if the tools don't answer this question. You seem to
be implying, but not stating, that it is nobody. Perhaps you could
be more clear here or provide explicit justification?

> rooms) and later upload that footage.
...
> more usable, or make the video available after the fact only.

So, lack of certainty should not result in killing the effort.

It would be reasonable to request that we look and make sure that
this effort is wisely spent, but it is inappropriate to assert that
we should break something that is working that people are using,
merely because you have not seen (or asked for clearly) a justification.

My understanding is that the folks who volunteer to multicast the IETF
sessions do not represent a financial cost to the secretariat or the
IETF attendees, so I am not too concerned on that count.

--jhawk

---

From: Keith Moore <[email-masked]>
Date: Thu, 29 Mar 2001 19:01:25 -0500

> Why aren't we using something like a RealAudio stream?

please no.  PowerPoint is bad enough.  the last thing we need is 
another thing to bias IETF away from open systems.

---

From: "Ole J. Jacobsen" <[email-masked]>
Date: Thu, 29 Mar 2001 16:08:38 -0800 (PST)

> another thing to bias IETF away from open systems.

Last I checked, the basic player is free, and implementations exists for
all the major platforms, which would put it on par with PDF/Acrobat reader 
in my book.

Open standards is a fine thing, but you have to have some implementations
and common use before it really matters. And let's not forget what the
goal was: allow people to remotely participate (for some value of
"participate").

Ole

---

From: Keith Moore <[email-masked]>
Date: Thu, 29 Mar 2001 19:26:41 -0500

> all the major platforms, which would put it on par with PDF/Acrobat reader

it doesn't run on the platform I use, and on those rare occasions
where they happen to produce a player that runs under Linux emulation
on my platform, about the time I get that player installed on my computer 
is when the content-providers 'upgrade' to a later version which isn't 
supported by the Linux player.  

it's not even close to being on par with PDF.  at least the PDF format
is publically documented (not sure about the most recent version), 
with documentation of sufficient quality to allow multiple independent
implementations to exist (with free source code, no less).

and last I checked, Internet standards (and development of Internet 
standards) weren't just for 'major platforms'.

Keith

---

From: "Ole J. Jacobsen" <[email-masked]>
Date: Thu, 29 Mar 2001 16:44:23 -0800 (PST)

Oh, and of course Internet standards based players are available for
all platforms, right?

Sometimes I think your techno religion outweights any sense of reality,
Keith.

Ole

Ole J. Jacobsen 
Editor and Publisher

---

From: Keith Moore <[email-masked]>
Date: Thu, 29 Mar 2001 19:47:11 -0500

> Sometimes I think your techno religion outweights any sense of reality,

I'm interested in bringing about a better reality,
not preserving the current one.

Keith

---

From: "Ole J. Jacobsen" <[email-masked]>
Date: Thu, 29 Mar 2001 16:55:07 -0800 (PST)

Interesting logic.

So, meanwhile, you would rather we NOT use widely available tools
that allow "remote viewing" just because:

- They aren't standards based

- They aren't available on absolutely every platform

Isn't this counter to allowing more participation?

What's the alternative, wait for Keith to bring about a better reality?

I give up.

Ole

---

From: Keith Moore <[email-masked]>
Date: Thu, 29 Mar 2001 20:07:49 -0500

> that allow "remote viewing" just because:

no, I'm just saying that let's not take two steps backward in the
name of making one step forward.  the formats that we're currently 
using appear to run on more platforms (using a variety of players)
than realaudio's proprietary formats.  

it might be that we need to support unicast playing, or some kind
of multicast tunneling, in addition to native multicast.   but that's
not by itself a reason to give up on the use of open standards.

Keith

---

From: Lyndon Nerenberg <[email-masked]>
Date: Thu, 29 Mar 2001 18:08:54 -0700

> Oh, and of course Internet standards based players are available for

Yes (for a larger value of "all" than RealPlayer supports). vic/vat/rat
are portable to many UNIX variants, and also run under Windows. I
think that MacOS is the only orphan in this scenario, but ISTR there
are protocol proxies available that will gateway to something MacOS
can handle (assuming they can't directly view H.261 multicast with
some other tools).

--lyndon

---

From: [email-masked]
Date: Fri, 30 Mar 2001 10:27:19 +0900

>all the major platforms, which would put it on par with PDF/Acrobat reader 

	what is the definition of "major platforms" here?
	if you could supply a list of freely-available player implementations
	(and URL) it would be really nice.

itojun

---

From: [email-masked]
Date: Fri, 30 Mar 2001 10:28:03 +0900

>	(and URL) it would be really nice.

	NOTE: I'm not advocating *.ppt in any way.
	my personal preference go to Magicpoint (obviously) :-)

itojun

---

From: "Ole J. Jacobsen" <[email-masked]>
Date: Thu, 29 Mar 2001 17:57:20 -0800 (PST)

According to the Real Web page:

Windows 95, Windows 98, Windows 2000, Windows Me or Windows NT 4.0, MacOS

Yes, I know no Unix variants, but the above still covers a large portion
of IETF would-be participants. I am not suggesting that RealPlayer be
made the standard, just an option.

However..... it now appears that the Real people have a new business
model. The player is no longer free, but part of some stupid subscription
service which allows "Access to the audio broadcast of every Major League
Baseball game this season..." and all sorts of other nonsense that I
can do without. 

Sigh.

Any good shareware player for the Mac?

Ole

Ole J. Jacobsen 
Editor and Publisher

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Thu, 29 Mar 2001 21:03:18 -0500

> high-end workstations. Maybe that's just my impression?

There are two parts to this question: codec and retrieval mechanism.
RealAudio supports RTSP, an Internet (proposed) standard, and RTP, as
long as you use non-Real-proprietary codecs. Theoretically, they should
interwork with other similar tools, such as QuickTime. It should be
possible to get implementations for all platforms that are not exotic
(e.g., Amiga or OS9). We (and others) offer free servers for modest
streaming loads.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: "Michael H. Lambert" <[email-masked]>
Date: Thu, 29 Mar 2001 23:35:06 -0500 (EST)

> Baseball game this season..." and all sorts of other nonsense that I

The free version is still available--it's just necessary to dig a little
to find in on the Real web site.

For the NLANR/Internet2 Joint Techs meetings we send the sessions via both
native multicast and Real to maximize coverage.

Michael

+----------------------------------------------------------------------------+
| Michael H. Lambert, Network Engineer                Phone: +1 412 268-4960 |
| Pittsburgh Supercomputing Center                    FAX:   +1 412 268-8200 |
| 4400 Fifth Avenue, Pittsburgh, PA  15213            [email-masked]        |
+----------------------------------------------------------------------------+

---

From: "Matt Crawford" <[email-masked]>
Date: Fri, 30 Mar 2001 08:30:59 -0600

> goal was: allow people to remotely participate (for some value of

Cool!  Where can I get this free two-way interactive RealAudio for Solaris?

---

From: Simon Leinen <[email-masked]>
Date: 30 Mar 2001 18:31:14 +0200

>>>>> "ln" == Lyndon Nerenberg <[email-masked]> writes:
> Yes (for a larger value of "all" than RealPlayer
> supports). vic/vat/rat are portable to many UNIX variants, and also
> run under Windows. I think that MacOS is the only orphan in this
> scenario, but ISTR there are protocol proxies available that will
> gateway to something MacOS can handle (assuming they can't directly
> view H.261 multicast with some other tools).

Recent QuickTime versions can receive IETF multicasts just fine.
I don't know whether they provide RTCP feedback though.
-- 
Simon.
Disclaimer: I don't use MacOS, but most of my colleagues here do.

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 30 Mar 2001 09:12:43 -0800 (PST)

> all the major platforms, which would put it on par with PDF/Acrobat reader

Free as in beer. It's heavily encumbered with Intelectual Property, and
liscensing issues. try and get a non-back-channel multicast liscense from
real for anything other than your intranet.

With h.261/pcm and mpeg-1 you should be able to implement a client for
your platform of choice without stomping on someone elses IP to hard, in
practice clients are already available for most platforms, or can be built
there with a modicum of effort.

> and common use before it really matters.

Can't argue there. but we do have the implementations.

> And let's not forget what the

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 30 Mar 2001 09:20:51 -0800 (PST)

> think that MacOS is the only orphan in this scenario, but ISTR there

macos has quicktime 5.0 which can handle both the h.261/pcm and mpeg stream

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 30 Mar 2001 14:44:55 -0500

>Can't argue there. but we do have the implementations.

        Precisely what is the URL for the Solaris/SPARC
implementation, so I can download it and play with it ?
Or did you mean to say that "we have PC implementations" ?

Thanks,

Ran
[email-masked]

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 30 Mar 2001 12:03:20 -0800 (PST)

> Or did you mean to say that "we have PC implementations" ?

for h.261/pcm take a look at:

http://www-mice.cs.ucl.ac.uk/multimedia/software/

or the mash toolkit.

http://www-mash.cs.berkeley.edu/dist/mash/release/5.0b2/

for mpeg-1

try mim...

http://videolab.uoregon.edu/mim/

we don't currently have a binary maintainer for sparc... but we do build
it over there fairly regularly, so building it should be trivial...
binaries for sparc are in the eariler 1.01 release.

---

From: Alastair Matthews <[email-masked]>
Date: Fri, 30 Mar 2001 21:38:53 +0100

> Any good shareware player for the Mac?

Quicktime seems suitable.

Mac and Windows Clients - both free.

and a free, open source, streaming server.

http://www.apple.com/quicktime/products/qtss/

A.

-- 
Alastair Matthews
Electronics Research Group
University of Aberdeen

[email-masked]

> -
> This message was passed through [email-masked], which
> is a sublist of [email-masked]. Not all messages are passed.
> Decisions on what to pass are made solely by Maurizio Codogno.
>

---

From: Alastair Matthews <[email-masked]>
Date: Fri, 30 Mar 2001 21:40:36 +0100

> can handle (assuming they can't directly view H.261 multicast with

The Mac has the "SillySAPClient" which creates SDP file which Quicktime can
handle.

http://macinfo.its.queensu.ca/MBONE/SillySAPClient.html

And the most excellent MacTV, U Oregon operate a content server.

http://www.iwitnessTV.com/

They offer H.261 and mpeg1 support.

You can only view streamed mpeg1 with the Quicktime 5 public preview.
http://www.apple.com/quicktime/preview/

(Those folk experiencing problems with Multicast and MacOS 9.1 try upgrading
to Airport 1.3, it seems to fix the problem.)

There's even a multicast streaming server or two....

http://www.evological.com/coolstream.html

(Doesn't generate SAP Announcements but that's not a huge problem)

and 

Sorenson Broadcaster

http://www.sorenson.com/products/broadcaster.html

A.

[email-masked]

---

From: "Gary E. Miller" <[email-masked]>
Date: Fri, 30 Mar 2001 12:52:50 -0800 (PST)

Yo Alastair!

Yes, the clients and streaming servers are free for Quicktime.

Too bad there is no free or open source encoder, and no open source
decoder.  Those are still proprietary.  The only way to encode live
streams for Quicktime is on a Mac running Sorenson.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701
	[email-masked]  Tel:+1(541)382-8588 Fax: +1(541)382-8676

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Fri, 30 Mar 2001 16:24:19 -0500

> Or did you mean to say that "we have PC implementations" ?

There are Solaris/Linux/FreeBSD RTSP client implementations in progress,
using rat and vic (which do work fine on SPARC Solaris, among other Unix
platforms) as clients. Should be available by the end of May. One of the
Java SDKs also has relevant implementations for Solaris, but obviously
no complete client. I'm sure there are others; a quick search at
sourceforge shows a bunch of promising things, e.g., using MPEG1
(popCorn).

---

From: Keith Moore <[email-masked]>
Date: Fri, 30 Mar 2001 18:37:57 -0500

> Mac and Windows Clients - both free.

too bad there are no clients, or encoders, for open platforms.

it's not likely to happen anytime soon - the Sorensen codec used 
for QT streaming is proprietary.

let's stamp out proprietary data formats (and patent profiteering)
in our lifetime.

Keith

---

From: Bora Akyol <[email-masked]>
Date: Fri, 30 Mar 2001 21:29:52 -0800

That doesn't help those of us that are behind firewalls ;-)

I like the way NANOG handles the broadcasts.

Maybe we can get one of the content distributors like Akamai to host the 
Quicktime broadcast.

Bora
Writing this from a powerbook running MasOS X

---

From: Einar Stefferud <[email-masked]>
Date: Sat, 31 Mar 2001 08:35:22 -0800

Hi Ole;-)...

Have you found "Any good shareware player for the Mac"?

I have gone back to MAC only, and it feels really good to not suffer 
the Windoze  Blues any more;-)...

Cheers...\Stef