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
