Subject: Re: [P2PSIP] New versions of RELOAD and sip draft

From: [email-masked]
Date: Fri, 23 Oct 2009 15:47:50 -0400

IMHO Lin Xiao has a quite valid point. If due changes of topology, node 500 permanently loose its ability to interconnect with close ( in DHT space) nodes, it has to be excluded from DHT ring or have to get a new ID.

Otherwise, it will became a permanent dead-end node for lookups for targets in its immediate neighborhood that significantly degrades speed of DHT lookup and ( under some conditions) can event result in DHT space segmentation.

>500 can of course keep it's node id, regardless of whether 400 and/or 
>600 are there or not. Due to stabilization and by means of the 
>successorcache the predecessor of 400 will notice the absence and bridge 
>directly to 500 as well as 500 will skip 600 after a short time and go 
>to 700 (in order to stay in the picture).  Using notify the ring will 
>close again. 400 and 600 may return whenever they want.
>
>Regards
>
>
>Xiao, Lin (NSN - CN/Beijing) schrieb:
>> Hi,
>>
>> Maybe I'm wrong, but I consider peers in RELOAD are structured with a
>> DHT algorithm, e.g., in Chord, peer with Node-ID 500 is connected with
>> peer 400 and 600. 
>>
>> However, what will happen, if peer 500 totally lose both of the
>> connections due to mobility and NAT, but can set up new ones with peer
>> 100 and peer 300? IMHO, in order to keep the topology structured, if
>> this node still want to be a peer in the overlay it should change its
>> Node ID to, say 200, and rejoin the overlay to enable itself still
>> reachable with the DHT algorithm.
>>
>> If peers in a overlay can not be connected with a strict order, the DHT
>> algorithm for structured topology will not work anymore.
>>
>>
>> Br
>> Xiao, Lin 
>>
>> -----Original Message-----
>> From: ext jc [mailto:[email-masked]] 
>> Sent: Thursday, October 22, 2009 12:41 AM
>> To: Xiao, Lin (NSN - CN/Beijing)
>> Cc: ext Cullen Jennings; P2PSIP WG
>> Subject: Re: [P2PSIP] New versions of RELOAD and sip draft
>>
>> The draft doesn't state that you MUST change you NodeID if you lose
>> overlay connectivity. In fact under your given condition you would
>> simply retain it and connect again as a Client when the network is back
>> up.
>>
>> Julian
>>
>> On Oct 21, 2009, at 3:59 AM, Xiao, Lin (NSN - CN/Beijing) wrote:
>>
>>   
>>> Hi Cullen,
>>>
>>> Thanks for your reply.
>>>
>>> I agree that RELOAD have covered  most of the functionalities of peers
>>>     
>>
>>   
>>> and clients. However, there is still a little different between 
>>> clients and peers while connection is lost besides data replica. What 
>>> I mean here is the Node ID.
>>>
>>> Because all the peers in the overlay are connected according to a 
>>> strict overlay algorithm. The position of a peer in the overlay is 
>>> decided by its Node ID. If a peer lost its position (disconnected) in 
>>> the overlay because of moving and NAT, but still want to work as a 
>>> peer, it must change its Node ID, which means it need do the 
>>> enrollment again and rejoin the overlay.
>>>
>>> But, because a client can attach with an arbitrary peer. It is not 
>>> necessary for a client to change its Node ID when it change its 
>>> attaching peer. The most important thing here is that, this behavior 
>>> make it possible for a client  to keep session continuity while its 
>>> attaching peer is switched.
>>>
>>> Considering to deploy  RELOAD in reality, stable nodes are preferred 
>>> to work as peers while mobile nodes can take the advantage of the 
>>> client behavior mentioned above. Sessions can be kept with high 
>>> mobility, as unique Node ID is maintained by clients. I'm not sure if 
>>> RELOAD has considered this distinction of client, which help clients 
>>> to be attached with the ovelay as long as it can build at least one 
>>> connection to the overlay.
>>>
>>> Br
>>> Xiao, Lin
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: ext Cullen Jennings [mailto:[email-masked]]
>>> Sent: Friday, October 16, 2009 9:05 AM
>>> To: Xiao, Lin (NSN - CN/Beijing)
>>> Cc: P2PSIP WG
>>> Subject: Re: [P2PSIP] New versions of RELOAD and sip draft
>>>
>>>
>>> Thank you, few comments inline....
>>>
>>> On Oct 10, 2009, at 2:20 AM, Xiao, Lin (NSN - CN/Beijing) wrote:
>>>
>>>     
>>>> Hi Cullen,
>>>>
>>>> I've had a quick review of these two drafts, and still not quite 
>>>> clear
>>>>       
>>>> with some Client related issues.
>>>>
>>>> I know Client is not the first-class concept in RELOAD, but as it has
>>>>       
>>
>>   
>>>> been involved in the RELOAD protocol, RELOAD should give full support
>>>>       
>>
>>   
>>>> to client anyhow, right?
>>>>
>>>> In the terminology chapter of RELOAD Base draft, the connection table
>>>>       
>>
>>   
>>>> is defined as:
>>>>    "The set of peers to which a node is directly connected.  This 
>>>> includes nodes with which Attach handshakes have  been done but which
>>>>       
>>
>>   
>>>> have not sent any Updates."
>>>> although, the second sentence implies that clients are also involved 
>>>> in, I still suggest to replace the "peers" in the first sentence with
>>>>       
>>
>>   
>>>> "nodes" to make it more clear that both peers and clients can be 
>>>> maintained in the table.
>>>>       
>>> I agree. I changed this - thank you for the careful review to catch 
>>> things like this.
>>>
>>>     
>>>> In my opinions, connection setup and maintenance between client and 
>>>> its connected peer (responsible peer or arbitrary peer) is a key 
>>>> issue for client support in RELOAD.  My question is: Does a peer in 
>>>> RELOAD distinguish if the connection is to a peer or to a client? 
>>>> Because the reaction of the peer could be different when the 
>>>> connection is lost.
>>>>       
>>> Reload does distinguish at some level but what do you think a node 
>>> needs to do differently when a connection is lost if the connection 
>>> when to a peer or client. Clearly how data replication is handled and 
>>> some of the finger table stuff is handled differently but I think that
>>>     
>>
>>   
>>> is covered in the draft. If you see something specific missing, let me
>>>     
>>
>>   
>>> know.
>>>
>>>     
>>>> As a client could set up a connection only with an arbitrary peer.
>>>> Does
>>>> this peer distinguish such connection from those it is responsible 
>>>> to?
>>>>       
>>> I don't se the need to.
>>>
>>>     
>>>> Should this peer inform the client's responsible peer about the 
>>>> Destination List to the client? So that it can still be accessed by 
>>>> other nodes. Or should the Destination List been stored with some 
>>>> usage, say SIP Usage?
>>>>       
>>> Yes, that is the approach to store destination lists where they are 
>>> needed.
>>>
>>>     
>>>> If so, the SIP usage must be extended to allow a Destination list 
>>>> containing more than one Node IDs.
>>>>       
>>> agree that it needs to allow storing multiple Node IDs but I think it 
>>> already does that.
>>>
>>>     
>>>> In current SIP
>>>> usage draft, the SipRegistration structure only allow one address 
>>>> being stored in the Destination List, as:
>>>> " Destination          destination_list<0..2^16-1>;"
>>>>       
>>> The destination_list here is an array of Destinations so it allows 
>>> between 0 and 65K entries in the array. I agree the syntax for 
>>> specifying arrays might seem a bit weird but I think the structure is 
>>> what you are pointing out we need to have.
>>>
>>>     
>>>> It should be replaced by: "Destination          destination_list
>>>> [dest_list_length];"
>>>> to enable a longer list stored by arbitrary connected clients.
>>>>
>>>> Anyway, IMHO, RELOAD should make sure to cover all situations a 
>>>> client could meet or at least clearly distinguish issues of clients, 
>>>> especially for arbitrary connected ones, which are left to be solved 
>>>> by other drafts. Thanks.
>>>>
>>>>
>>>> Best Regards,
>>>> Xiao, Lin
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: [email-masked] [mailto:[email-masked]] On 
>>>> Behalf Of ext Cullen Jennings
>>>> Sent: Wednesday, October 07, 2009 1:53 AM
>>>> To: P2PSIP WG
>>>> Subject: [P2PSIP] New versions of RELOAD and sip draft
>>>>
>>>>
>>>> I just submitted
>>>> draft-ietf-p2psip-base-04
>>>> and
>>>> draft-ietf-p2psip-sip-02
>>>>
>>>> These contain technical changes but do not have a lot of editorial 
>>>> changes. At some point we need to go and reorganize the documents 
>>>> with editorial changes.
>>>>
>>>> Cullen <in my individual contributor role>
>>>>
>>>> _______________________________________________
>>>> P2PSIP mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/p2psip
>>>>       
>>> _______________________________________________
>>> P2PSIP mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/p2psip
>>>     
>>
>> _______________________________________________
>> P2PSIP mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/p2psip
>>   
>_______________________________________________
>P2PSIP mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/p2psip

---

From: "neil.young" <[email-masked]>
Date: Fri, 23 Oct 2009 22:26:59 +0200

Given a chord ring of 100 - 200 - 300 - 400 - 500 - 600 (back to 100) 
and considering to fight a high churn rate of 400 and 600, than a "new 
ID" for 500 (e.g. somewhere around 150) would be good for 500, but 
wouldn't be of help for the whole topology. Similarity: You are in a 
cinema and unfortunately sitting between two persons, constantly talking 
to each other. You could choose a new free seat somewhere off the 
middle, where you have been sitting up to now. That would probably help 
you, but wouldn't make the situation much better for the whole bunch of 
visitors :)

Of course the hyperventilation of 400 and 600 might be annoying, but the 
ring has to have the ability to always stabilize and cope with this. A 
new ID - don't know, where this privileged seat should be come from :) 
I'm not aware of having read about such means anywhere.

Regards

---

From: jc <[email-masked]>
Date: Fri, 23 Oct 2009 20:07:48 -0400

In section 3.2.1.  Client Routing contains two algorithms for Client  
routing. if you choose either of those algorithms then this won't be a  
problem.

The first algorithm would forward through 500 around to 600(a direct  
connection).

The second would use the destination list and form the route to 600 by  
storing information in the hash table.

Finally, it is up to the Topology Plugin to ultimately handle this  
which Chord does so fine under this condition via it's own update 
(stabilization) procedures.

Julian

On Oct 23, 2009, at 3:47 PM, [email-masked] wrote:

> IMHO Lin Xiao has a quite valid point. If due changes of topology,  
> node 500 permanently loose its ability to interconnect with close  
> ( in DHT space) nodes, it has to be excluded from DHT ring or have  
> to get a new ID.
>
> Otherwise, it will became a permanent dead-end node for lookups for  
> targets in its immediate neighborhood that significantly degrades  
> speed of DHT lookup and ( under some conditions) can event result in  
> DHT space segmentation.
>

---

From: "Xiao, Lin (NSN - CN/Beijing)" <[email-masked]>
Date: Mon, 26 Oct 2009 14:18:40 +0800

Hi Julian,

You are right. But it's Client Routing for clients, right?  A peer,
however, can not attaches arbitrarily on the overlay. That is the exact
difference between peers and clients in my previous e-mails. If what you
mean is that peers can also been found by algrithm 2 when it lost its
position in the overlay, the overlay would be messed up with disordered
topology structure finally.

Br
Lin

-----Original Message-----
From: ext jc [mailto:[email-masked]] 
Sent: Saturday, October 24, 2009 8:08 AM
To: [email-masked]
Cc: Xiao, Lin (NSN - CN/Beijing); [email-masked]; [email-masked]
Subject: Re: [P2PSIP] New versions of RELOAD and sip draft

Finally, it is up to the Topology Plugin to ultimately handle this which
Chord does so fine under this condition via it's own update
(stabilization) procedures.

Julian

On Oct 23, 2009, at 3:47 PM, [email-masked] wrote:

> node 500 permanently loose its ability to interconnect with close ( in

> DHT space) nodes, it has to be excluded from DHT ring or have to get a

> new ID.

>> successorcache the predecessor of 400 will notice the absence and 
>> bridge directly to 500 as well as 500 will skip 600 after a short 
>> time and go to 700 (in order to stay in the picture).  Using notify 
>> the ring will close again. 400 and 600 may return whenever they want.
>>
>> Regards
>>
>>
>>> Maybe I'm wrong, but I consider peers in RELOAD are structured with 
>>> a DHT algorithm, e.g., in Chord, peer with Node-ID 500 is connected 
>>> with peer 400 and 600.
>>>
>>> connections due to mobility and NAT, but can set up new ones with 
>>> peer 100 and peer 300? IMHO, in order to keep the topology 
>>> structured, if this node still want to be a peer in the overlay it 
>>> should change its Node ID to, say 200, and rejoin the overlay to 
>>> enable itself still reachable with the DHT algorithm.
>>>
>>> If peers in a overlay can not be connected with a strict order, the 
>>> DHT algorithm for structured topology will not work anymore.
>>>
>>>
>>> Br
>>> Xiao, Lin
>>>
>>> simply retain it and connect again as a Client when the network is 
>>> back up.
>>>
>>> Julian
>>>
>>>> attaching peer. The most important thing here is that, this 
>>>> behavior make it possible for a client  to keep session continuity 
>>>> while its attaching peer is switched.
>>>>
>>>> Considering to deploy  RELOAD in reality, stable nodes are 
>>>> preferred to work as peers while mobile nodes can take the 
>>>> advantage of the client behavior mentioned above. Sessions can be 
>>>> kept with high mobility, as unique Node ID is maintained by 
>>>> clients. I'm not sure if RELOAD has considered this distinction of 
>>>> client, which help clients to be attached with the ovelay as long 
>>>> as it can build at least one connection to the overlay.
>>>>
>>>> Br
>>>> Xiao, Lin
>>>>
>>>>
>>>>
>>>>> although, the second sentence implies that clients are also 
>>>>> involved in, I still suggest to replace the "peers" in the first 
>>>>> sentence with
>>>>>
>>>
>>>

>>>> things like this.
>>>>
>>>>
>>>>> In my opinions, connection setup and maintenance between client 
>>>>> and its connected peer (responsible peer or arbitrary peer) is a 
>>>>> key issue for client support in RELOAD.  My question is: Does a 
>>>>> peer in RELOAD distinguish if the connection is to a peer or to a 
>>>>> client?

>>>> when to a peer or client. Clearly how data replication is handled 
>>>> and some of the finger table stuff is handled differently but I 
>>>> think that
>>>>
>>>
>>>
>>>> is covered in the draft. If you see something specific missing, let

>>>> me

>>>>> Destination List to the client? So that it can still be accessed 
>>>>> by other nodes. Or should the Destination List been stored with 
>>>>> some usage, say SIP Usage?
>>>>>

>>>> agree that it needs to allow storing multiple Node IDs but I think 
>>>> it already does that.
>>>>
>>>>
>>>>> In current SIP
>>>> specifying arrays might seem a bit weird but I think the structure 
>>>> is what you are pointing out we need to have.
>>>>
>>>>
>>>>> client could meet or at least clearly distinguish issues of 
>>>>> clients, especially for arbitrary connected ones, which are left 
>>>>> to be solved by other drafts. Thanks.
>>>>>
>>>>>
>>>>> Best Regards,
>>>>> Xiao, Lin
>>>>>
>>>>>

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 26 Oct 2009 16:47:03 +0100

I think peers can connect in the same ways as clients.

On Oct 26, 2009, at 7:18 , Xiao, Lin (NSN - CN/Beijing) wrote:

> which
>> ( in