Subject: RE: MBONE access?

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 3 Mar 2004 17:44:29 -0800

> > Equally flawed and useless are the H.323 protocols that do not
> > tunnel through NAT or even work with a firewall in a remotely 
> > acceptable fashion.
> 
> NAT is the big bad dog here, that is what breaks the
> end to end connectivity. <restart NAT war />

In case you had not noticed there are now tens of millions of NAT
devices in use. End users are not going to pay $10 per month for
an extra IP address when they can connect unlimited numbers of 
devices to the net using a $40 NAT box.

The NAT war has been over for years, NAT won. The problem is that
the IETF still has not come to terms with that fact.

The Internet was designed to be a network of networks. The core
architecture is NOT end-to-end, that is a political shiboleth that
has been imposed later.

The features of the Internet that work are the ones that work within
the end-to-end model. The features that are failures are the ones
where the end-to-end model is bogus.

The security world has long since realised that exclusive relianance
on end-to-end security is bogus. I don't know of any serious security
professionals who now claim that firewalls are bogus or that they 
will go away as the myth has it. Perimeter security is here to stay.

In the case of H323 the problem is not just NAT, it is the derranged 
protocol which uses a block of 3000 odd TCP/IP ports to receive
messages on. there is no way that this is consistent with good
firewall management - unless you go to some pretty sophisticated 
additional control to open up and shut down the ports as required.

As for IPv6, the only feasible way to deploy it is by co-opting those
NAT boxes.

		Phill

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Thu, 4 Mar 2004 11:05:28 +0900

Most of the NAT boxes allow you to use IPv6. There are several protocols that allow it.

The simpler one http://www.rfc-editor.org/cgi-bin/iddoctype.pl?letsgo=draft-palet-v6ops-proto41-nat-03

Regards,
Jordi

----- Original Message ----- 
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "'Jeroen Massar'" <[email-masked]>; "Hallam-Baker, Phillip" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, March 04, 2004 10:44 AM
Subject: RE: MBONE access?

> As for IPv6, the only feasible way to deploy it is by co-opting those

**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Ole Jacobsen <[email-masked]>
Date: Wed, 3 Mar 2004 18:30:31 -0800 (PST)

<begin naive question>

Apart from the "eating our own dogfood" bit ...

Most other Internet events I attend, or follow remotely, use Real
audio/video, or sometimes Windows Media Player.

Can anyone tell me if there are any TECHNICAL reasons why we can't
do this for the IETF meetings?

Ole

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

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Thu, 4 Mar 2004 11:38:20 +0900

Agree. I didn't wanted to mention specific brands before, but we use Windows Media Server for our own events (www.ipv6-es.com), and it works very well (with IPv6 support)

I volunteer to help if needed.

Regards,
Jordi

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 04 Mar 2004 11:45:32 +0900

In message <[email-masked]>, Ole Jacobsen wr
>do this for the IETF meetings?

Does Windows Media Player run on a high-enough percentage of IETFers 
machines?  The incidence of Windows here is considerably lower than in 
the population as a whole.  Note that this is a technical reason:  it 
doesn't support our user base.

		--Steve Bellovin, http://www.research.att.com/~smb

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 3 Mar 2004 18:51:33 -0800 (PST)

> do this for the IETF meetings?

how about economic and poltical... 

In point of fact it has been done, either by reflecting sources to 
unicast through real servers or by simply generating additional sources. 
The resources to do this on an ongoing basis (namely transit) haven't been 
forthcoming.

joelja

-- 
-------------------------------------------------------------------------- 
Joel Jaeggli  	       Unix Consulting 	       [email-masked]    
GPG Key Fingerprint:     5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2

---

From: Paul Vixie <[email-masked]>
Date: 04 Mar 2004 03:30:44 +0000

> Apart from the "eating our own dogfood" bit ...

apart from that, we should all stay at our desks and use DECNet-PhaseV
or NetWare to get our work done, and stop trying to create new protocols
that are robust, interoperable, and open.

in other words there is a big nothing "apart from" that particular thing.

the fact that realmedia and windowsmedia aren't interoperable means that
we (this community) failed to recognize and address a common need, and
that the world (including this community) is suffering for it.

compounding this failure by adopting proprietary technology for the primary
work of this community -- which is interior and published communications --
would be a bad, bad (bad) thing.
-- 
Paul Vixie

---

From: Ole Jacobsen <[email-masked]>
Date: Wed, 3 Mar 2004 20:17:04 -0800 (PST)

Actually, the use of Windows Media Player is quite rare for the events I
am talking about, Real is probably used in 90% of them, I only mentioned
the other one because it does appear from time to time. Note that Real
Player is available for multiple platforms for free, and so is Windows
Media Player, I have one for the Mac for example.

Ole

Ole J. Jacobsen

---

From: Ole Jacobsen <[email-masked]>
Date: Wed, 3 Mar 2004 20:24:13 -0800 (PST)

Paul,

This is simply silly.

What you are saying is that for religious reasons you are unwilling to use
FREE and widely used tools in order to help us develop our own.

Next thing you'll be telling me PDF is a bad thing.

If you want the IETF to be a place where more people can participate you
need to ditch some of this religion.

Ole

Ole J. Jacobsen

---

From: Paul Vixie <[email-masked]>
Date: Thu, 04 Mar 2004 05:05:59 +0000

> What you are saying is that for religious reasons you are unwilling to
> use FREE and widely used tools in order to help us develop our own.

well, actually, that's not what i said at all.

> Next thing you'll be telling me PDF is a bad thing.

and no, that won't be the next thing i'll tell you.

> If you want the IETF to be a place where more people can participate
> you need to ditch some of this religion.

if there were no robust open alternatives i'd be the first to say
"issue an rfp."

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 3 Mar 2004 21:14:35 -0800 (PST)

> FREE and widely used tools in order to help us develop our own.

The focus in clients is a little misguided... 

There's a reasonable cross-section of clients for most platforms the
supports a set of mostly interoperable codecs and transports. It is
possible to source with real/darwin streaming server/videolan a source
that will be visbile to users of quicktime/real/vlc and some other clients
via multicast or unicast transports. In order to do that you have to be
somewhat selective about which codecs, and features you use.

The transport is an issue. 500Kb/s isma mpeg-4 streams have a real cost if 
you want 200 of them... 

If you want variable-rate codecs that support clients at an number of
rates simultaniously you may have to forgoe interoperabilty in favor of a
single client platform. If you want slides and video in seperate windows
you need smil but there are no interoperable smil implementations.

The thing I consider most unworkable frankly is low-bitrate video... I 
don't consider a 40 80 100Kb/s streams terribly usable regardless of the 
codec chosen, I want to be able to read the slides, I want to be able hear 
the speakers from someplace other than the bottom a barrel and I want to 
be able to discern who's standing at the mic.
 
> Next thing you'll be telling me PDF is a bad thing.

I have deep ambivalence towards pdf but that's a seperate issue for a 
different forum.

---

From: Ole Jacobsen <[email-masked]>
Date: Wed, 3 Mar 2004 21:23:34 -0800 (PST)

Paul,

As has been pointed out, this is a little more complicated than just
the choice of client, in particular multicast is not widely available
to the "average" Internet user.

But I still find it ironic that I can watch a webcast from an ICANN
meeting but I am unable to do the same for an IETF meeting (until after
the fact). That is but one example.

Ole

Ole J. Jacobsen

---

From: Paul Vixie <[email-masked]>
Date: 04 Mar 2004 05:50:54 +0000

> to the "average" Internet user.

that could be punctuated very differently and thus become even more factual.

> the fact). That is but one example.

well, let's do what we always do, then... have a BOF about it.  we can wire
a 1394 camera to jabber somehow, but until there's widely deployed idmr or
a whole lot of widely deployed open/shared L4 streamsplitters, this won't
be a protocol problem (like it ought to be).

for dark humour value, i note with dispair that in 1992 when i participated in
a project at DEC (r.i.p.) to move the nasdaq trading system onto tcp/ip, we
were told by several people that "ya oughta use multicast".  my part of the
project was an L4 streamsplitter that was used because multicast didn't work.
folks told us that we'd regret it and have to tear it out in a year or two
when multicast became widely deployed.  someone, somewhere, is probably still
using "DECrbs" because for them, multicast still isn't a realistic possibility.
-- 
Paul Vixie

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Thu, 4 Mar 2004 15:14:09 +0900

Yes, even there are other interoperable implementations for Linux and BSD based platforms.

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Thu, 4 Mar 2004 15:15:49 +0900

Well we can use tools like Helix that combine Multicast, Real and Windows Media, I believe, into a single platform, so any kind of client can access it.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 04 Mar 2004 16:08:39 +0900

Ole,

the multicast services are provided by the UOregon team supported by a 
grant from Cisco (+ some support from ISOC via the IETF Chair's fund).

This grant is in its final year, and the end of the grant is a convenient 
time to stop and reconsider exactly what services we (the IETF community) 
want in the area of A/V at meetings, and see how we can arrange to have 
that done, and cover the costs.

So yes, it's on my list of things to worry about - it's just not at the 
top......

                       Harald

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 4 Mar 2004 10:53:07 +0100

On 4-mrt-04, at 6:14, Joel Jaeggli wrote:

> via multicast or unicast transports.

Right. And unless I'm mistaken, streaming servers will happily take 
either a unicast or a multicast feed and reflect this feed over one of 
several transports (including some that will bypass NAT).

> The transport is an issue. 500Kb/s isma mpeg-4 streams have a real 

That's 100 Mbps. There are a lot of outfits that care about the IETF 
for which 100 Mbps is small change. (The latest episode of the Steve 
Jobs Show had 60,000 people watching at 300 kbps...) And 200 x 24 kbps 
audio only is just 5 Mbps, which would even be doable from the meeting 
site. A reasonable charge to cover the costs for online participation 
wouldn't be out of the question either, IMO.

> be able to discern who's standing at the mic.

Our little multi6 experiment taught me that low quality video indeed 
isn't all that useful, and goood quality video isn't simple. However, 
workable quality audio is both simple and useful. So if good video 
can't be done, forget about it altogether and do audio only. If the 
speakers get in the habit of putting their slides online before a 
session and either they or the jabber scribe say which slide is up, 
that part is covered.

Another option would be "slow scan tv": rather than stream relatively 
low quality moving video, why not send out periodic high quality 
stills? The advantage here is that there is no set rate at which those 
have to load so there is no binary good/none quality problem as with 
streaming.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 4 Mar 2004 13:37:39 +0100

> devices to the net using a $40 NAT box.

Sounds like a conspiracy... ISPs charging orders of magnitude more than 
cost for additional addresses "forcing" people to use NAT.

> the IETF still has not come to terms with that fact.

I don't think anyone has won here, there are just casualties all over 
the place: more work for the IETF and vendors, less functionality for 
the users.

> architecture is NOT end-to-end, that is a political shiboleth that

Suppose for the sake of argument that the above is a valid position, 
and that we would actually want to make NAT work. What we need to do 
then is extend it such that it becomes possible to address hosts behind 
a NAT from the public internet. That should be perfectly doable, in 
essence we'd be redefining the protocol and port numbers to be part of 
the address. However, this means these must now also be put in the DNS 
and in most other places where IP addresses show up. So this adds up to 
a HUGE amount of new work.

Guess what: we already did pretty much the same thing with IPv6. The 
logical conclusion here is that we can save a lot of time and effort by 
simply adding IPv6 to the mix, as it is just a hair shy of being ready 
for full deployment, while all this stuff to make NAT actually work is 
all over the place.

> firewall management

So now you are complaining because after you install a firewall, it 
turns out the thing does its job? The whole idea that decent security 
can be had by allowing packets with certain port numbers in them in and 
not others is fatally flawed, as it just makes for an arms race between 
firewall vendors that inspect deeper and deeper into packes and 
firewall bypass utilities that tunnel the real protocol through more 
and more layers of accepted protocols.

What we need is "corporate zone alarm" like functionality, where 
firewalls get to see which applications (and users) are trying to 
communicate with the outside world, rather than guess based on the port 
number in the packet. This would allow some very nice features such as 
blocking vulnerable versions of applications but allowing patched 
versions of the same application.

---

From: "Robert G. Brown" <[email-masked]>
Date: Thu, 4 Mar 2004 08:49:23 -0500 (EST)

> need to ditch some of this religion.
...
> > would be a bad, bad (bad) thing.

This is not silly, it is just smart in a longer timeframe than you're
thinking in.  Proprietary tools that utilize a proprietary/non-open data
interface are a serious problem for a variety of very sound,
non-religious reasons (as well as for a variety of political and
economic reasons, which is what I think you're calling "religious"
reasons).  "Free" is irrelevant to the issue, unless free means open.

   1) Proprietary data formats and long term archiving of any sort of
data are fundamentally incompatible.  Ask anybody who has lived through
the last twenty or thirty years of computer evolution how many documents
they've lost or had to go in and rescue (sometimes at great expense) as
the tools they were built with have disappeared.  Sometimes along with
their vendors.  Other times the vendors simply decided to release a new
version that was sufficiently incompatible that it could no longer
manage the old documents.  I think all of us can remember multiple
instances where this has happened to us -- I personally have lived
through wordstar, pcwrite, wordperfect, word, and several income tax
programs (which are the worst, as one HAS to be able to access the
records up to seven years later, which is a real problem with operating
systems and Moore's Law). There is also the uncertainty even now
surrounding the "encumbered" mp3 format versus e.g.  the unencumbered
ogg format.

Formats used to encode long-term public records need to be open and
tools to manage those records need to be available from many sources.
So putting up realmedia shows is short-run glitzy and nifty and all that
(even though lots of people won't have the players and cannot play the
media) but it is long run foolish IF the production is intended as any
sort of serious historical or archival record.

   2) Using a proprietary data format that can only be accessed by using
a proprietary tool (even a "free" one) leaves one vulnerable to all
sorts of shenanigans and hidden costs.  For example, nothing prevents
the vendor from waiting until you have a large amount of valuable data
built up with their format that would be very expensive to convert and
then deciding to charge you.  It's their tool, they can charge you if
and when they please.  Worse, since their tool is generally a closed
source, proprietary object, there are the usual problems with libraries
and compatibility when trying to get the tool to run on the wide range
of platforms it is advertised for.  "Free" may just refer to the cost of
getting the program, but it may well cost quite a bit of time to install
and maintain it, and time is money.

  3) The Internet has been built on open standards from the very
beginning.  This is absolutely the key to its success and tremendous
degree of universality and functionality to this very day.  Any vendor
can build a mail tool, an ftp tool, a tool using TCP/IP as a transport
layer.  Any vendor can build a browser, an http daemon.  The
specifications for those tools are laid out in RFCs, and modifications
to the open standards proceed in a serious and systematic way.  The
Internet has RESISTED being co-opted by monopolistic vendors who have
sought to introduce their own proprietary and "essential" layer of
middleware on hidden protocols, although they continue trying. The DMCA
makes it quite possible that if they ever succeed it will be
tremendously expensive and damaging to the entire structure.  You can
call this a "religious" argument if you like, but I think it is really a
statement of both politics and economics, in this case the politics of
freedom and the economics associated with having lots of choices.

So I'm afraid that I agree with Paul 100% on this one (although I
respectfully disagree with him on others;-).  The IETF absolutely should
avoid using proprietary tools to create documents that they might wish
to archive, and should strongly encourage the development of open
standards for and open document formats (one data format, many tools
both free and non-free) for data transmission on the Internet to ensure
that the Internet NOT be co-opted by any single vendor and that records
that might be archived today can still be accessed ten or twenty years
from now without finding a DOS PC and a 5.25" floppy drive to reload an
ancient piece of software.

Or am I alone in think that this would be a Bad Thing?

   rgb

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:[email-masked]

---

From: Frank Solensky <[email-masked]>
Date: Thu, 04 Mar 2004 10:16:11 -0500

A nit, perhaps, but:

On Wed, 2004-03-03 at 20:17 -0800, Ole Jacobsen wrote:
> ..Note that Real
> Player is available for multiple platforms for free, ..

The Linux version, last I tried [8.0.3.412], didn't include support for
multicast.

---

From: Daniel Senie <[email-masked]>
Date: Thu, 04 Mar 2004 10:30:06 -0500

>The resources to do this on an ongoing basis (namely transit) haven't been

On the economic front, there have been offers, at least from me, to PAY for 
remote attendance. Let's face it, I'd have been happy to pay $500 to have 
access to all WG sessions and plenaries via Real Player or other Unicast 
mechanism in Seoul. There's just no way my company can afford the travel 
expenses for me to personally travel to Korea.

The IETF should be interested in individuals, not just large corporations, 
participating. What better way than to provide a way for individuals to 
attend on their own budgets? If that means virtual attendance, then so be it.

Multicast is just not available to many of the folks who might otherwise 
attend. I don't care what unicast mechanism is chosen, provided it allows a 
wider crosssection of the community access to live participation in the 
meetings.

---

From: [email-masked]
Date: Thu, 04 Mar 2004 10:56:27 -0800 (PST)

> expenses for me to personally travel to Korea.

I too would have no problem paying for this.

> attend on their own budgets? If that means virtual attendance, then so be it.

Exactly right.

> wider crosssection of the community access to live participation in the

The choice of unicast technology is largely irrelevant to me as well. While I
might find one approach somewhat more advantageous than another at this
particular point in time, if something is chosen I will take the necessary
steps to get it working. The same cannot be said for multicast, since no amount
of my own futzing will make it work for me.

				Ned

---

From: Ole Jacobsen <[email-masked]>
Date: Thu, 4 Mar 2004 14:53:05 -0800 (PST)

Right, but multicast appears to be a large part of the problem.

I know this is heresy, but good engineers are usually able to use
available tools. It is possible to use the handle of a screwdriver to hit
the head of nail and drive it into the wall --- when you don't have a
hammer.

Now, it was a *naive* question, and others have pointed out the cost
of unicast alternatives, so I am not saying "adopt commercial solutions
today", but if we are only doing multicast for religious reasons AND
it isn't reaching the large group of people who cannot participate
THEN it might be time to consider some alternatives, that's all.

Ole

Ole J. Jacobsen

---

From: James Seng <[email-masked]>
Date: Sat, 06 Mar 2004 09:44:48 +0800

Ole didn't say Realplayer supports Multicast. He is asking why we can't 
use Real stream (or something along that line) instead.

FYI, I didnt get mbone since 1995 when I stop working for an ISP. I have 
managed to get any of my current ISPs to get it either. It is time we 
have to admit mbone is not going mainstream.

ps: https://helixcommunity.org/ - Real player (or at least Helix, the 
Open Source version of it) is available on multiplatform.

-James Seng

---

From: Paul Vixie <[email-masked]>
Date: 06 Mar 2004 06:22:05 +0000

> have to admit mbone is not going mainstream.

today shep reminded me that we (shepfarm and isc, with help from cisco,
juniper, procket, verio, and a cast of others) are supporting some number
of mbone-like tunnels designed to glue otherwise disconnected "walled gardens"
together, with touchdowns on fix-west, paix-sfba, and equinix-sj.  naturally
there'll be pressure toward (and aid offered toward) "going native", but
other than that these tunnels are free of cost.  "We *Can* Fix This."

> Open Source version of it) is available on multiplatform.

if that increases the market for realnetworks' proprietary server-side
products, and if realnetworks is still doing absolutely no confirmation
on e-mail addresses they send bulk e-mail to, then i'll probably continue
to boycott that application suite, no matter how free the players are.
-- 
Paul Vixie