Hi Henry. Responses inline... On Mar 11, 2008, at 10:15 AM, Henry Sinnreich wrote:
> The missing elements in Reload are well known in the DHT "industry": > > 1. Defining neighbor proximity by > · Delay > · Number of routing hops > · Bandwidth > > 2. Algorithms for fair disk usage, etc. > > 3. Recovery of temporarily ”failed” neighbors that may have been > overloaded due to congestion in the access link or high CPU usage > due to cryptography. > I think this is getting to an important open issue that we need to decide how we will handle (at least in whatever base overlay we agree on). Basically, there is a spectrum of possibilities that range from simple to explain and implement, but not ideal in all deployments to multi-featured, configurable, and complex. maybe(?) scales to different size/types of deployments The DHT in reload-03 (and earlier) leans toward the simpler end of things, largely on the grounds of reducing complexity for ease of implementation. But I think it certainly is an open topic (and likely to be the subject of much debate for some time) where the wg's base overlay should land on this scale. > The above are key ingredients and another reason to decouple the > DHT layer form the application layer; SIP in our case. Hear, hear! > > This decoupling is one of the reasons why I believe P2PP should be > the common starting base for P2PSIP and not Reload for sure. > In Reload (1) routing is duplicated in the DHT and the SIP layers > and (2) coupled for too strong from benefiting of advanced DHT > development. > I'm not quite sure what you're referring to here. 11.2.2 and 11.2.3 describe the two methods of establishing a SIP dialog proposed by reload-03. The first is to use CONNECT (essentially ICE) to initiate a direct connection between the peers. The second is a use of reload's generic TUNNEL mechanism to route the SIP dialog over the overlay as application-level traffic. I believe that both these approaches separate the roles and responsibilities of the various layers appropriately, but am interested in any comments on how this could be improved. Bruce > Henry > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Bruce Lowekamp > Sent: Monday, March 10, 2008 6:58 PM > To: jiangxingfeng 36340 > Cc: [email protected] > Subject: Re: [P2PSIP] Random resource probe > > > On Mar 10, 2008, at 6:48 PM, jiangxingfeng 36340 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. > > Right. If the standard service name method works in all cases, > > there is no need to develop new methods. But in some cases, this > > method has some shortcomings: > > 1. if too much peers providing the same service, and also publish > > the information to the responsible peer fo the service-id gotten by > > hashing the standard service name. So the responsible peer has to > > store so much <key, value> pair; > > > > 2. the other shortcoming is if the service is a popular service, > > all query will go to the responsible peer. It may overload the > > responsible peer. > > This isn't how the service discovery algorithms work (either reload, > redir, or any of the others I can think of). ReDiR, in particular, > is adaptive. In ReDiR, the service providers and the queriers gauge > the population density of the service and use that to select where to > search for the service. There isn't overload on a single responsible > peer. > > In the technique in reload, the data is stored at random locations > and random queries are used to search, so again, there is no overload > on a single peer. > > > > > > > >> If pure random probes suffice, then that's enough. > > Maybe we need collect some experiemental data to see whethere > > random probes could work in most cases. I mean, if the service > > providers could be got within two or three transactions, IMHO, it > > is a reasonable latency. > > > > The technique in reload works fine if you can reasonably accurately > predict the server population. If you can't, it won't work very well. > > 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
