The point about mobile devices was made in response to your comment that many p2psip application scenarios are just for LAN (office systems etc). I was trying to point out that in many enterprises people may not even have a fixed desktop and use wireless LAN/ethernet docked laptops. That specific comment was not really targeted at justifying locality awareness which applies to fixed desktop based overlays as well. I just mentioned in passing that mobile devices would introduce more scenarios where locality awareness is useful due to the potential geogrpahic spread of the overlay. However, even fixed desktop based overlays are likely to have large enough geographic spread to justify locality-awareness.
Thanks Saumitra -----Original Message----- From: Bruce Lowekamp [mailto:[EMAIL PROTECTED] Sent: Saturday, November 15, 2008 5:55 PM To: Narayanan, Vidya Cc: Das, Saumitra; [email protected] Subject: Re: [P2PSIP] Suggested enhancement for default Chord topology plugin 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
