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

["Eunsoo Shim" <[e-mail]>]

I agree that it should be the market that drives the choice of the DHT
algorithm eventually.

On the other hand, currently no specific DHT algorithm has been established
as a widely accepted one for P2PSIP overlays. So I am wondering what DHT
algorithms a manufacturer would implement if they implement P2PSIP nodes.
And if manufacturers choose all kinds of variations of various DHT
algorithms, it will give significant headache and limited choices of devices
to even large service providers, not to mention smaller ones and enterprises
who like to use multi-vendor solutions.

The SIP community did not have to recommend or choose any voice codec. Other
organizations developed various voice codec standards and there were widely
accepted voice codecs such as G.711. So it was not much of an issue what
voice codec should be implemented or selected for SIP devices. The situation
with DHT is different in my understanding. There are too many options and
one can easily try to tweak a known DHT algorithm.

I am not aware of any standardization body or industry organization that is
working to define any standard DHT.

I believe at least some kind of recommendation on DHT algorithms, if not a
mandatory implementation requirement, would help a lot.

If the P2PSIP community does not produce it for P2PSIP overlays, who would
do it?

Thanks.

Eunsoo



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
>

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