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

From: "Michael Chen" <[email-masked]>
Date: Mon, 23 Nov 2009 10:34:56 -0700

Julian,

I know that dilemma. It's a ring of 2 scenario. The bootstrap node (BN) is also the admitting node (AP) of the join node (JP). The sequence of event is like this:

1) JP looks up for BN (via broadcast, multi-cast, DNS, etc.)

2) JP Attach to BN

3) JP and BN do ICE check followed by D/TLS handshake.

3) JP Attach to JP+1 (looking for its successor)

4) BN reply the Attach with the Node-ID of AP == BN.

For any Attach request, the sender should check its connection table to see it has already connected to the target peer. At this point, both JP and BN discover that it is already connected to each other. In our implementation, both JP and BN will skip the ICE check and D/TLS.  Instead, they both reuse the connection obtained from step 2 and 3 and move on.

5) JP send JOIN to AP (BN).

This ring of 2 scenario also applies to a populated ring in which the BP also happens to be the AP of a new peer seeking to join.

Thanks

--Michael

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

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

From: jc <[email-masked]>

Date: Sun, November 22, 2009 9:57 pm

To: Michael Chen <[email-masked]>

Cc: "[email-masked]" <[email-masked]>

Michael,

I have a single bootstrap node with zero successors and predecessors. How does this work under that common scenario? It doesn't in my lab. The Attach won't be routed anywhere and JP will never Join nor will any other Node. JP MUST send a Join first and then Attach to the Resource-ID.

Julian

Sent from my iPhone

On Nov 22, 2009, at 8:37 PM, "Michael Chen" <[email-masked]> wrote:

Julian,

The last 3 paragraphs of 9.4 explains how this works. Say JP n knows and have connected one and only one node in the overlay (the bootstrap node) B. To discover and attach to JP's **unknonwn** successor s0, JP do the following calculation:

n1 = n + 1; // simple 128-bit modulo addition

Then construct an Attach request that contains a lone Resource-ID destination entry:

struct Destination {
DestinationType         type;
uint8                   length;
DestinationData         destination_data;
} dest;

dest.type = DestinationType.resource; // Not node!!!

dest.lenght = 17;

dest.destination_data.resource_id.length = 16;

memcpy(dest.destination_data.resource_id.value, n1, 16);

The ResourceID in dest contains the value of n1. When bootstrap node B receives this Attach request, according to Section 5.1.1 it will route the message to JP's immediate successor (n1 or higher) s1. In the reply, s1 will include its ICE info, which get forwarded back to JP. Then JP and s1 will do ICE and connect.

Thanks

--Michael

-------- Original Message --------
Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work
From: jc <[email-masked]>
Date: Sun, November 22, 2009 12:06 pm
To: "Michael Chen" <[email-masked]>
Cc: [email-masked]

Michael,
I understand the discovery of Node-ID's by Resource-ID's. You are stating that you connect to a bootstrap node and start sending Attach requests however there is a problem. Where do you obtain the Node-ID's or Resource-ID's to send the Attach requests to?

This is a technical impossibility. You MUST have at least another Node-ID or Resource-ID other than that of the bootstrap node. You MUST learn at least a single Node-ID or Resource-ID from the bootstrap node.

Julian

On Nov 22, 2009, at 2:34 PM, Michael Chen wrote:

Julian,

Please revisit section 5.1.1, particularly the last paragraph. The nuance is that for any request (including Attach), the last Destination entry in the destination-list can be either a Resource-ID or a Node-ID. Normally, an Attach to a known peer uses a Node-ID Destination.

However, the example in Section 11 demonstrates sending an Attach that uses a Resource-ID to discover an **unknown** peer (JP's successor s0, s1 and finger nodes). This is a clever use of Attach. Since it is sent to the bootstrap node (or other known peer, e.g. use s0 to find s1), there is no need to use Ping. Like I said, Section 11 is sound as it is.

Thanks

--Michael

-------- Original Message --------
Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work
From: jc <[email-masked]>
Date: Sat, November 21, 2009 10:47 pm
To: "Michael Chen" <[email-masked]>
Cc: [email-masked]

On Nov 21, 2009, at 11:16 PM, Michael Chen wrote:

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

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

>
> --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: Mon, 23 Nov 2009 12:44:13 -0500

Michael,
This is what I was attempting to state the entire time and needs to be  
worded in correctly in the draft.

Also why would you perform an ICE connectivity check with a public  
bootstrap node? This doesn't bring anything worthy of doing. The  
connectivity check is performed by DTLS/TLS in this case..

Julian

Sent from my iPhone

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

> Julian,
>
> I know that dilemma. It's a ring of 2 scenario. The bootstrap node  
> (BN) is also the admitting node (AP) of the join node (JP). The  
> sequence of event is like this:
>
> For any Attach request, the sender should check its connection table  
> to see it has already connected to the target peer. At this point,  
> both JP and BN discover that it is already connected to each other.  
> In our implementation, both JP and BN will skip the ICE check and D/ 
> TLS.  Instead, they both reuse the connection obtained from step 2  
> and 3 and move on.
>
> This ring of 2 scenario also applies to a populated ring in which  
> the BP also happens to be the AP of a new peer seeking to join.
>
> Thanks
>
> --Michael
>
> I have a single bootstrap node with zero successors and  
> predecessors. How does this work under that common scenario? It  
> doesn't in my lab. The Attach won't be routed anywhere and JP will  
> never Join nor will any other Node. JP MUST send a Join first and  
> then Attach to the Resource-ID.
>
> Julian
>
> Sent from my iPhone
>
>> The last 3 paragraphs of 9.4 explains how this works. Say JP n  
>> knows and have connected one and only one node in the overlay (the  
>> bootstrap node) B. To discover and attach to JP's **unknonwn**  
>> successor s0, JP do the following calculation:
>>
>> The ResourceID in dest contains the value of n1. When bootstrap  
>> node B receives this Attach request, according to Section 5.1.1 it  
>> will route the message to JP's immediate successor (n1 or higher)  
>> s1. In the reply, s1 will include its ICE info, which get forwarded  
>> back to JP. Then JP and s1 will do ICE and connect.
>>
>> Thanks
>>
>> --Michael
>>
>> I understand the discovery of Node-ID's by Resource-ID's. You are  
>> stating that you connect to a bootstrap node and start sending  
>> Attach requests however there is a problem. Where do you obtain the  
>> Node-ID's or Resource-ID's to send the Attach requests to?
>>
>> This is a technical impossibility. You MUST have at least another  
>> Node-ID or Resource-ID other than that of the bootstrap node. You  
>> MUST learn at least a single Node-ID or Resource-ID from the  
>> bootstrap node.
>>
>> Julian
>>
>>> Please revisit section 5.1.1, particularly the last paragraph. The  
>>> nuance is that for any request (including Attach), the last  
>>> Destination entry in the destination-list can be either a Resource- 
>>> ID or a Node-ID. Normally, an Attach to a known peer uses a Node- 
>>> ID Destination.
>>>
>>> However, the example in Section 11 demonstrates sending an Attach  
>>> that uses a Resource-ID to discover an **unknown** peer (JP's  
>>> successor s0, s1 and finger nodes). This is a clever use of  
>>> Attach. Since it is sent to the bootstrap node (or other known  
>>> peer, e.g. use s0 to find s1), there is no need to use Ping. Like  
>>> I said, Section 11 is sound as it is.
>>>
>>> Thanks
>>>
>>> --Michael
>>> > 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:
>>>
>>> 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.
>>>
>>> 6. JP SHOULD send a series of Attach requests to form connections  
>>> finger table entries.
>>> > 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,
>>> >>