Hi, I also like (3). But a peer can not make sure that his neighbor must have a peer of public address (i.e, its neighbor peer can act as a TURN server); so in order to improve the lookup success rate for TURN server, we can do as follows: if there is no TURN server in his neighbor peers, it can ask its neighbor peers to ask their neighbor peers until finding a TURN server or failed due to scope limit.
So maybe we should extend the searching scope by defining a new message like LookUpServicePeer in SEP( http://www.p2psip.org/drafts/draft-jiang-p2psip-sep-01.txt ) to improve the searching success rate. In order to make the lookup operation successful when a peer reaches the destination peer, the key for the lookup message can be set to a key which is hashed by a standard service name, for example, turn.exaple.com; On the other hand, we can add replica parameters to a standard service name to make the resource stored in several separated locations in DHT. It may improve load balance of the look up operation. Regards Jiang XingFeng > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Salman Abdul Baset > Sent: Wednesday, March 25, 2009 2:14 PM > To: Narayanan, Vidya > Cc: [email protected] > Subject: Re: [P2PSIP] TURN usage in RELOAD > > > Multiple peers can provide the TURN service. Using a single name for TURN > service has the problem that H(turn_service_name) maps to a single node. > This implies that all STORE and FIND requests can potentially terminate at > a single node, overburderning it, and creating a single point of failure. > > 1) The written text is one way to address this problem. > > 2) The ReDiR approach proposed in OpenDHT paper also addresses this > problem. It stores the TURN record under a two-dimensional tree. A TURN > record is stored under H(turn_service_name + L + rand[1,2^L) ) > > where L is the level of the tree, starting from 0. > > 3) Another approach is to only admit nodes in the overlay that can provide > the TURN service. This means that all peers in the routing table of a peer > can potentially provide the TURN service. A client looking for a TURN > server asks its peer, which returns a peer providing the TURN service from > its routing table. This approach works both for DHTs and unstructured > networks. > > Assuming the default overlay algorithm is a DHT, I prefer the ReDiR > approach as the generic mechanism for TURN server discovery because it is > deterministic in nature than (1). However, this is something the WG can > discuss. > > For Internet deployments with sufficient number of peers with public IP > addresses, I prefer (3) because the lookup time is O(1). > > -s > > On Tue, 24 Mar 2009, Narayanan, Vidya wrote: > > > The currently specified TURN usage in RELOAD is rather odd to me. I suppose > it tries to load balance and spread the storage of TURN server information in > various parts of the overlay. But then, load balancing and distribution of > popular data is a much more generic problem that needs to be handled in a > fashion > independent of the usage anyway. > > > > In the current definition, a node looking for a TURN server keeps looking > up a random resource ID until it finds a match for data corresponding to the > TURN-SERVICE type. This seems rather inefficient to me. It also puts yet > another somewhat dynamic parameter into the configuration document > (turnDensity). > > > > It seems that a far simpler design would be to treat it like a generic > > keyword > storage, where a TURN-SERVICE kind stores data at a location corresponding to, > say, h(TURN). It is a well-known resource name that will allow nodes to find > a TURN server in a deterministic fashion. This can utilize the authorization > model where any node can write to that resource id, but only the creator is > allowed to modify its own entry. In any event, a node-id based authorization > is quite irrelevant for this service. > > > > Any load balancing or caching of information at other points in the overlay > should be handled by generic mechanisms that can be used by any usage on the > overlay. In fact, simple on-path caching will allow permeation of this data > in various parts of the overlay rather quickly, since many nodes are likely > to look for TURN services. > > > > Vidya > > _______________________________________________ > > P2PSIP mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/p2psip > > > > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
