[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Auto-tunnel Rant
Mike Luby wrote:
> I'm confused by the email that is on these mailing lists. Are we still
> discussing possible standards, or have we moved on to advertisements for
> company products?
I'm just selling my Idea...something wrong with this?
BTW I belong to a research group of a University...not a company and do not
intend to make any money with this.
Bye,
Pieter
>
>
> Michael Luby
> Chief Technical Officer
> Digital Fountain, Inc.
> 600 Alabama Street
> San Francisco, CA 94110
>
> www.digitalfountain.com
> luby@digitalfountain.com
> (415) 401-2100 (main)
> (415) 401-2120 (direct)
> (415) 401-2199 (fax)
>
> -----Original Message-----
> From: Pieter Liefooghe [mailto:pieter@info.vub.ac.be]
> Sent: Friday, March 23, 2001 9:32 AM
> To: Jared Mauch
> Cc: Kevin C. Almeroth; mbone@ISI.EDU;
> mboned@network-services.uoregon.edu; ssm-interest@external.cisco.com
> Subject: Re: Auto-tunnel Rant
>
> Jared Mauch wrote:
>
> > On Fri, Mar 23, 2001 at 07:32:48AM -0800, Kevin C. Almeroth wrote:
> > > Well, I'll add my voice to the rest of the noise. As I see it,
> > > auto-tunneling is fine. Why?
> > >
> > > 1. Let's not get in the business of protecting people from
> > > themselves (in reference to Dino's comment about large
> > > fanout is bad... it is, sure, but who cares?)
> >
> > Those of us who are customers of router vendors (not
> > server/software vendors) have concerns about this impacting our
> > routers should they spend time creating tunnels. large fanout
> > is bad in this case as to get upgrades to the cpu/power in these
> > takes 18 months as compared to the server market that gets a faster
> > cpu every few months and it is easier to add extra machines when it's
> > needed.
>
> That is the idea behind the CastGate proposal, it even allows to distribute
> the
> tunnel end-points over your network....the CastGate client will use - if
> allowed by your policy - the Tunnel server reacheable via the least
> congested
> path!
> I don't need routers in the proposal, I use PC's who are really cheap as
> compared to even basic routers. ;-)
>
> > > 2. Let people run whatever they want in their own cloud.
> > > To force people to only do network-layer multicast is
> > > wrong because:
> > >
> > > (a) You should be able to do whatever you want (See 1.)
> > >
> > > (b) We are in a transition period and not every
> > > single device supports multicast. Until every
> > > single device can handle multicast we need things
> > > like tunneling (any maybe auto-). Why? See 3.
> > >
> > > 3. An infrastructure that has devices that don't support
> > > multicast and so no way for the eyeballs on the other
> > > end to see the content is ultimately defeating for
> > > multicast. Yes we can be multicast advocates, but saying
> > > that someone can't play in our sandbox because they
> > > haven't bought the latest equipment from Vendor X hurts
> > > us more than it hurts the rest of the world.
> > >
> > > In the end: who cares if there is tunneling? or even
> >
> > I don't care about tunneling, unless the burden gets
> > palced on my routers.
>
> As mentioned above, CastGate Tunnel Servers (and Tunnel Database Servers)
> are
> just PC's located in strategic locations in your network.
>
> >
> >
> > > auto-tunneling? Who cares if people expend effort deploying
> > > non-network-layer multicast? If they weren't smart enough in
> > > the first place they probably wouldn't have been smart enough
> > > to deploy multicast anyway.
> > >
> > > NOW... the real question is should the IETF be standardizing
> > > a way to do this? My intuition... NO. Let some clever vendor
> > > sell a piece of hardware or software that makes it mostly
> > > seemless.
>
> I guess, I will just finish building all my components and let it
> loose..(give
> me another month or so)...we will see what happens ;-)
>
> Bye,
>
> Pieter