Subject: [P2PSIP] Clarification of initial attach procedure

From: Frederic-Philippe Metz <[email-masked]>
Date: Sat, 23 Oct 2010 09:31:11 +0200

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

---

From: jc <[email-masked]>
Date: Sat, 23 Oct 2010 03:43:50 -0400

It should be AP. You are correct however JP could have discovered the node-id of AP through many means.

On Oct 23, 2010, at 3:31 AM, Frederic-Philippe Metz <[email-masked]> wrote:

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

---

From: Frederic-Philippe Metz <[email-masked]>
Date: Sat, 23 Oct 2010 18:46:51 +0200

Hi jc, thanks a lot for the support. Ok, I understand. So the second
paragraph in section 10.5 is also not correct ?

The init setup procedure, assume you have chord-reload, is where I
have problems to understand.

Assume the config-server is contacted and the bootstrap IP is in
place. What happens then ? I guess the JP a) has to establish a TLS
connection to the bootstrap peer. Then b) it has to send an attach to
the bootstrap peer for the purpose of sending further RELOAD messages
(i.e. ping to find the AP). But from where does it know the Node-Id
(for sending the attach request) of the bootstrap peer (in case of
central enrollment when the node-id is generated by the enrollment
server) ?

Second question is for clarification:
The draft states a difference between the Connection Table and the
Routing table. So I see the Connection Table (in the Forwarding and
LinkLayer) as a map of key node-id with value of a IP:Port pair. Would
that go along with the draft ? And the Routing table (in the Topology
plugin) as an Overlay specific "decision table" to which _node-id_ at
the end the message has to be routed. This node-id in the Routing
table has always a key entry in the connection table. Would that also
go along with the draft ?

Cheers,
  Frédéric

---

From: jc <[email-masked]>
Date: Sat, 23 Oct 2010 14:06:52 -0400

> central enrollment when the node-id is generated by the enrollment

The Node-Id is obtained from the message signature.

> go along with the draft ?

This sounds like a implementer detail.

---

From: Frederic-Philippe Metz <[email-masked]>
Date: Sun, 24 Oct 2010 11:43:05 +0200

Hi, I didn't catch it, sorry.

Do you mean that the node_id is learned at JP via the TLS
(certificate) authentication with bootstrap peer ? So when TLS
happens, Jp gets the node_id of bootstrap peer via the certificate
used in TLS ? That means that for debugging purpose you have to use
TLS ? We hoped during implementation that we could use simple TCP
connections first, instead of TLS.

If so, don't you think that the exchange of the Node_id should better
be placed on RELOAD-Layer, not on the Link Layer ?

Cheers,
  Frédéric

---

From: [email-masked]
Date: Mon, 25 Oct 2010 15:04:34 +0800

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,

Cheers,
Frédéric

--------------------------------------------------------
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.

---

From: Frederic-Philippe Metz <[email-masked]>
Date: Mon, 25 Oct 2010 09:36:04 +0200

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:

> "It sends an Attach to the *Resource-IP* AP+1, which gets routed to NP."
>
>  *Frederic-Philippe Metz <[email-masked]>*

---

From: [email-masked]
Date: Tue, 26 Oct 2010 09:56:23 +0800

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.

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

收件人
[email-masked] 
抄送

主题

Hi all,

Cheers,
Frédéric

--------------------------------------------------------
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.

---

From: Michael Chen <[email-masked]>
Date: Mon, 25 Oct 2010 21:09:54 -0800

My implementation agrees with Mr. Peng. There is no need for JP to use Ping to 
find AP. Just send an Attach with a *Resource-ID* as destination which contains 
_JP's own ID_ to the bootstrap node.  Since this is a *Resource-ID*, it will be 
routed to the responsible node, which is AP. AP's reply will be routed back to 
JP to start the ICE check.

Did I mention it's a *Resource-ID*? :) It is the key to this join method.

Thanks

--Michael

---

From: Bruce Lowekamp <[email-masked]>
Date: Tue, 26 Oct 2010 10:47:56 -0700

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:

> On Mon, Oct 25, 2010 at 9:04 AM, <[email-masked]*<[email-masked]>>
> wrote:
>
>   *Frederic-Philippe Metz <[email-masked]*<[email-masked]>
> *>*
> 发件人:  [email-masked]* <[email-masked]>
>
> 2010-10-23 15:31
>
>   收件人
> [email-masked]* <[email-masked]>
> 抄送
>   主题
> P2PSIP mailing list*
> [email-masked]* <[email-masked]>*
> **https://www.ietf.org/mailman/listinfo/p2psip*<https://www.ietf.org/mailman/listinfo/p2psip>
>
>
>
> are not permitted to disclose the contents of this communication to others.
> 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.

---

From: jc <[email-masked]>
Date: Tue, 26 Oct 2010 18:14:55 -0400

On Oct 26, 2010, at 1:47 PM, Bruce Lowekamp <[email-masked]> wrote:

> 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 a MUST or should be IMO.

> 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
> 
> It appear to be inconsistent between section 9.5 and section 11.  I think the method in section 11 is more efficient. 
> 
> 
> 
> 
> 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
> I think JP is correct. The Node of JP is as Resource-ID in Attach. Before Attaching, a Ping message is redundant. 
>

---

From: [email-masked]
Date: Wed, 27 Oct 2010 14:37:51 +0800

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

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

收件人
[email-masked] 
抄送

主题

Ok. So JP either can

Do you agree ? 

Cheers,
   Frederic

收件人
[email-masked] 
抄送

主题

Hi all,

Cheers,
Frédéric

---

From: Frederic-Philippe Metz <[email-masked]>
Date: Thu, 28 Oct 2010 09:06:15 +0200

Thanks for clarifying that, it got it now.

But there's one thing for me to understand which hasn't been discussed here,
yet:

There were several sentences in the draft letting me understand that the
connection table (if using not compressed destination_type) has the key as
the node_id, where i.e. when the peer gets a message etc. and has an entry
in the connection table for that peer, it must forward directly (without
consulting the routing table). I understand this (hope this understanding is
right here).

But imagine the initial case: Assume you have a bootstrap up and running and
no other node, and a new node want to enter the overlay, let say as a
client:

1. The new node gets the config document, now it is becoming very
interesting:
2. It does a TLS connection to that bootstrap node.

What now in detail ? Now it has to insert the connection information paired
with the bootstrap node_id in its connection table (and also Routing table)
before routing any _first_ RELOAD Message to a node over that bootstrap.
More precise: It has now a connection and has to insert the connection
information with the node_id of the bootstrap peer into the connection
table. Does it learn the node_id for that connection from any information
out of TLS ?

Cheers,
Frederic

On Wed, Oct 27, 2010 at 12:14 AM, jc <[email-masked]> wrote:

> attach is routed to the JP's resource-id, though.
>
>
> 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
> On Mon, Oct 25, 2010 at 6:56 PM, < <[email-masked]>
> [email-masked]> wrote:
>
>>
>>  *Frederic-Philippe Metz < <[email-masked]>
>> [email-masked]>*
>> 发件人:   <[email-masked]>[email-masked]
>>
>> 2010-10-25 15:36
>>   收件人
>>  <[email-masked]>[email-masked]
>> 抄送
>>   主题
>>  <[email-masked]>[email-masked]
>>  <https://www.ietf.org/mailman/listinfo/p2psip>
>>  <[email-masked]>[email-masked]
>>  <https://www.ietf.org/mailman/listinfo/p2psip>