Hi Bruce, >The first is to use CONNECT >(essentially ICE) to initiate a direct connection between the >peers.
Could you please explain why you want to use P2P layer methods on the SIP layer (application layer)? Do you expect all SIP UAs to implement P2PSIP? Marcin >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >On Behalf Of ext Bruce Lowekamp >Sent: Tuesday, March 11, 2008 10:50 PM >To: Henry Sinnreich >Cc: [email protected] >Subject: Re: [P2PSIP] Random resource probe > > >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 > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
