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

["Henry Sinnreich" <[e-mail]>]

Henning Schulzrinne wrote:

>Lack of a common DHT does not necessarily interfere with  
>interoperability. The client protocol, at least in our thinking, is  
>independent of the DHT, so a node that doesn't implement the DHT  
>algorithm of the overlay it wants to talk to can still reach others,  
>it just can't be a full peer.

Can we interpret this as an endorsement of the client protocol and/or
another argument in its favor?

Thanks, Henry

-----Original Message-----
From: Henning Schulzrinne [mailto:[e-mail]] 
Sent: Friday, July 13, 2007 5:02 PM
To: David A. Bryan
Cc: P2PSIP WG
Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion

Lack of a common DHT does not necessarily interfere with  
interoperability. The client protocol, at least in our thinking, is  
independent of the DHT, so a node that doesn't implement the DHT  
algorithm of the overlay it wants to talk to can still reach others,  
it just can't be a full peer. Since typically only a small fraction  
of nodes need to act as peers at any given time, this may not be much  
of a problem.

You could design a system that essentially replicated the key-data  
mappings across two DHT algorithm, a baseline universal one and the  
"fancy"/"better" one less universally spoken. This incurs  
significantly more overhead and probably yields some strange partial  
reachability cases particularly as new nodes are added, but it could  
be done.

Henning

On Jul 13, 2007, at 6:16 PM, David A. Bryan wrote:

> 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

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