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
