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 protected]] >> 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 protected]] >>> 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 protected] [mailto:[email protected]] 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 protected] >>>> https://www.ietf.org/mailman/listinfo/p2psip >>>> >>> _______________________________________________ >>> P2PSIP mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/p2psip >>> >> >> _______________________________________________ >> P2PSIP mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/p2psip >> >_______________________________________________ >P2PSIP mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
