[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