Subject: RE: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion

From: "Roy, Radhika R." <[email-masked]>
Date: Sat, 14 Jul 2007 23:41:45 -0400

I guess that David has made some excellent technical points: Implementation in Large-scale commercial networks vs. implementations in small lab networks.
 
For example, SIP is yet to provide any meaningful inter-operable standard-based large-scale commercial implementations for multipoint, multimedia conferencing. Had it been the case that we had been in a hurry to standardize SIP based on lab's point-to-point communications only (as multi-point multimedia conferencing using SIP had been difficult to implement in labs environments)?
 
We like to see more solid technical arguments against David's real-world large-scale commericial implementation experiences for using of one standardized DHT to start with.
 
Is it not that we want the economies-of-large-scale using "standarization?"
 
Best regards,
Radhika

________________________________

From: [email-masked] on behalf of David Barrett
Sent: Sat 7/14/2007 7:41 PM
To: 'Henning Schulzrinne'
Cc: 'P2PSIP WG'
Subject: RE: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion

I want running code on a large scale, in the real world, outside the lab.
It doesn't matter what algorithm it uses, how the packets are laid out, etc.
I just want something that solves a real problem for some relevant set of
users, and then I want to iterate.

Thus I have "concrete concerns" with any proposal that deviates from this
goal.  Adding more flexibility to a nonexistent system isn't useful.  Paving
the way for experimental algorithms that might exist on paper or on a few
buddies' computers isn't useful.  Planning for esoteric networking
environments with exceedingly difficult constraints isn't useful.  The only
thing that's useful is running code at a meaningful scale, instrumented in
such a fashion to learn if it works and what needs fixing.

I understand that it might not be exciting to hear my proposals.  "Blah
blah, reality, blah blah, actual users."  It's always more fun to add more
features and more flexibility, but it's not useful (for any meaningful
definition of "useful" that is somehow tied to actual users communicating).

I respect we all come to this forum with our own experiences.  And I'll
grant that others might have experienced success with alternate strategies.
But in my experience developing commercial P2P applications deployed on
hundreds of thousands of active computers around the world, until you have
something that actually does what you want to do -- even if it doesn't do it
great -- any distraction from this goal isn't useful.

So again, I say we pick the best DHT available today, build around that to
the exclusion of all others, and actually ship a product that people can
use.  Then, once people are using it, we'll know what works and what
doesn't, and then we can focus our attention accordingly.

I understand and respect there are other proposals, but this is mine.

-david

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Saturday, July 14, 2007 4:00 PM
> To: David Barrett
> Cc: P2PSIP WG
> Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion
>
> I don't know what beyond actual proposals and running code you'd
> like. Fear-mongering and mentioning demons in the closet isn't going
> to help us. If you have concrete concerns about any of the proposals,
> please describe them. Otherwise, I don't find these generic "it's
> really, really difficult" statements all that helpful in making
> progress.
>
> Henning
>
> On Jul 14, 2007, at 6:52 PM, David Barrett wrote:
>
> > I agree with Bruce: a top priority for P2PSIP 1.0 is to be highly
> > compatible between multple vendor's implementations.  As such,
> > choosing a single DHT seems like a sensible risk reduction -- even
> > if later we decide to change it.
> >
> > And I agree with Henning -- I'm sure there are ways to create an
> > uber-DHT that is algorithm independent.  But it's harder and
> > riskier, and I think that problem needn't be solved today.  I agree
> > it's not magic, but there is a surprising amount of voodoo to get
> > any of this working outside the lab.
> >
> > Overall, I still think this quest for eternal agility and fear of
> > commitment is keeping us from moving forward at all.  I'd happily
> > give up some short-term flexibility if it meant improving the odds
> > of getting *anything* working.  Problems are so much easier to
> > solve when you actually have them, versus when we merely theorize
> > them.
> >
> > -david
> >

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip