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

["Karl Stahl" <[e-mail]>]

Interesting thoughts, inline comments below -->

-----Ursprungligt meddelande-----
Från: tram [mailto:[e-mail]] För Pal Martinsen (palmarti)
Skickat: den 13 februari 2014 15:40
Till: [e-mail]
Kopia: Simon Perreault
Ämne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for
enterprise and ISPs


On 13 Feb 2014, at 15:17 pm, Simon Perreault <[e-mail]>
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. 

[Karl] Have you noticed that Google does this in Chrome/VP8 already? When
getting bad network conditions (you see disturbances in the video), the
video screen shrinks to reduce bandwidth usage. That is "some kind fairness
and share the resources" intent, but unfortunately not very effective, since
the bandwidth reduction in practice is given back to TCP (non-real time
traffic) streams filling the pipe. That is the way TCP (data) vs. UDP
(media) today share the Internet pipes (UDP makes TCP streams reduce their
bandwidth usage at congestion time - and that is also reversed when reducing
UDP) by backing off TCP. That is why we need to be able to apply "traffic
shaping" at lower network levels. 

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. 

[Karl] True!

But i might be dreaming.

[Karl] Are you? :)
I will comment further/elsewhere on the DISCUSS/MALICE draft, which I see
related to this


> 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..
[Karl] Agree, but the path to be chosen by the endpoint, can only be
advised/offered by the ISP/NSP if it is within their network the quality
fixes have to be done.

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)

[Karl] Yes, and I see DISCUSS/MALICE (that has been mentioned by Justin and
others here) as one step to do this.

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.

[Karl] There must be some recommendation of such ICE usage, to ensure that
the quality path (if available) is chosen - Yes! 

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.  


[Karl] Enforcing a specific TURN-path, will reduce the number of candidates,
so maybe Tickle-ICE does not even have to be used, when there are a an
ISP/NSP adviced/offered TURN servers to use



.-.
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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tram

_______________________________________________
tram mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tram