On Sun, Nov 16, 2008 at 3:38 AM, Das, Saumitra <[EMAIL PROTECTED]> wrote: > 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. >
Fully agree. Bruce > 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
