Subject: [p2p-sip] draft-bryan-sipping-p2p-03 and Chord's notify procedure

From: jean-francois.wauthy at alcatel.fr (Jean-François Wauthy)
Date: Fri, 10 Nov 2006 16:30:09 +0100

Hi,

In subsection 10.8 of draft-bryan-sipping-p2p-03 describing the periodic 
stabilization, it is required to send a REGISTER request structured as 
if the stabilizing peer had just entered the system when the peer 
updates its successor so that that successor can eventually update its 
predecessor. IMO, this can't work because the successor will eventually, 
even almost every time in fact, route the REGISTER request to another 
peer in the overlay (may be the stabilizing peer itself).

This can be seen illustrated with the example of subsection 13.4, when 
peer 3 runs its periodic stabilization it sends a REGISTER request to 
peer 10, structured as if peer 3 had just entered the system. It is then 
said that:
"When Peer 10 receives the message, it then sends a 200 OK response to 
Peer 3."

How did peer 10 figure out that it handles registration of peer 3 ? 
According to the successor, predecessor and finger table information I 
think it should route the REGISTER request to peer 3 itself (as it 
doesn't have a predecessor it can't determine the interval it covers and 
thus must rely on its finger table to route the message).

Have i missed something ?

BTW i found a little repetition in subsection 10.2, the sentence : "The 
peer MUST initialize its finger table such that all entries point to 
itself." is useless as it is repeated in the next sentence.

--
Jean-Fran?ois Wauthy

---

From: marcia at sipeerior.com (Marcia Z Bryan)
Date: Fri, 10 Nov 2006 15:33:47 -0500

On 11/10/06, Jean-Fran?ois Wauthy <jean-francois.wauthy at alcatel.fr> wrote:
> peer 10, structured as if peer 3 had just entered the system.

Peer 3, the stabilizing peer, sends a Peer Registration (see section 9.2.2.1)
message to Peer 10.

It is then
> How did peer 10 figure out that it handles registration of peer 3 ?

Peer 10 handles the message from Peer 3 as if Peer 10 is the admitting peer
(sections 9.2.2.2 and 10.4).  From 10.4 in the draft:

"...the admitting peer MUST reply with a 200 response if the joining peer
has a Peer-ID between the admitting peer's predecessor's Peer-ID and the
admitting Peer-ID, or the admitting peer's predcessor is NULL."

Peer 10 is checking to see if Peer 3 should be its predecessor --- basically
checking to see if Peer 3 is in  the interval [pred, Peer 10).  Because Peer
10 doesn't have a predecessor (pred = NULL), it sets its predecessor to Peer
3.

I believe it is still an open issue as to what the stabilizing peer, Peer 3
in this example, does if the response is not a 200.

does this help?

--Marcia

> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061110/16d3bd4e/attachment.html

---

From: jean-francois.wauthy at alcatel.fr (Jean-François Wauthy)
Date: Mon, 13 Nov 2006 09:25:44 +0100

Marcia Z Bryan a ?crit :
> On 11/10/06, *Jean-Fran?ois Wauthy* <jean-francois.wauthy at alcatel.fr 
> <mailto:jean-francois.wauthy at alcatel.fr>> wrote:
>
> Peer 10 handles the message from Peer 3 as if Peer 10 is the admitting 
> peer (sections 9.2.2.2 <http://9.2.2.2> and 10.4).  From 10.4 in the 
> draft:
>
> "...the admitting peer MUST reply with a 200 response if the joining 
> peer has a Peer-ID between the admitting peer's predecessor's Peer-ID 
> and the admitting Peer-ID, or the admitting peer's predcessor is NULL."
>
Hmm, somehow i skipped that part. I understand now how peer 10 knows it 
is the admitting node for the request and must process it.
> Peer 10 is checking to see if Peer 3 should be its predecessor --- 
> basically checking to see if Peer 3 is in  the interval [pred, Peer 
> 10).  Because Peer 10 doesn't have a predecessor (pred = NULL), it 
> sets its predecessor to Peer 3. 
Shouldn't the interval be (pred, Peer 10] ? AFAICT the definition of 
that interval isn't clearly defined in the draft and may also cause some 
confusion.
> I believe it is still an open issue as to what the stabilizing peer, 
> Peer 3 in this example, does if the response is not a 200.
OK
> does this help?
Yes, thanks for the explanations.

-- 
Jean-Fran?ois Wauthy