Subject: Suggestion

From: Telecom Regulatory Commission of Sri Lanka <[email-masked]>
Date: Thu, 19 Oct 2000 13:08:00 +0500

Why cannot IETF arrange Netmeeting sessions. So that all new techniques 
such as Video, Audio, White board, Chat etc. can be used to exchange the
valuable knowledge members posses.

Champake/Sri Lanka
Assitant Director (Information & Documentation)
Telecommunications Regulatory Commission
276 Elvitigala Mawatha,
Colombo 8,
Sri Lanka.   Tel: (941) 684865  Fax: (941) 689341 
Email: [email-masked]/[email-masked]
Web: www.geocities.com/champake or www.trc.gov.lk

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 19 Oct 2000 09:09:24 +0100

In message <[email-masked]>, Telecom Regulato

 >>valuable knowledge members posses.
 
we do - we not only have put ietf WGs email in the public and archives
on the net and all docs on the web, but IETF meetings have some of the
main WGs live multicast out on the net

we don't use netmeeetign per se, coz its a specific technology, and
prefer to use somethign where the toolset is multiplatform and widely
avaialble - its done somewhat on a volunteer basis, so  depends also
on what the volunteers are interested in and expert at....

it would be nice to
a) expand this
b) offer other formats (webcasting and netmeeting gateways)...

its up to you (i.e. anyone) to offer to do it as far as I am aware!

 cheers

   jon

---

From: Daniel Senie <[email-masked]>
Date: Thu, 19 Oct 2000 08:25:51 -0400

> main WGs live multicast out on the net

I wonder if we have any statistics available on how many people actually
tune in to the multicast sessions? Many network providers are presently
unable or unwilling to allow multicast into their networks. Last I
asked, this included ATT Broadband/MediaOne/Roadrunner, among many
others.

> b) offer other formats (webcasting and netmeeting gateways)...

I've asked in the past, at plenary, and not gotten much of a response.
I've had to miss a few of the meetings in the past few years for various
reasons, and had hoped to participate, but the technology we use is just
not widely available. It may be widely available in academia, but our
participants come from a much broader spectrum.

I asked about this a few times, concerned that the volunteers who spend
so much time and effort creating the video from the sessions may be
sending that information out to a vanishingly small audience.

To ask it another way, when was the last time anyone heard a question
from the mbone attendees?

I've also raised the issue before that when I can't make it to a
meeting, I'd still like to pay a meeting attendance fee, and have that
money go toward the cost of providing the sessions via Real Audio/Video,
or other similar technologies which can operate across a broader array
of networks. Combined with some capability to email in questions during
a meeting, this would be useful to the active IETF participants who
can't make the trip to a particular meeting.

> its up to you (i.e. anyone) to offer to do it as far as I am aware!

I'm offering dollars, when I'm not able to make it to the meetings. If I
pay a remote-attendance fee, that money obviously doesn't need to be
spent on food, so spending it on video collection, transmission and
redistribution seems like a good idea.

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

---

From: Keith Moore <[email-masked]>
Date: Thu, 19 Oct 2000 09:34:22 -0400

> Why cannot IETF arrange Netmeeting sessions.

the last thing we need is more pro-Microsoft bias in this community.

---

From: Mark Atwood <[email-masked]>
Date: 19 Oct 2000 08:29:18 -0700

> valuable knowledge members posses.

I have a better idea. Put the meetings online using our *own* IETF RFC
multimedia protocols, to "eat our own dogfood" as it were, rather than
use a two-bit propriatarily "extended" mediocre implementation of a
painfully roccoco ISO protocol that was hacked (badly) to run over UDP
instead of ISDN, in a matter guaranteed to give ulcers and headaches
to every firewall admin on the `net.

Netmeeting? *spit* I used it for a year to "video telecommute".

-- 
Mark Atwood   | Freedom from want, freedom from fear, freedom from choice.
[email-masked] | Is that the freedom you want? 
http://www.pobox.com/~mra

---

From: Dennis Glatting <[email-masked]>
Date: Thu, 19 Oct 2000 08:59:58 -0700

> the last thing we need is more pro-Microsoft bias in this community.

Amen.

---

From: Tim Salo <[email-masked]>
Date: Thu, 19 Oct 2000 12:32:53 -0500 (CDT)

> the last thing we need is more pro-Microsoft bias in this community.

I hope that this sentiment won't distract us from what I hope are more
important objectives, one of which presumably is to effectively communicate
with our audience.

I don't know whether NetMeeting is the right answer.  But, I am pretty
sure the question ought to be "How can we more effectively communicate
our message?", not "How can we avoid using Microsoft products?"

(Awaiting a modest proposal to outlaw PowerPoint at IETF meetings...)

-tjs

---

From: Mark Atwood <[email-masked]>
Date: 19 Oct 2000 11:13:06 -0700

> (Awaiting a modest proposal to outlaw PowerPoint at IETF meetings...)

What wrong with SliTeX anyway? Other than that the files are too
small compaired to PowerPoint?

(I swear, every time I see that blue fade to black background, I feel
my eyelids start to get heavy.  Too many sales and PHB presentations,
probably.)

---

From: Keith Moore <[email-masked]>
Date: Thu, 19 Oct 2000 15:04:21 -0400

> our message?", not "How can we avoid using Microsoft products?"

agree entirely.  but in my mind part of communicating effectively 
is avoiding the use of protocols or data formats that can only be 
read by a particular vendor's software.

> (Awaiting a modest proposal to outlaw PowerPoint at IETF meetings...)

I'd love to see more discussion and fewer slide presentations at IETF
meetings, for reasons having nothing to do with Microsoft.

Keith

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 20 Oct 2000 08:37:22 +0200

>asked, this included ATT Broadband/MediaOne/Roadrunner, among many

my anarchistic self wonders....
what would happen if there was an open server that would allow (filtered) 
MBONE tunnels to connect, and a widely available (Linux?) client that would 
connect to that server, and behave like a multicast router?

"start this program on a spare PC, and you too can watch the IETF multicast".

I've been frustrated by the need to modify core routers to support 
multicast properly, and the resulting reluctance of the ISPs to deploy it.
Perhaps it's time to interpret this as damage, and route around it....?

--
Harald Tveit Alvestrand, [email-masked]
+47 41 44 29 94
Personal email: [email-masked]

---

From: Jon Crowcroft <[email-masked]>
Date: Fri, 20 Oct 2000 08:44:57 +0100

In message <[email-masked]>, Harald Alvestrand typ
 
 >>"start this program on a spare PC, and you too can watch the IETF multicast".

we have reflectors - what we don't have is what we talked about ever
since 1989, which is remote control of a reflector....cu-seeme has
some stuff, but we never generalized it ....

actually , the reason for not allowing auto-setup of a reflector is
the EXACT same reason ISPs dont allow IGMP at the edge  is you get to
get unexpected traffic patterns on your net - normally, a sender can
only send at the rate their access link providers to someone who can
receive at simial rate (basically TCP...) a multicast can send at a
rate 1 receiver can handle, but other receivers joing the multicast
can cause traffic to clobber downstream links so we've been working
for ages to try to devise 
i) adaptive audio/video schemes in avt
ii) tools that tell receivers that they might as well leave a session
in the mmusic wg (e.g. RTP monitoring )
iii) rmt wg protocols that do TCP like congestion control
(e.g. rlc and pgmcc schemes)
etc etc and more flexible models for multicast access (igmpv3)
and routing (ssm etc) to permit ISPs to manage traffic in as similar ways
as they are used to for unicast as possible...

reflectors don't sidestep any of these problems - like NATs and other
intermediaries, appplication level stuff merely introduces another
layer to manage - soem reflectors do transcode data  - these seem
useful - some folks have designed application level multicast boxes
that also do things like access control, content and delivery based
billing, and also use IP multicast where available - all reasonable,
of course, and all part of the Content Distribution Net evolution....

 >>Perhaps it's time to interpret this as damage, and route around it....?

most core/tier-1 ISPs have multicast within the core...they just don't
have general access to it yet......the reasons are partly given above

its gonna change slowly...

actually, a servlet thing for a webcast/multicast/proxy (e.g. on
apache) would be v. cool....maybe we could even support gatewaysing to
netmeeting:-)

 cheers

   jon

---

From: William Allen Simpson <[email-masked]>
Date: Fri, 20 Oct 2000 07:59:11 -0400

> connect to that server, and behave like a multicast router?
It's been done.  I've implemented such in various real time games, 
and Paul Francis gave a nice talk on his YallCast.  What we need 
is a formal standard....   Yet another WG, I guess.

> Perhaps it's time to interpret this as damage, and route around it....?
Yes.  Current multicast doesn't scale.

[email-masked]
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

---

From: Ross Finlayson <[email-masked]>
Date: Fri, 20 Oct 2000 14:22:11 -0700

At 11:37 PM 10/19/00, Harald Alvestrand wrote:
>MBONE tunnels to connect, and a widely available (Linux?) client that 
>would connect to that server, and behave like a multicast router?
>

FYI, a UDP-based tunneling protocol called "UMTP" has been used for several 
years now to tunnel multicast UDP packets over UDP unicast tunnels.  The 
Internet-Draft for this is currently expired, but is online as 
<http://www.live.com/umtp.txt>

One advantage of using UDP/UDP tunneling (rather than IP/IP) is that you 
don't need raw sockets, so people can even run tunnel endpoints on OSs like 
Windows 9x.

There is also server software available (using this protocol) that people 
can use right now to set up multicast-over-unicast tunnels, but it would be 
an inappropriate use of the "ietf" list to say where :-)

         Ross.