Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs

On 13 Feb 2014, at 15:17 pm, Simon Perreault <simon.perreault@viagenie.ca> wrote:

> Le 2014-02-12 22:40, Tirumaleswar Reddy (tireddy) a écrit :
>> There are other ways to solve the problem for example using PCP.
> 
> True.
> 
>> Can you clarify how deploying a TURN server in the Enterprise
>> protects the users and the network ?
> 
> IMHO that's not the right question to ask. It is pretty clear to me
> that, technically, TURN does indeed have the potential to solve the
> problem identified by Karl. (I understand the problem to be: "ISP wants
> to provide enhanced QoS to WebRTC.")
> 
> I have two questions in my mind:
> 
> a) Is this a real problem that is worth fixing?
Yes.. But not just QoS. There should be some kind fairness and “share the resources” so everyone can get the best result. If the link is getting crowed it would be nice of the endpoint than can would for example reduce its bandwidth by dropping from 1080p to 720p. Tis have some impact on user experience, but uses half the bandwidth. 

I would like us to move away from hard reservations as that does not give us the best usage of a scarce resource (bandwidth) as video codecs are very elastic in its nature and it would be hard to know how much bandwidth to allocate for a video stream. 

But i might be dreaming.

> b) Is TURN the best, most appropriate solution?
> 

Probably a part of the solution, It is a nice way of “forcing” media through a certain path. But I think that path only should be chosen by the endpoint if that is the best(*1) path.   (*1) For certain values of best..

I have been planning to write a draft: POLICE, Path Optimisation done Locally with ICE. But that probably belongs to MMUSIC. But to get that of the ground we need to figure out how to get more information from the network regarding bandwidth, cost and other decisions that might influence the path selection. (RTT we get from the connectivity checks). That would be something for the TRAM WG to figure out.. (And maybe the PCP WG)

Another thing to remember is that webRTC is probably going to use Trickle-ICE. In clear that means the host candidates will be tested as soon as they are ready. The rest of the candidate discovery might happen in parallel or after. This might affect how we discover the available TURN servers.

Due to security concerns the webRTC also severely limits the speed the connectivity checks happen. So unless Trickle ICE is in use it is good to keep the number o candidates to a minimum.  

.-.
Pål-Erik

> Simon
> -- 
> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
> STUN/TURN server               --> http://numb.viagenie.ca
> 
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram