Subject: [P2PSIP] TURN usage in RELOAD

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 24 Mar 2009 22:34:15 -0700

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

---

From: Salman Abdul Baset <[email-masked]>
Date: Wed, 25 Mar 2009 02:14:19 -0400 (EDT)

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:

> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip
>
>

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 24 Mar 2009 23:39:11 -0700

> a single node, overburderning it, and creating a single point of

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 

> > 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

---

From: jiangxingfeng <[email-masked]>
Date: Thu, 26 Mar 2009 09:18:51 +0800

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-masked] [mailto:[email-masked]] On Behalf Of
> Salman Abdul Baset
> Sent: Wednesday, March 25, 2009 2:14 PM
> To: Narayanan, Vidya
> Cc: [email-masked]
> Subject: Re: [P2PSIP] TURN usage in RELOAD
> 
> 
> > 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