Subject: [P2PSIP] Mechanisms for inserting TURN server

From: Cullen Jennings <[email-masked]>
Date: Wed, 16 Jul 2008 12:05:22 -0700

Different overlay might want to have different ways of deciding how to  
find TURN servers and identifying what servers should be TURN servers. 
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: Bruce Lowekamp <[email-masked]>
Date: Thu, 24 Jul 2008 16:28:37 -0400

Cullen Jennings wrote:
> find TURN servers and identifying what servers should be TURN 
> servers._______________________________________________
> P2PSIP mailing list
> [email-masked]

I think this issue should be split up:

1) should service discovery be part of the base protocol?  If so, what 
service discovery algorithm should be specified? (the current draft 
mentions ReDIR and describes a very simple mechanism for discovering 
TURN servers, which should work well for a known density of TURN servers)

2) should a mechanism for identifying the ability to be a TURN server be 
specified?

It adds complexity, but I'm afraid that there should probably be a 
mandatory service discovery algorithm for (1).  The existing algorithm 
in Section 9 actually isn't too bad if you can estimate the density 
parameters in advance.  It's certainly easier than requiring everything 
to implement ReDIR.  Is it good enough?

I would really, really like to label (2) as out of scope for the base 
(or mandatory portion of) protocol.

Bruce

---

From: Salman Abdul Baset <[email-masked]>
Date: Thu, 24 Jul 2008 17:08:41 -0400 (EDT)

On Thu, 24 Jul 2008, Bruce Lowekamp wrote:

> 1) should service discovery be part of the base protocol?

There are two issues:

1) Should service discovery be a *usage* of base protocol?
I think yes.

2) Should service discovery mechanism as a usage be specified in the base 
protocol?

> If so, what 
> service discovery algorithm should be specified? (the current draft mentions 
> ReDIR and describes a very simple mechanism for discovering TURN servers, 
> which should work well for a known density of TURN servers)

Service discovery algorithm is tied to the overlay algorithm 
(DHT/unstructured). ReDiR is a DHT(Bamboo)-specific approach for service 
discovery.

The complexity of service discovery algorithm depends on the underlying 
scenario. ReDiR is a good solution for the case when there are multiple 
peers providing the same service. When this is not the case, defaulting to 
ReDiR for service discovery is inefficient.

Also, if every node is a TURN server, discovering them is a non-issue.
This is so because a node can simply obtain the routing table of any peer, 
and every peer in the routing table is a TURN server.

Due to above dependencies, I think it is best to leave service 
discovery out of the base protocol. There could be a BCP specifying 
various mechanisms.

> 2) should a mechanism for identifying the ability to be a TURN server be 

No. At best, it can be a BCP document.

-s

---

From: jiangxingfeng 36340 <[email-masked]>
Date: Fri, 25 Jul 2008 11:04:51 +0800

> TURN servers, which should work well for a known density of TURN 

I think yes. Service discovery mechanism proposed by SEP could be a candidate. 

> to implement ReDIR.  Is it good enough?

I don't think estimate the density parameter is a good choice. Overlay is dynamic network, and the density is changing over time.  On the other hand, the method could not work under unstructured network. 

> (or mandatory portion of) protocol.

I have a question, if we could not identify a peer to be capable of a TURN server, how could the overlay estimates the density? 

Regards
---
Jiang XingFeng

---

From: jiangxingfeng 36340 <[email-masked]>
Date: Fri, 25 Jul 2008 11:28:52 +0800

> 1) Should service discovery be a *usage* of base protocol?

I think service discovery should be part of the base protocol. But it does require the service discovery SHOULD be a usage. In unstructured network, making each node spread its capability information is a good method to do service discovery. So does in structured network. It may not conform to the usage concept in the base protocol. 

> (DHT/unstructured). ReDiR is a DHT(Bamboo)-specific approach for 

Method in SEP making built-in overlay manitenance method is a general method, and it could work with different algorithms. 

Maybe I am missing something, but I have a question about ReDiR. As I know, ReDiR works with OpenDHT, which is a overlay being comprised of stable peers and whose goal is to support new service without modify core OpenDHT infrastructure. As for ReDir, it relies on the peer on the core OpenDHT infrastructure to store all information about clients( in OpenDHT terminology) to organize a tree to locate which peer could provide which kind servic
e. It seems all work is done on a stable peer and does not fit in distributed situation like structured/unstructured algorithm?  comments?

> No. At best, it can be a BCP document.
I think we should has a draft to give guidance to implementators on how to identify it. IMHO, bootstrap peer, TURN server, Relay Peer (proposed in SEP) have some requirements in common, for example, it should hava a public address and no firewall or behind address-independent firewall. We could work out a draft to address these commone requirement. comments? 

Regards!
JiangXingFeng

---

From: jiangxingfeng 36340 <[email-masked]>
Date: Fri, 25 Jul 2008 11:31:13 +0800

> I think service discovery should be part of the base protocol. But 
> it does require the service discovery SHOULD be a usage. In 
> unstructured network, making each node spread its capability 
> information is a good method to do service discovery. So does in 
> structured network. It may not conform to the usage concept in the 
> base protocol. 

Sorry, A typo mistake. I mean "it does not require the service discovery SHOULD be a usage".

Regards!
JiangXingFeng