Subject: [p2p-sip] Comments to draft-baset-sipping-p2pcommon-00

From: jani.hautakorpi at ericsson.com (Jani Hautakorpi (JO/LMF))
Date: Wed, 10 Jan 2007 17:10:05 +0200

Hi all,

I read your draft draft-baset-sipping-p2pcommon-00 and I didn't quite
get what is the long-term goal of this draft? At the moment it really
doesn't contain a lot of information that wouldn't already be documented
in draft-singh-p2p-sip-00.

However, I liked the title of the draft "A protocol for Implementing
Various DHT Algorithms", because I personally believe that a common
protocol for different DHT algorithm would be useful (and feasible).
Please check my inline comments from:

http://users.piuha.net/jantzgu/temp/draft-baset-sipping-p2pcommon-00-commented.html

-- 
Regards,
Jani Hautakorpi

---

From: 2007 at shudo.net (Kazuyuki Shudo)
Date: Thu, 11 Jan 2007 02:10:53 +0900 (JST)

Hi all,

I have recently subscribe to this p2p-sip list and started looking
over what is ongoing.

> From: "Jani Hautakorpi (JO/LMF)" <jani.hautakorpi at ericsson.com>
> Date: Wed, 10 Jan 2007 17:10:05 +0200

> I read your draft draft-baset-sipping-p2pcommon-00 and
(stuff deleted)

> protocol for different DHT algorithm would be useful (and feasible).

Let me introduce related software. Overlay Weaver implements multiple
lookup algorithms such as Chord, Kademlia, Koorde, Pastry and
Tapestry. Three algorithms (Chord, Pastry and Kademlia) which the I-D
focuses are included.

  Overlay Weaver: An Overlay Construction Toolkit
  http://overlayweaver.sourceforge.net/

Overlay Weaver supports parallel lookups with Kademlia in addition to
sequential lookups, and both iterative and recursive lookups. It
implements multiple service layers, DHT and application-level/layer
multipcast (ALM) over a routing layer while the I-D focues on DHT.

The protocol is algorithm-independent, but dependent on lookup style
(recursive or iterative). A message is serialized Java objects and the
wire format of a message has not been designed, but it is definitely
possible.

> http://users.piuha.net/jantzgu/temp/draft-baset-sipping-p2pcommon-00-commented.html

I will have comments by closer look based on the experience in
development of Overlay Weaver. A few of them are the followings:

Strictly speaking, distance function for Chord is not (b - a) mod
2^M. The distance should be 2^M, not 0 in case that b = a.

In some algorithms, distance function is not requied to perform
lookups. For example, lookup algorithm of Tapestry is described purely
in algorithmic.

Regards,

  Kazuyuki Shudo	2007 at shudo.net		http://www.shudo.net/

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Wed, 10 Jan 2007 13:21:08 -0800

I also like the approach and as mentioned, Bamboo/openDHT should be
included as well. 

Because the proximity neighbor selection of Bamboo can be based on
latency, it is the most preferable IMHO.

Henry

-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Jani Hautakorpi
(JO/LMF)
Sent: Wednesday, January 10, 2007 7:10 AM
To: salman at cs.columbia.edu; hgs at cs.columbia.edu;
eunsoo at research.panasonic.com
Cc: p2p-sip at cs.columbia.edu
Subject: [p2p-sip] Comments to draft-baset-sipping-p2pcommon-00

Hi all,

http://users.piuha.net/jantzgu/temp/draft-baset-sipping-p2pcommon-00-com
mented.html

-- 
Regards,
Jani Hautakorpi
_______________________________________________
p2p-sip mailing list
p2p-sip at cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip

---

From: salman at cs.columbia.edu (Salman Abdul Baset)
Date: Mon, 15 Jan 2007 19:07:05 -0500 (EST)

Thanks. We are in the process of revising the draft and an updated version
will be made available soon.

Bamboo can be considered an offshoot of Pastry. The purpose of including
the description of DHT algorithms is two fold: 1) to highlight
commanalities among various DHTs 2) to show that multiple DHT algorithms
can be implemented by one protocol.

Regards,
Salman

---

From: jiang.x.f at huawei.com (JiangXingFeng)
Date: Wed, 17 Jan 2007 16:34:29 +0800

Hi, Baset:
 I have read this draft.  IMHO, when we design a protocol to be
standardized, we not only standardize the message format of this protocol,
but also define the message exchanges between two protocol entities and
actions taken by the protocol entity when receive different protocol
messages. Given Peer protocol, the message formats could be standardized
like what you have proposed in the draft, but it is hard to standardize the
message exchanges and actions required by protocol entities. For example,
there is different process for Chord and Pastry. If a Node want to join a
Chord overlay, then it send the join message to it's node key's successor
and the successor would reply it with a response, which may include the
route table of the successor and some <key, value> pairs which should be
responsible by the new Node. After doing that, the joining node would start
fix finger and stabilization procedure to keep the route information
correct. But in the case of Pastry, the joining node should get leaf set and
neighbor set from other nodes than the node being responsible for the node
ID in addition to obtain routing table from nodes which are encountered
while the join request are routed through the overlay.  So the join
operation could trigger different message exchanges in each different DHT
algorithm. 
How do you consider the heterogeneity of different DHT algorithms? If the
heterogeneity could not be solved, I am afraid that a general Peer protocol
accommodating various DHT algorithms may not be developed.  It is good that
you could add some content to make me convince that my worries are not
necessary. 

Regards!
--
Jiang XingFeng