Subject: [P2PSIP] Comments on draft-baset-p2psip-p2pcommon-01 Attn: Baset/Schulzrinne

From: [email-masked]
Date: Sun, 1 Apr 2007 18:50:10 +0530

Comments on draft-baset-p2psip-p2pcommon-01
-----------------------------------------------
1. I had gone through this draft and currently implementing the same.
It covers most of the aspect except that there are some more methods
to be defined and some corrected as given below.

Comments on the draft
-----------------------------

i) On Peer-Lookup, it is stated that "A peer MAY send a Peer lookup message
to update its routing or neighbor table entries".

From the above statement, i understand that a Peer P1 issues  Peer-Lookup
message to another Peer P2. On receiving the Peer-Lookup response from P2,
P1 updates its routing/table based on the Peer-Lookup response.
Is the above understanding correct?

There is also an Update message defined. "It states that A peer sends an
update request to another peer to request a copy of its neighbor or routing
table peers".

What is the significance of this method?. Peer-Lookup method serves the
same purpose.

Clear differentiation between Peer-Lookup and Update is not made.
Both Peer-Lookup and Update message is sent to obtain details
of a Peer's routing/neighbour table.

ii) The Update request and response [Page 29] parameters does not match with the
call flows provided. In the call flow [Page 69] Update request contains routing table
where as Update response does not contain routing table in contrast to the
description and parameters provided in Page 29.

So i guess, Update request is to indicate another Peer to update its routing table.
i.e., P1 send Update request to P2, so that P2 updates its routing table.
The description and parameters on page 29 has to be corrected.

Enhancements required to the protocol
-------------------------------------

Considering an implementatin of Chord as DHT, there are not sufficient or efficient messages
to achive overlay management. For example, consider the case that P2 wants to join an overlay
and P1 is the only node currently in the overlay. (P1 is both bootstrap and admitting node
for P2).

The sequence of actions are as follows (P2 joins P1 overlay).

P2 sends join request to P1 ( to join the overlay).
P1 accepts and sends join resp to P2.
P2 has to update its routing table. For this it queries P1 and constructs its routing table.
P2 indicates other node that it has joined the overlay.
P2 has to share some of the resources of P1.

One of the call flow scenario to achieve the same is that

(a) Lets say P2 has to construct its finger table. While doing so P2 has to repeatedly send
P1 Peer-Lookup as it wants to know the successor of each key of its finger table.
The number of rows depends on the hash-key size bits used and hence lot of Peer-Lookup
messages has to be sent.

(b) As part of resource sharing, P2 wants to take some of the resources of P1. There is no
method directly to take some resources from P1 by P2.
Currently the Resource-Replicate is to be used. However in this case, resources shall
be replicated and will not be removed. A separated Remove request has to be sent.

A simple joining mechanism would result in lot of P2PP messages exchanged between joining
and bootstrap/admitting node.

We are on the design of a prototype of P2PSIP overlay node based on the architecture
provided by draft-hautakorpi-structure-of-p2psip-node-00. If you are interested i can
send the call flows for overlay management. Might be when this protocol was written, the
intent of a method was different from what is being currently used in the draft. If so
this can be corrected, please let me can i share this call flow.

Another thing to be considered is whether to use TCP/UDP and iterative/recursive routing.
This draft fails to analyse the pros and cons of this. It used both TCP/UDP simulataneously
based on message size. This is not a good approach.

For e.g, lets say recursive routing is used in TCP, in this case, P1 sends message to P2, P2 sends
to P3.. and so on... and the response would reach P1 after traversing P3, P2 etc. The transction
would have timed out at P1, but still the message goes on with in the overlay until TTL is zero.

We are almost done with the implementation of this protocol which we are planning to use for
our prototype of SIP overlay node. If interested i can share the source code too.

Thanks & Regards,

Anuroop.

*****Aricent-Unclassified *****=

"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of
the individual to whom it is addressed. It may contain privileged or confidential information and should not be
circulated or used for any purpose other than for what it is intended. If you have received this message in error,
please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for
loss or damage arising from the use of the information transmitted by this email including damage from virus."

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

---

From: Salman Abdul Baset <[email-masked]>
Date: Mon, 2 Apr 2007 13:17:31 -0400 (EDT)

Hi Anuroop,

>    Comments on the draft

Consider a DHT where a node may want to obtain routing table of its
successor. This is accomplished using Update request. Peer-Lookup is not
necessarily required in this scenario.

In general, Update is used when the peer is already known. i.e., it does
not need to be 'looked up'.

>        The description and parameters on page 29 has to be corrected.

The reason there is no routing-table in Update response (message # 10) is
because the join request had set request-routing-table
and in-seperate-request flags in the Request-Options object. Nodes
that receive a request with these flags set wait for a random period of
time and then send a copy of their routing table to the node issuing the
request.

In the message flow, the in-seperate-flag is missing which I will add.
Indeed, the Update message parameters should be updated.

>     Enhancements required to the protocol

This is where the Update message comes into play. P2 does not need to
issue a per-row Peer-Lookup. Rather, it obtains a copy of neighbor and
routing-table of P1 using Update. P2 then checks the neighbor-table and
finds that P1's neighbor (successor) is P1 itself. Thus, P2 determines
that there is no need to send a per-row Peer-Lookup since P1 has no
successors.

In Chord, a Peer-Lookup message finds a node which succeeds the ID
specified in Peer-Lookup. If range [2^i, 2^(i+3)] does not contain any
node, then rows i, i+1, i+2, i+3 can be filled with a node which was
found when Peer-Lookup request was issued for ID i.

In general, the use of some simple heuristics by the node attempting to
fill its routing-table can greatly decrease the number of Peer-Lookup
messages.

>         be replicated and will not be removed. A separated Remove request has to be sent.

Agreed. A messasge should explicitly perform this function. Peer P1,
however, may not immediately remove the resource-objects it is going to
offload to P2. However, such a behavior is implementation specific.

>      and bootstrap/admitting node.

A join operation performs the following functions:
1) Locate the position in the overlay where a node will join.
2) Inform the neighbors that a new node is coming between them.
3) Obtain a copy of routing-tables from neighbor peers.
4) Take the responsibility for some resource-objects of its neighbors.

It is not uncommon for nodes to exchange a lot of messages during join.
Skype, for example, exchanges more than 20-30 messages with different
nodes during join. This is not to say that we should be liberal in the
number of messages exchanged but rather such an exchange is necessary
for the functioning of a distributed system.

>     based on message size. This is not a good approach.

The transport tradeoffs were highlighted in section 4.7 but they need to
be further elaborated. You are right in pointing out that only message
size should not dictate whether a request should be sent over TCP or UDP.

Rather, it should depend on whether a node is using TCP or UDP for
routing-table maintenance. If recursive routing is used and there is a TCP
connection with the next hop, the request should be sent over it.

Clearly, for iterative routing, establishing a per-hop TCP connection
incurs a setup latency. This may be useful, if a node wants to update its
routing-table from the lookup responses.

>     would have timed out at P1, but still the message goes on with in the overlay until TTL is

This is true. There is a tradeoff between maintaining additional timers
for response processing or have a simple state machine which does not
worry about late responses. I would argue on the side of simplicity but
this is open to discussion.

Regards,
Salman

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 2 Apr 2007 15:55:42 -0400

>
>>     For e.g, lets say recursive routing is used in TCP, in this  
>> case, P1 sends message to P2, P2
>> sends
>>     to P3.. and so on... and the response would reach P1 after  
>> traversing P3, P2 etc. The
>> transction
>>     would have timed out at P1, but still the message goes on with  
>> in the overlay until TTL is
>> zero.
>

For TCP, the timer is not really critical and serves a different  
function than in UDP. After all, transmission is (hop-by-hop)  
reliable, so you only have to deal with the somewhat less likely case  
of a node crashing just after it has received a message. Thus, the  
transaction timeout can be fairly long, and mainly prevents infinite  
waiting for a response that is unlikely to ever arrive.

Henning