> > > 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. >
This is what I was referring to as the load balancing and distribution of data problem in my email. Ultimately, to support all kinds of usages on overlays, this must be generically addressed - there is always the problem that a particular metadata or keyword is popular and it maps to one node. Addressing it with a special design for TURN doesn't seem appropriate to me. Load balancing and caching for performance and replication for availability must be provided as fundamental additions to RELOAD and these will help TURN just as they help any other usage on the overlay. Thanks, Vidya > 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
