On Thu, 24 Jul 2008, Bruce Lowekamp wrote:
I think this issue should be split up:
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
specified?
No. At best, it can be a BCP document.
-s
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
