Subject: Re: [P2PSIP] 答复: Re: 答复: Re: 答复: Clarification of initial attach procedure

From: Bruce Lowekamp <[email-masked]>
Date: Mon, 1 Nov 2010 07:29:11 -0700

In Section 9.4, you're right that there's no reason for the PINGs to
be there.   Right now the first three steps are:

1.  JP MUST connect to its chosen bootstrap node.
   2.  JP SHOULD use a series of Pings to populate its routing table.
   3.  JP SHOULD send Attach requests to initiate connections to each of
       the peers in the neighbor table as well as to the desired 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.

Propose a change to make it:

1.  JP MUST connect to its chosen bootstrap node.
2. <deleted, renumber the rest>
3. JP SHOULD send Attach requests to the resource IDs
   necessary to populate each of the peers in its
  neighbor table as well as to the desired 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.
....

Then after the list, change:

In order to populate its neighbor table, JP sends a Ping via the
   bootstrap node directed at Resource-ID n+1 (directly after its own
   Resource-ID).  This allows it to discover its own successor.  Call
   that node p0.  It then sends a ping to p0+1 to discover its successor
   (p1).  This process can be repeated to discover as many successors as
   desired.  The values for the two peers before p will be found at a
   later stage when n receives an Update.

to

In order to populate its neighbor table, JP sends an Attach via the
   bootstrap node directed at Resource-ID n+1 (directly after its own
   Resource-ID).  This allows it to discover and Attach to its own
successor.  Call
   that node p0.  It then sends an Attach to p0+1 to discover its successor
   (p1).  This process can be repeated to discover as many successors as
   desired.  The values for the two peers before p will be found at a
   later stage when n receives an Update.

Bruce

2010/10/26 <[email-masked]>
>
> I'm sorry, it is error in my last e-mail. It should be section 9.4 rather than section 9.5 which is inconsistent with section 11.
>
>
>
>
>
> Bruce Lowekamp <[email-masked]>
>
> 2010-10-27 01:47
>
> 收件人
> [email-masked]
> 抄送
> Frederic-Philippe Metz <[email-masked]>, [email-masked], [email-masked]
> 主题
> Re: [P2PSIP] 答复: Re: 答复: Clarification of initial attach procedure
>
>
>
>
> Yes, using PING first introduces some corner failure cases that simply routing the ATTACH to the resource-id of JP does not.
>
> Section 9.5  doesn't actually conflict with the notion that the initial attach is routed to the JP's resource-id, though.  9.5 simply says that if peer A learns of peer B through peer C, it needs to send the ATTACH through peer C.  This is simply because A may not have connectivity with B other than through peer C, such as when an overlay has been partitioned and is now healing.  The initial ATTACH is essentially handled the same way, because it is routed via the BP.
>
> Bruce
>
> On Mon, Oct 25, 2010 at 6:56 PM, <[email-masked]> wrote:
>
> Yes, these methods are also ok.
> It appear to be inconsistent between section 9.5 and section 11.  I think the method in section 11 is more efficient.
>
>
>
> Frederic-Philippe Metz <[email-masked]>
> 发件人:  [email-masked]
>
> 2010-10-25 15:36
>
> 收件人
> [email-masked]
> 抄送
> 主题
> Re: [P2PSIP]        答复:  Clarification of initial attach procedure
>
>
>
>
>
>
> Ok. So JP either can
> a) Send a ping to the resource id+1 (as the node_id of JP) to get the node-id (in the RELOAD message signature of the Ping answer) to then perform an attach to this node_id (this is mentioned in 9.4) or
> b) directly form a resource-id+1 (as JP's node_id) and send an attach.
>
> Do you agree ?
>
> Cheers,
>    Frederic
>
> On Mon, Oct 25, 2010 at 9:04 AM, <[email-masked]> wrote:
>
> I think JP is correct. The Node of JP is as Resource-ID in Attach. Before Attaching, a Ping message is redundant.
>
> There is the description above the second dirgram in the draft:
> "It sends an Attach to the Resource-IP AP+1, which gets routed to NP."
>
> "Resource-IP" should be "Resource-ID".
>
>
> Frederic-Philippe Metz <[email-masked]>
> 发件人:  [email-masked]
>
> 2010-10-23 15:31
>
> 收件人
> [email-masked]
> 抄送
> 主题
> [P2PSIP] Clarification of initial attach procedure
>
>
>
>
>
>
>
>
> Hi all,
>
> I've got a question resp. page 123:
>
> The first attach in the call flow diagram states JP as the
> destination. I think it should be AP ? JP has got the node-id of AP
> from a previous ping, right ? If that assumption is not right, the
> attach to node-id JP will fail, because 5.5.1 states that the attach
> to a node-id which isn't reached will fail.
>
> Cheers,
> Frédéric
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip
>
>
>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
>
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip
>
>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
>
>
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip
>
>
>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.