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

["Roy, Radhika R." <[e-mail]>]

The example of G.711 codec is NOT exactly right here although some aspects of this are applicable in the DHT argument. A couple of things are as follows:

1.	
	All codecs including G.711 use the same SIP signaling protocol
2.	
	G.711 codec has been used as a reference for all other codecs for interoperability purpose. For example, if audio bridging with multiple different codecs are done, then all of them need to be converted into a single common format, and G.711 is used as a reference common format.

So, if we analyze items 1 and 2 very carefully, it again proves the fact, as David pointed out, we need one standard thing as a reference to start with as follows:

*	Only "one" reference standard for the signaling protocol (in this case it is SIP) to provide interoperability
*	Only "one" reference standard codec that will offer a reference standard format that will be used for inter-operability among different codecs

As such, what is the lesson from the above from standardization point of view when we apply those experiences in DHT standardization?

Is it not what David has pointed out?

Best regards,

Radhika


________________________________

From: [e-mail] on behalf of Eunsoo Shim
Sent: Sat 7/14/2007 11:43 PM
To: Jonathan Rosenberg
Cc: P2PSIP WG
Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion


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 <http://www.jdrosen.net/>                          PHONE: [phone] 
	http://www.cisco.com <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