On Tue, May 12, 2009 at 2:44 PM, Narayanan, Vidya <[email protected]> wrote: > <snip> > >> > Joining (Section 9.5): >> > ---------------------- >> > It is not clear why the join procedure requires all neighbor and >> finger connections to be established prior to sending the JOIN message >> itself. To be functional in the overlay, only the immediate successor >> relationships must be correctly in place. The other successors, >> predecessors and fingers can be established subsequently. This also >> doesn't cause nodes to establish unnecessary connections unless the >> node has successfully joined. There is also the question of whether a >> JP is supposed to establish a TLS connection to the BP to send messages >> through it, which is presently not addressed in the draft. It seems to >> me that a more streamlined join process can be defined as follows: >> > >> >> You're right that it's just an optimization to have finger table >> entries, but it's not completely clear to me that adding a new peer >> without finger table entries provides a benefit to the overlay. I can >> see that being a SHOULD, though. >> > > The finger entries must be added upon Join. I'm not saying that the peer can > wait longer to do that. However, there is no gain in doing the finger > connections upfront - it is not like the AP or any node tries to verify that > has happened. So, in terms of processing the join, it is the same. And, it > makes more sense to go through those after a successful join, rather than > having to tear down if the node is unable to join for any reason. >
In terms of processing the join, completely agree, but in terms of overall overlay routing efficiency, it's better to delay the join until the finger table connections are complete, otherwise you add more linear routing to the overlay. Difficult to compare routing efficiency vs the odds that a node is unable to join, but my instinct leans toward routing efficiency. > <snip> > >> > Further, having the enrollment server involved in specifying the >> frequency of updates and probes seems strange. How is the enrollment >> server supposed to know the magic values here? It seems like it should >> be enough to specify a recommended value and leave it at that. Since >> the finger stabilization is for optimization and the neighbor >> stabilization is reactive anyway in the present draft, having these >> parameters in the config document seem to be of little use. >> > >> >> Are you revisiting the issue of wanting to split the authority for >> enrollment and config files, or are you questioning whether it should >> be possible to specify update frequency in a config file at all? >> > > The latter - I'm not seeing a need for these being configurable. > I'm inclined to leave them configurable unless there is a significant reason not to. I'm actually inclined to make quite a few of the other constants specified in the current draft configurable. >> >> > Finger entries (Section 9.7.3 and elsewhere): >> > --------------------------------------------- >> > The draft requires 16 finger table entries - at first, I took those >> to mean 16 different resource ids that will be probed per formula. >> After reading 9.7.3, it appears that it is talking about 16 different >> fingers that a node should maintain. In a small overlay, that's >> ridiculously large. The text is also unclear on what happens when the >> overlay shrinks. Further, the text states that a peer SHOULD consider >> the finger table entry valid if it is in the range [n + >> 2^(numBitsInNodeId-i), n + 1.5 x 2^(numBitsInNodeId-i)]. For small >> overlays, there may be no entries in this range for every i in [0, >> 127]. >> > >> >> The text was left the way it is in an effort to make it simpler, but I >> think there may be an issue in there where too many MUSTs are >> prohibiting common optimizations. Definitely need to take a look at >> that. I think the right answer here is to check the existing text for >> being too pedantic and compare its length & complexity with the >> optimization you describe (which I agree is how this should really be >> implemented). >> > > I don't believe the current text is implementable - it is confusing at best. > It needs to be reworded for clarity. A rewording along the lines of what I > wrote is one possibility. > Will definitely make a pass at that. Thanks for the text. Bruce > Best, > Vidya > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
