Subject: RE: MBONE access?

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 3 Mar 2004 15:23:49 -0800

> I'm all for eating our own dog food, but IMO workable remote 
> access is more
> important.

The point about eating the dog food is so that you improve it
to the point where it is acceptable.

I think it is time to accept that the MBONE technology is
fatally flawed and is not going to be deployable.

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.

This thing is not rocket science. There are lots of folk
with the little cameras and the ISPs do not want to have
their bandwidth wasted needlessly. But trying to do multicast
in the network layer has failed. The Internet considers 
complexity in the network to be stupidity and does not route
it.

		Phill

---

From: "Jeroen Massar" <[email-masked]>
Date: Thu, 4 Mar 2004 02:08:48 +0100

-----BEGIN PGP SIGNED MESSAGE-----

> tunnel through NAT or even work with a firewall in a remotely 

NAT is the big bad dog here, that is what breaks the
end to end connectivity. <restart NAT war />
 
> complexity in the network to be stupidity and does not route

Simple solution: IPv6 tunnelbrokers that provide multicast connectivity.
2 bonuses in one go:
 - IPv6 connectivity, thus anything becomes end-2-end.
 - IPv6 Multicast connectivity, also to IPv4 using the gateway.

Then ISP's only need to upgrade their core network and can
leave the access part as what it is. But fortunatly that
is not protocol and thus has nothing to do with ietf ;)

Greets,
 Jeroen

---

From: Dean Anderson <[email-masked]>
Date: Wed, 3 Mar 2004 22:55:03 -0500 (EST)

> fatally flawed and is not going to be deployable.

There is nothing wrong with Mbone, per se--though, as someone mentioned,
it might be nice to have better codecs. The problem is that multicast is
flawed, and not going to be globally deployable. It will be useful perhaps
to the large organization that has a potential for multicast. But it
certainly isn't useful in any potentially "hostile" environment.  To abuse
some more buzzwords, multicast is not a "global"  technology. Its more an
"enterprise" technology. Or, as MBone is today, arranged as tunnels to
participating and interested organizations.

> tunnel through NAT or even work with a firewall in a remotely 

There is nothing wrong with h323.  There are good reasons for the IP
address of the client to be embedded in some h323 control messages.  In
most cases, this is a good thing, and an advantage for call control and
call routing systems.  Indeed, this is what gives h323 its scalability and
ability to compete and work in tandem with the PSTN.  But when passing
through a NAT, those addresses and port numbers have to be properly and
statefully translated---That's what a proxy does.  The problem is that
your NAT doesn't (or most likely, /didn't/ until the last year or two or
three) support h323 proxy.  You need h323 proxy support just like you need
proxy support for many non-trivial protocols.  Either upgrade your NAT
software, or if you run linux/bsd/etc, install an open source h323 proxy
on your NAT gateway.

> complexity in the network to be stupidity and does not route

Perhaps.  But it didn't fail because it was too complex. "Failed" probably
isn't the right word. "Adopted" or "Allowed" are probably more
appropriate.  It isn't allowed by ISPs because it isn't suitable to the
environment.  It may be allowed by cooperating organizations, which have 
to create tunnels between them. I don't a big problem with that.

		--Dean

---

From: shogunx <[email-masked]>
Date: Wed, 3 Mar 2004 18:27:42 -0500 (EST)

So we are still faced with the question of how to deploy multicast to the
end user.  Sad.  I have two circuits running into my home office, and both
providers (one a major telco) are so cranially-rectally inverted that they
have no clue what multicast is much less how to deploy it.

What does it take, someone to go to berkeley and hack a server onto the
network to act as a tunnel broker?

Scott

> to create tunnels between them. I don't a big problem with that.

sleekfreak pirate broadcast
http://sleekfreak.ath.cx:81/