Saumitra, You're absolutely right in the advantage of including topology information in picking finger table entries. However, one of our goals in the base draft is to minimize complexity where possible. In this case, many application scenarios for p2psip are on a LAN (office phone system, voicemail server cluster) and so don't need this complexity. Therefore, we'd rather avoid adding this to the base draft as it would both complicate the overlay algorithm and require diagnostics in every implementation.
I think there are two ways to address your concern without adding complexity, however: - we expect new overlay algorithms to be proposed, especially a better DHT for Internet-scale use. Would really like to see that. - The terminology in the stabilization section doesn't use MUST to describe how finger table entries are found. I can work on the wording a little bit to state that there may be alternative methods for selecting good entries. Bruce On Thu, Nov 13, 2008 at 8:18 PM, Das, Saumitra <[EMAIL PROTECTED]> wrote: > I would like us to consider including locality awareness in the default > topology plugin that is being proposed in p2psip-base. Through simulations of > large scale overlays, I have observed a reduction in lookup delay of 40-45% > using such a technique. > > Making progress in the identifier space can be expensive in terms of network > latency. A successor and predecessor list can be used to optimize network > latency by relaxing the requirement for finger selection. Specifically, for > each finger table entry, a node A first determines a node X that matches the > identifier of the finger. It then retrieves the successors and predecessors > of X from X. Node A then PINGs the successors and predecessors of node X and > chooses the topologically closest node among these as the choice for the > finger table entry. The sizes of the successor and predecessor lists have an > impact on network latency; the larger the value or these, the higher the > probability of finding a topologically close finger table entry. > > Note that having successor and predecessor lists have been alternately > proposed for improved robustness to failures and preventing the partition of > a Chord network. We can have this benefit as well as the benefit of better > lookup performance using locality awareness by exploiting this extra > information. Some of the methods proposed in p2psip-diagnostics can be used > for choosing the finger table entry. If the usage wants to avoid measurement > overhead, virtual cooridnate systems such as GNP, vivaldi could be used to > select a peer for locality awareness as well. > > > A simulation study with a different simulator in Ref 1 using 2^16 nodes and > an euclidean RTT model and transit-stub model showed lookup stretch > reductions of 31% to 40% as well. > > Ref 1: "Chord: A Scalable Peer-to-peer Lookup Service for Internet > Applications", IEEE/ACM Transactions on Networking, vol 11, 2003." > > Thanks > Saumitra > > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
