On Sat, Nov 15, 2008 at 8:31 PM, Narayanan, Vidya <[EMAIL PROTECTED]> wrote: > >> I am really unconvinced that mobile devices in an overlay >> consisting mostly of wired devices should be peers. >> Particularly in an enterprise environment, I don't think this >> is justifiable. >> > > I don't quite understand what locality awareness has to do specifically with > mobile devices. It is much more generic than that. And, the kind of gains we > are talking about in latency makes it definitely worth it. >
Reread the text I was responding to that was directly above that sentence. It said that mobile devices justified locality awareness. >> > 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. >> > >> >> That's fine. It requires no changes to the current draft >> other than for the draft to recommend a basic way to select >> finger table entries but allow that other methods are >> acceptable as long as the finger table entries are valid for >> that range. The RouteQueryReq already handles probing for >> the existing neighbors. >> > > Unless I'm missing something about the RouteQuery messages, I don't think > this is enough. This message will return the next hop towards the > destination. If a particular resource id maps to itself, it is not going to > return its neighbors from what I can tell. What you need are hooks in the > protocol to obtain information about a node corresponding to a point in the > id space and some number of its predecessors and successors. For now, all we > would need the draft to specify is the messaging for this. We don't have to > get into how the fingers themselves are chosen here. > RouteQueryReq can be used to request that the responder sends an Update. The Update conveys the information you are seeking. Bruce > Vidya > > >> Bruce >> >> >> > 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 >> _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
