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

["David A. Bryan" <[e-mail]>]

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