Hi Bruce, While there are application scenarios for LAN, even if we take an enterprise we are already seeing increasing use of enterprise mobile devices which sort of take this problem to a larger scale. Even if the enterprise itself may be in a few locations, the people part of the overlay could be spread out while traveling and once again locality awareness would come into play.
In order to support it either as a better topology plugin to be proposed in the future or as part of the default DHT, what we need is the capability in the protocol to request the neighbor list of a targeted finger entry and receive it. I concur with your concern about not adding complexity. However, I would argue that locality selection does not add much complexity to the system. A peer gets a list of peers in a ID neighborhood, pings those peers, and chooses the one with the lowest RTT as a finger. The draft would need to support the ability for a peer to give another peer a list of its id space neighbhors. A ping message is already supported, so no additional change is required for that. The exact details of how many neighbors to ping, how many pings to send, etc. can be left to the implementation to reduce the complexity of the base draft. When put in the context of everything else that the base draft would specify, this may not be significantly complex. So while I concur that simplicity is an important design criterion, locality awareness designed in this way is in the spirit of that criterion and results in worthwhile gains. Thoughts? Thanks, Saumitra -----Original Message----- From: Bruce Lowekamp [mailto:[EMAIL PROTECTED] Sent: Friday, November 14, 2008 4:35 AM To: Das, Saumitra Cc: [email protected] Subject: Re: [P2PSIP] Suggested enhancement for default Chord topology plugin 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
