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

["Krishna Sankar \(ksankar\)" <[e-mail]>]

David,
	I assume by "pluggable DHTs" you mean common interface and
protocols. 

	Supporting your line of thought, as I understand them, basically
if we have a model which says a DHT should do this thing, that thing and
all those (well defined) things; plus a way of interacting with DHT
instances (via well established and crisp protocols), do we care how the
DHTs are implemented ? In fact, isn't this how routing works ?

> to implement, there may be many devices from different 
> vendors that don't even implement a common DHT. Each will 
> pick and choose which DHTs to implement, and in the end, 
> there won't be a common DHT all can even run if they want to.
<KS>
	Wouldn't a device implement only the protocols and interfaces ?
In fact, depending on the domain, we might need different types of DHTs
anyway. I am not sure one size will fit all domains for various reasons
- for example there might be a need for power saving; in which case that
domain might choose a lightweight DHT implementation; Apple definitely
will want to have an iDHT for no reason ;o),... 
</KS>

Also, I keep on seeing interoperability thrown around; interoperability
has different forms in different domains - as Medhavi mentions, in the
codec world what it means is different than in the routing world which
is different than in the SAML world, for example. In short what exactly
is interoperability in the world of P2PSIP ? I think if we have a clear
& common understanding of the definition of interoperability, that would
be a good start; we all have it in our heads, may be it is written down
somewhere.  

Cheers
<k/>
> -----Original Message-----
> From: David A. Bryan [mailto:[e-mail]] 
> Sent: Friday, July 13, 2007 3:16 PM
> To: Jonathan Rosenberg (jdrosen)
> Cc: P2PSIP WG
> Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a 
> dissenting opinion
> 
> I think this likely to be a source of serious discussion. At 
> least for now (maybe Jonathan can convince me), I'm inclined 
> to disagree.
> 
> I think the problem is that if we don't specify a mandatory 
> to implement, there may be many devices from different 
> vendors that don't even implement a common DHT. Each will 
> pick and choose which DHTs to implement, and in the end, 
> there won't be a common DHT all can even run if they want to.
> 
> I think looking at it from the perspective of "once the DHT 
> chosen it is locked" is the wrong way to look at it. The idea 
> isn't that any device can join any already established 
> overlay, but that if I deploy a system of heterogeneous 
> devices, there is at least one that I can select when I start 
> and know that all "P2PSIP endpoints" (assuming that term 
> means anything) will at least support that and I can form an 
> overlay with them. Maybe not the ideal DHT for my overlay, 
> but something I know all devices can support, and if I run it 
> in that mode, it works.
> 
> Personally, I think if we don't do that, many DHTs will be 
> standardized for different environments (good) but each 
> vendor will implement a (potentially disjoint) subset, and 
> there may be no way to use two endpoints from different 
> vendors together at all.
> 
> I agree that if a user selects a non-mandatory DHT, they may 
> risk not being fully interoperable, but I think if we don't 
> pick one at all, we almost guarantee things won't be interoperable.
> 
> And I (and I think nearly everyone) is 100% in the camp of 
> "we should allow pluggable DHTs". I think it is safe to say 
> that one is a done deal, but I would personally have thought 
> a mandatory was as well. In any case, my vote is definitely 
> for pluggable DHTs.
> 
> David
> 
> On 7/13/07, Jonathan Rosenberg <[e-mail]> wrote:
> > I've read draft-bryan-p2psip-requirements-00, and have a bunch of 
> > comments. But a few items came to mind I wanted to discuss 
> which merit 
> > their own threads.
> >
> > First, is the concept of mandatory-to-implement DHT. The 
> requirements 
> > document talks a lot about requirements around selecting a 
> mandatory 
> > to implement DHT. Its something we've discussed in the 
> meeting and on 
> > the list. I think everyone agrees also that we need to allow for 
> > multiple DHT and all of the recent protocol proposals support it.
> >
> > However, I do not think we should have a 
> mandatory-to-implement DHT at all.
> >
> > There are several reasons for this. First of all, its important to 
> > understand the reason why IETF has mandatory-to-implement 
> > functionality in its protocols. The one and only reason is that it 
> > ensures interoperability. It ensures that, independent of 
> the optional 
> > features selected by a pair of entities, when you connect them 
> > together, they can still interoperate.
> >
> > This property will NOT be retained with a 
> mandatory-to-implement DHT.
> > Once the ring forms, the DHT protocol is chosen and locked. 
> Thus, if any
> >   DHT besides the 'mandatory-to-implement' one has been 
> selected for 
> > the DHT, a new node not supporting that DHT will not be 
> able to join 
> > the ring even if it implements the mandatory-to-implement 
> one. Thus, 
> > the entire purpose of mandatory-to-implement is eliminated 
> - we don't 
> > actually get interoperability.
> >
> > Indeed, to get this kind of interoperability, we'd need to pick one 
> > and only one DHT that ever gets used with p2psip. I think 
> that is a mistake.
> > This is an evolving area and is one where agility is important.
> >
> > Instead, what I think happens is that a 'provider' that 
> deploys a p2p 
> > network will need to pick a DHT, and make sure that the clients all 
> > support that DHT. This is something the market should drive, not us.
> >
> > Secondly, I think its important to realize that we are 
> picking up work 
> > in an area that is well trod. There are lots and lots of papers and 
> > protocols and software written around P2P networks. I don't think 
> > anyone looks at an IETF protocol and says, "IETF are the 
> guys who know 
> > about DHTs, lets go with their recommendation". What IETF is really 
> > good at, and what this group has expertise in, is SIP, and on 
> > designing good, scalable protocols in general - things that have 
> > security, extensibility, good performance, and so on. So I 
> think the 
> > greatest value we can bring to the table is to create a 
> protocol that 
> > allows others to take DHTs and easily turn them into a real wire 
> > protocol that you can actually deploy, on the Internet, to 
> support SIP 
> > and ideally other things too. Interestingly, this is 
> exactly what all 
> > of the protocol proposals do. That kind of focus goes hand-in-hand 
> > with saying, let someone else figure out which DHT to use. 
> I think its 
> > perfectly reasonable for us, and for others, to write 
> documents on how 
> > to use our protocol with various DHTs. But I think we 
> should be out of 
> > the business of picking one or recommending one (or ones) 
> to be used.
> >
> > -Jonathan R.
> > --
> > Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> > Cisco Fellow                                   Parsippany, 
> NJ 07054-2711
> > Cisco Systems
> > [e-mail]                              FAX:   [phone]
> > http://www.jdrosen.net                         PHONE: [phone]
> > http://www.cisco.com
> >
> > _______________________________________________
> > P2PSIP mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/p2psip
> >
> 
> 
> --
> David A. Bryan
> [e-mail]
> +1.757.565.0101 x101
> +1.757.565.0088 (fax)
> www.SIPeerior.com
> 
> _______________________________________________
> P2PSIP mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/p2psip
> 

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