[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [P2PSIP] New versions of RELOAD and sip draft
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:julian at orchidseed.org]
>> 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:fluffy at cisco.com]
>>> 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: p2psip-bounces at ietf.org [mailto:p2psip-bounces at ietf.org] 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
>>>> P2PSIP at ietf.org
>>>> https://www.ietf.org/mailman/listinfo/p2psip
>>>>
>>> _______________________________________________
>>> P2PSIP mailing list
>>> P2PSIP at ietf.org
>>> https://www.ietf.org/mailman/listinfo/p2psip
>>>
>>
>> _______________________________________________
>> P2PSIP mailing list
>> P2PSIP at ietf.org
>> https://www.ietf.org/mailman/listinfo/p2psip
>>
>_______________________________________________
>P2PSIP mailing list
>P2PSIP at ietf.org
>https://www.ietf.org/mailman/listinfo/p2psip