1. About data insertion procedure. A new data storing request should first arrive at the physical node which primary ID is the immediate successor of the object ID, then be dispatched to the neareast secondary node in the physical node?
Yes. This is correct. 2. Can secondary ID migrate dynamically among peers? Primary IDs are fixed and a node has one primary ID assigned for its lifetime on the network similar to base RELOAD. The secondary IDs change dynamically as required (for example, during adding or removing nodes as in our update algorithm). I guess this is what you are asking or maybe I am misunderstanding your question. An id cannot be handed off between peers. 3. In some managed p2p systems, performance is critical, so O(1) DHT is the preferable algrithm. For O(1) DHT, extra O(LogN) hops introduced by load balancing may be too large. In the basic form, you would require O(log N) to get to the primary virtual node closest to the object ID (via Chord/Pastry etc.), and then an additional O(log N) hops to get to the correct physical node. The latter step is usually random-walk based where you just walk backwards from the primary virtual node until you get to a physical node that owns the object ID. Now, the step 1 can be easily implemented over a O(1) DHT just by replacing the Chord/Pastry like topology with the corresponding O(1) DHT. There are several proposals in research papers to do this. In Pastry you could vary the system parameters to achieve this. If we want to make the random walk part also O(1), then the easiest way to do it is by including more neighbor state (e.g. O(log N) neighbors in addition to O(log N) fingers) in the node so that the object can be routed to the exact ID in O(1) hops. So yes, in managed backed p2p systems which may not be too concerned with higher overhead as generic p2p systems, the scheme can be extended. Thanks Saumitra From: [email protected] [mailto:[email protected]] Sent: Sunday, March 08, 2009 8:58 PM To: Das, Saumitra Cc: [email protected]; Das, Saumitra Subject: RE: [P2PSIP] New Load balancing in RELOAD draft Hi saumitra thanks for your clarification. I read the article again, and still was wondering that: 1)About data insertion procedure. A new data storing request should first arrive at the physical node which primary ID is the immediate successor of the object ID, then be dispatched to the neareast secondary node in the physical node? Can secondary ID migrate dynamically among peers? 2)About performance. In some managed p2p systems, performance is critical, so O(1) DHT is the preferable algrithm. For O(1) DHT, extra O(LogN) hops introduced by load balancing may be too large. "Das, Saumitra" <[email protected]> 2009-03-07 05:00 收件人 "Das, Saumitra" <[email protected]>, "[email protected]" <[email protected]> 抄送 "[email protected]" <[email protected]> 主题 RE: [P2PSIP] New Load balancing in RELOAD draft Just a clarification 3)Could the imbalance factor be reduced further? Yes. The simplest way is by increasing alpha or by increasing delta. However, if you increase alpha or delta too much then routing would become less efficient requiring more than O(log N) hops. A more complicated way to reduce the imbalance factor is by employing a hierarchical approach by clustering nodes into groups (doing the scheme in that group) and then do the same scheme on the supergroups as a whole. This can get complicated and we stayed away from it to keep the proposal simple. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Das, Saumitra Sent: Friday, March 06, 2009 12:58 PM To: [email protected] Cc: [email protected] Subject: Re: [P2PSIP] New Load balancing in RELOAD draft Hi Russell, Thanks for going through the draft. 1)Does the finger table only include the primary virtual node ID? The finger table only includes the primary virtual IDs. Routing always happens in two steps. In the first step, you can just imagine that you don’t have the secondary virtual node IDs and just have the primary ones. Then, as in the case of Chord, you would use the primary IDs to route the request to the primary ID closest to the object. At this point, the node that receives the request checks if it owns that part of the ID space. If yes, it simply returns the object/response. If no, then it uses the neighbor tables to route the requests. This would take a maximum of O(log N) additional hops. 2)How to change the estimated N parameter and keep the services non-stopping? Supposing that it has been far away from the actual network scale. I don’t think there will be a situation where it is far away from the actual network scale since the fingers keep updating as and when the network grows. In some ways, the update algorithm will ensure that this situation would not arise. In the worst case, if the situation happens to arise, then that would imply that this particular node is highly imbalanced and is handling a very large amount of load. Therefore, it would be of benefit for the node to offload some of its load. The change can be done by leaving joining the network with a new set of virtual ids and leaving the network with the old ones. This can be done slowly without afffecting services (not leave and join at the same time with all the virtual node ids). 3)Could the imbalance factor be reduced further? Yes. The simplest way is by increasing alpha or by increasing delta. However, if you increase alpha or delta too much then routing would become less efficient requiring more than O(log N) hops. A more complicated way to reduce the imbalance factor is by employing a hierarchical approach and building Y0 over another Y0. Thanks Saumitra From: [email protected] [mailto:[email protected]] Sent: Tuesday, March 03, 2009 10:59 PM To: Das, Saumitra Cc: [email protected]; [email protected] Subject: 答复: [P2PSIP] New Load balancing in RELOAD draft I have read your article, and agree that load balancing is a key issue especially when we deploy the backend server systems built by p2p technology. Some questions following: 1)Does the finger table only include the primary virtual node ID? 2)How to change the estimated N parameter and keep the services non-stopping? Supposing that it has been far away from the actual network scale. 3)Could the imbalance factor be reduced further? Russell Wang [email protected] 写于 2009-03-04 09:10:51: > Hi all, > > I just submitted a draft that proposes a load balancing solution for > the default DHT in RELOAD. Comments are appreciated. > > http://www.ietf.org/internet-drafts/draft-saumitra-p2psip-loadbalance-00.txt > > Best, > Saumitra > > > > > www.saumitra.info > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
