Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work

From: "Michael Chen" <[email-masked]>
Date: Sat, 21 Nov 2009 21:16:28 -0700

Julian,

Section 9.4 1. already established that JP has a connection to the bootstrap node. Function-wise, I think the example in Section 11 is sufficient to join the overlay.

As for 9.6.1, when a peer lost all its successors, the overlay may have been partitioned (the ring is broken). Whether it uses Ping or Attach to re-join makes no difference.

Actually, I made a couple of mistakes in my text. In the paragraph after step 8, "Node-ID" should be "Resource-ID".  The original text of draft-06 is correct per section 5.1.1 last paragraph.

--Michael

-------- Original Message --------

Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work

From: jc <[email-masked]>

Date: Sat, November 21, 2009 11:16 am

To: Michael Chen <[email-masked]>

Attach messages are routed through the overlay where pings are not.

A ping actually tests the path while Attach does not.

Also the wording changes break further 9.* sections. For instance 9.6.1 states "this peer should behave as if it is joining the network and use pings to find a peer and send it a Join".

It's clearly not defined correctly as is however. A ping is error prone unless you've already Attached due to possible NAT. While an Attach will reach any node that is inside the ring a ping will not.

Julian

Sent from my iPhone

On Nov 21, 2009, at 12:42 PM, "Michael Chen" <[email-masked]> wrote:

Hi,

Draft-06 Section 9.4 is dated and needs work.

2.  JP SHOULD use a series of Pings to populate its routing table.
3.  JP SHOULD send Attach requests...
4.  JP MUST enter all the peers it has contacted into its routing
table.

Section 11 provided a better method in which Attach requests are used
(instead of Ping) to discover and populate the routing table.  There is
no need to use Ping.  Suggest using the following text:

1.  JP MUST connect to its chosen bootstrap node.
2.  JP SHOULD send a series of Attach requests to discover and connect
to peers that make up its neighbor table as well as the desired 16
finger table entries.  Note that this does not populate their
routing tables, but only their connection tables, so JP will not
get messages that it is expected to route to other nodes.
3.  JP MUST enter all the peers it has contacted into its routing
table and connection table.
4.  JP SHOULD send a Join to its immediate successor, the admitting
peer (AP) for Node-ID n.  The AP sends the response to the Join.
5.  AP MUST do a series of Store requests to JP to store the data
that JP will be responsible for.
6.  AP MUST send JP an Update explicitly labeling JP as its
predecessor.  At this point, JP is part of the ring and
responsible for a section of the overlay.  AP can now forget any
data which is assigned to JP and not AP.
7.  AP MUST send an Update to all of its neighbors with the new
values of its neighbor set (including JP).
8.  JP SHOULD send Updates to all the peers in its routing table.

In order to populate its neighbor table, JP n sends an Attach via the
bootstrap node directed at Node-ID n+1 (directly after its own Node-ID).
This allows it to discover its own successor.  Call that node s0.  It
then sends an Attach (via the bootstap peer or s0) to s0+1 to discover
its second successor (s1).  This process can be repeated to discover as
many successors as desired.  The predecessors of JP will be found at a
later stage when JP receives an Update.

In order to set up its finger table entry i, JP simply sends an Attach
to peer (n+2^(numBitsInNodeId-i).  This will be routed to a peer in
approximately the right location around the ring.

The joining peer MUST NOT send any Update message placing itself in
the overlay until it has successfully completed an Attach with each
peer that should be in its neighbor table.

Thanks

--Michael

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

---

From: jc <[email-masked]>
Date: Sun, 22 Nov 2009 01:47:46 -0500

> Section 9.4 1. already established that JP has a connection to the bootstrap node. Function-wise, I think the example in Section 11 is sufficient to join the overlay.

Right.

> As for 9.6.1, when a peer lost all its successors, the overlay may have been partitioned (the ring is broken). Whether it uses Ping or Attach to re-join makes no difference.

The logical ring wouldn't be broken if it were partitioned. You would have N overlays that aren't communicating with one another. So the logic from 9.6.4.4. would be used in that case which states sending a Ping not an Attach.

> Actually, I made a couple of mistakes in my text. In the paragraph after step 8, "Node-ID" should be "Resource-ID".  The original text of draft-06 is correct per section 5.1.1 last paragraph.

The problem I see is:

 1.  JP MUST connect to its chosen bootstrap node.
 2.  JP SHOULD send a series of Attach requests to discover and connect....

In order to perform 2 you need to know "some" Node-ID's in your neighbor table. So you MUST send a Join on connection to the bootstrap node and then you can start forming your Attach requests. 

It should read something like:

 1.  JP MUST connect to its chosen bootstrap node (AP).
 2.  JP Sends a Join request to JP announcing its intention to join.
 3.  AP sends a Join response.
 4.  AP does a sequence of Stores to JP to give it the data it will need.
 5.  AP does Updates to JP to tell it about its own routing table.
 6.  JP SHOULD send a series of Attach requests to form connections to peers that make up its neighbor table as well as the desired 16 finger table entries.

Julian