An example of a "pervasively supported mechanism" is the SEP technique of having the receiver respond not just with whether it has the resource, but whether it knows where to find the resource (from exchanges with its neighbors.) Since that would seem to be independent of any particular usage, it is a mechanism which, if you want it at all, you want supported by every node (i.e. pervasive.) I can imagine other techniques.
If the ReDiR mechanism, and / or the Reload mechanism, are sufficiently robust to work across the range of real world deployments, then thats fine. The fact that my limited intuition on random distributions makes me nervous doesn't mean anything. (Heck, if I hadn't done the analysis years ago I wouldn't believe the numbers about how little overspeed switch cores need to work well.) We are trying to cover a wide range of cases. Yours, Joel PS: The reason I was asking about whether it is a single service (TURN) or multiple is that if we are going to end up with multiple "usages" which are essentially identical, it would be nice not to need to redefine things for each service. As written Reload requires that the usage be redefined each time just to discover another underlying service. Bruce Lowekamp wrote: > I think ReDiR is a good general-purpose service discovery algorithm. It > auto-tunes based on server population, although I'm not entirely > convinced it doesn't have bad behavior in avalanche restart, but there > may be studies on that I'm not aware of. In steady state, I believe > ReDiR to be robust. > > The mechanism currently in reload should work well in deployments where > server population is well known. I suspect that for wide-area overlays, > for example, this is likely to be possible to measure in advance. It > has the virtue of simplicity. > > I'm not sure what you mean by "pervasively supported mechanisms." Both > of these techniques require no support beyond base STORE/FETCH. > > TURN is certainly not the only example. Conference bridges would be > another. > > Bruce > > > > On Mar 10, 2008, at 5:54 PM, Joel M. Halpern wrote: > >> Let me try parsing this another way. >> If the Service location is just a normal lookup, returning normal >> responses, then it clearly needs no support from the P2P layer we are >> defining. >> If pure random probes suffice, then that's enough. >> >> However, if we want any pervasively supported mechanisms in order to >> increase the robustness of the search, then we need a base mechanism >> rather than just a usage. >> >> (Correspondingly, I would like to see some discussion of whether TURN is >> really the only service or this is a general issue. I have not been >> able to discern the answer to that.) >> >> Yours, >> Joel >> >> Bruce Lowekamp wrote: >>> >>> On Mar 10, 2008, at 1:44 PM, Victor Pascual Ávila wrote: >>> >>>> Hi Bruce, >>>> >>>> On Mon, Mar 10, 2008 at 6:28 PM, Bruce Lowekamp >>>> <[EMAIL PROTECTED]> wrote: >>>>> Fortunately, I think service discovery is something >>>>> that can be built on top of the basic mechanism. >>>> >>>> Please, could you elaborate this? >>>> >>>> In SEP, three different service discovery mechanisms can be found in >>>> Section 4.1. We plan to put more effort on this issue. >>>> >>> >>> So I think the key question here (that we need to answer soon) is >>> whether service discovery needs a new method like SEP's >>> LookUpServicePeer method or whether it can simple use FETCH for a >>> particular data type defined by a usage (as reload proposes). >>> >>> I do think that SEP's proposal is an intriguing possibility, but I'm >>> personally not too enthusiastic about a method type that requires every >>> intermediate peer to do processing---I really would like to see message >>> routing being as low-overhead an operations as possible. >>> >>> Anyway, back to my original comment. Most of the service discovery >>> algorithms just rely on FETCH, so there are no changes to the basic peer >>> protocol at all. SEP has a custom method in the peer protocol. I'm not >>> convinced that if you really want to have per-hop additions to a query, >>> that you need a particular method for it or that service discovery is >>> the only possible example of that behavior. But the next question is >>> that if a custom method is needed for service discovery, can we at least >>> build new service discovery algorithms on top of that beyond what are >>> envisioned for the base draft? >>> >>> Bruce >>> >>> >> _______________________________________________ >> P2PSIP mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/p2psip >> > > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
