Subject: Re: [P2PSIP] Section 3.5.2 and 10.5 Discrepancies

From: Cullen Jennings <[email-masked]>
Date: Thu, 15 Oct 2009 19:06:46 -0600

I thought about this and talked to a few people. No one could see any  
reason the bootstrap node had to be a peer (clearly it can be a peer)  
so I went and updated the terminology to refer to bootstrap node  
instead of peer. Folks on the list, think about this one - if someone  
has a good reason that the bootstrap has to be a peer, this will need  
to be changed back.

On Sep 10, 2009, at 4:54 AM, jc wrote:

> Hi,
>
> From subversion(04) draft:
>
> 3.5.2.  Joining, Leaving, and Maintenance Overview
>
> The first thing the peer needs to do is form a connection to some  
> "bootstrap node".
>
> 10.5.  Contacting a Bootstrap Peer
>
> When contacting a bootstrap peer, the joining peer sends a Ping  
> request to the bootstrap peer's known IP address with the  
> destination Node-ID set to the joining peer's Node-ID
>
> When the requester peer finally does receive a response from some  
> responding peer, it can note the Node-ID in the response and use  
> this Node-ID to start sending requests to join the Overlay Instance  
> as described in
>
> There are two problems here, the first is simply terminology.
>
> 3.5.2 uses "bootstrap node"
>
> 10.5 uses "bootstrap peer"
>

> The second, 10.5 does not mention forming a connection and looks as  
> if it was based on a UDP bootstrap mechanism or the multicast  
> bootstrap(10.4). Am I correct that 10.5 is attempting to refer to  
> 3.5.2 and that 10.5 should clear up the fact that your forming a  
> connection to a bootstrap peer and not simply sending a datagram to  
> bootstrap nodes and waiting for responses?
>
> REgaRDs,
> Julian
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip

---

From: jc <[email-masked]>
Date: Thu, 15 Oct 2009 22:02:52 -0400

As long as a client can perform lookups on behalf of other nodes this  
won't be a problem.

Julian

On Oct 15, 2009, at 9:06 PM, Cullen Jennings wrote:

>
> I thought about this and talked to a few people. No one could see  
> any reason the bootstrap node had to be a peer (clearly it can be a  
> peer) so I went and updated the terminology to refer to bootstrap  
> node instead of peer. Folks on the list, think about this one - if  
> someone has a good reason that the bootstrap has to be a peer, this  
> will need to be changed back.
>
>

---

From: jc <[email-masked]>
Date: Thu, 15 Oct 2009 22:36:23 -0400

Cullen,
I may not be on the same page as to what I just said.(old email) This  
is referring to the fact that you CAN bootstrap off of ANY node? If so  
then the terminology needs to state otherwise about public ip address  
as well. Because you CAN bootstrap off of a Client behind the same NAT  
that is connected to a remote Peer that is inside the ring. I  
demonstrated this with multicast bootstrap.

If that is the case the following may be removed:

Because this is the first connection the peer
1461	   makes, these nodes must have public IP addresses and therefore  
can be
1462	   connected to directly.

from svn:

1451	   The first thing the peer needs to do is form a connection to  
some
1460	   "bootstrap node".  Because this is the first connection the peer
1461	   makes, these nodes must have public IP addresses and therefore  
can be
1462	   connected to directly.  Once a peer has connected to one or more
1463	   bootstrap nodes, it can form connections in the usual way by  
routing
1464	   Attach messages through the overlay to other nodes.  Once a  
peer has
1465	   connected to the overlay for the first time, it can cache the  
set of
1466	   nodes it has connected to with public IP addresses for use as  
future
1467	   bootstrap nodes.

If this wasn't the topic please disregard.

Julian

On Oct 15, 2009, at 10:02 PM, jc wrote:

> As long as a client can perform lookups on behalf of other nodes  
> this won't be a problem.
>
> Julian
>
>>> this Node-ID to start sending requests to join the Overlay  
>>> Instance as described in
>>>
>>> The second, 10.5 does not mention forming a connection and looks  
>>> as if it was based on a UDP bootstrap mechanism or the multicast  
>>> connection to a bootstrap peer and not simply sending a datagram  
>>> to bootstrap nodes and waiting for responses?
>>>
>>> REgaRDs,
>>> Julian

---

From: jc <[email-masked]>
Date: Thu, 15 Oct 2009 23:10:49 -0400

On what I just said. If Client A connects to Client B that is  
connected to Peer Y then Client A can send a Lookup through Client B  
to Peer Y performing the bootstrap. Should clients be able to  
bootstrap off of other clients or is this to be reserved for public ip  
addresses as currently stated in draft? The confusion of this was  
created by multicast bootstrap. If multicast bootstrap is removed then  
this won't be a problem anymore.

Julian

On Oct 15, 2009, at 10:36 PM, jc wrote:

> Cullen,
> I may not be on the same page as to what I just said.(old email)  
> This is referring to the fact that you CAN bootstrap off of ANY  
> node? If so then the terminology needs to state otherwise about  
> public ip address as well. Because you CAN bootstrap off of a Client  
> behind the same NAT that is connected to a remote Peer that is  
> inside the ring. I demonstrated this with multicast bootstrap.
>
> 1461	   makes, these nodes must have public IP addresses and  
> therefore can be
> 1461	   makes, these nodes must have public IP addresses and  
> therefore can be
> 1465	   connected to the overlay for the first time, it can cache  
> the set of
> 1466	   nodes it has connected to with public IP addresses for use  
> as future
> 1467	   bootstrap nodes.
>
>>> any reason the bootstrap node had to be a peer (clearly it can be  
>>> a peer) so I went and updated the terminology to refer to  
>>> bootstrap node instead of peer. Folks on the list, think about  
>>> this one - if someone has a good reason that the bootstrap has to  
>>> be a peer, this will need to be changed back.
>>>
>>>

---

From: jc <[email-masked]>
Date: Thu, 15 Oct 2009 23:45:17 -0400

6481	10.4.  Contacting a Bootstrap Node
6482	
6483	   In order to join the overlay, the joining peer MUST contact a  
peer in
6484	   the overlay.  Typically this means contacting the bootstrap  
nodes,
6485	   since they are guaranteed to have public IP addresses (the  
overlay
6486	   configuration should not advertise them as bootstrap nodes
6487	   otherwise).  If the joining peer has cached a list of peers it  
has
6488	   previously been connected with in this overlay, as an  
optimization it
6489	   MAY attempt to use one or more of them as bootstrap nodes before
6490	   falling back to the bootstrap nodes listed in the  
configuration file.

Section 3.2 and 10.4 backs up my discussion. Technically speaking a  
Client performs a bootstrap and when inside the ring will be  
considered a Peer. So a Peer doesn't join the overlay as stated, a  
Client does but more-so a Node in general. This could be more clear by  
stating Node when referring to a Bootstrap or Join procedure instead  
of a Peer on the Sender side. However in the end this is a "when are  
you considered a peer vs client" scenario. For instance if you are  
sending a Join chances are the intentions of the Node is to become a  
Peer.

 From 3.2:

1143 We use the term "peer" to identify a node in the overlay that  
routes
1144	   messages for nodes other than those to which it is directly
1145	   connected.

This states that you are not not a Peer when you send a Join but  
instead after the Join and Updates have been performed and the Node is  
inside the ring. Therefore a Client or Node performs Bootstrap and  
Join procedures not Peers.

Julian

On Oct 15, 2009, at 11:10 PM, jc wrote:

> bootstrap off of other clients or is this to be reserved for public  
> ip addresses as currently stated in draft? The confusion of this was  
> created by multicast bootstrap. If multicast bootstrap is removed  
> then this won't be a problem anymore.
>
> Julian
>
>> public ip address as well. Because you CAN bootstrap off of a  
>> Client behind the same NAT that is connected to a remote Peer that  
>> is inside the ring. I demonstrated this with multicast bootstrap.
>>
>> 1451	   The first thing the peer needs to do is form a connection  
>> to some
>> 1463	   bootstrap nodes, it can form connections in the usual way  
>> by routing
>>>>> The first thing the peer needs to do is form a connection to  
>>>>> some "bootstrap node".
>>>>>
>>>>> When the requester peer finally does receive a response from  
>>>>> some responding peer, it can note the Node-ID in the response  
>>>>> and use this Node-ID to start sending requests to join the  
>>>>> Overlay Instance as described in
>>>>>
>>>>> bootstrap(10.4). Am I correct that 10.5 is attempting to refer  
>>>>> to 3.5.2 and that 10.5 should clear up the fact that your  
>>>>> forming a connection to a bootstrap peer and not simply sending  
>>>>> a datagram to bootstrap nodes and waiting for responses?
>>>>>
>>>>> REgaRDs,
>>>>> Julian