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

From: "Karl Stahl" <[email-masked]>
Date: Sat, 8 Feb 2014 14:11:21 +0100

Karl from Ingate and Intertex just added himself to this list for exactly the purpose of the subject of Milestone 3 above 

I welcome this initiative that I saw yesterday after being reminded by China Mobile Research Institute who had seen the previous October discussion on the WebRTC-list, parts of which are inserted below. Large carriers have also expressed the importance of this milestone.

--------------------

We are working on this draft, will publish it next week.

-Tiru.

Great, please consider the input and suggestions below:

> -----Original Message-----

> From: tram [ <mailto:tram-bounces> mailto:tram-bounces at ietf.org] On Behalf Of Simon Perreault

> Sent: Friday, February 07, 2014 7:58 PM

> To: tram at ietf.org

> Subject: [tram] Milestone 3: TURN server auto-discovery mechanism for

> enterprise and ISPs

…

> Enterprises or ISPs wishing to provide

> their own TURN server, in an attempt to reduce so-called "triangle routing",

> need a new auto-discovery mechanism.

--- There are more reasons heard for auto-discovery of a network provided TURN server:

- NSPs (Network Service Providers) want to provide a path where the bandwidth of WebRTC is better coped with.

- NSPs or Enterprises want to offer an Internet access quality pipe for prioritized RTC (Real Time Communication) traffic. 

- Enterprises having restrictive firewalls, want to provide a UDP-path for WebRTC and possibly also for better quality where RTC do not compete with data traffic. 

- Mobility; It is common to move from a LAN to accessing via WiFi or 3G/4G OTT channels, all should be able to automatically offer their own optimal TURN server

- Note that to achieve some of the above points, TURN must be favored over STUN to enforce that the TURN-path actually is used. (The Anycast method suggested below, “automatically” does this.) 

-- In my view, a TURN server is the network providers’ responsibility to provide (just like the IP address, the default gateway, the DNS etc.) – rather than the application provider’s. Our current Internet accesses may not cope with or be optimized for WebRTC usage – The NSP (or Enterprise LAN administrator) should then be able to fix the access (here by offering a TURN server). 

> IMHO this is also a top-priority milestone. We need to quickly have a

> mechanism that people can implement in WebRTC browsers now, while

> there is still frenetic development happening. 

--- Agree

I don't foresee actual server-

> side deployment happening quickly though. But as soon as clients are ready,

> any ISP or enterprise can deploy and immediately benefit.

- There is a definitive interest among forward SPs already, especially carriers owning the network.

(They have learned that their networks (especially mobile) seem to become data crowded no matter how much bandwidth they invest in.)

> I imagine that the solution will be fairly simple, spec- and implementation-

> wise. 

--- Agree that such solution should and could be found, but it is not obvious. Below you find 3 proposals (initiated by me or colleagues, where I see flaws in the two first and now only suggest the third (the Anycast mechanism). From below:

- 1st: … withdraw my suggestion to use DHCP to find a network provider offered TURN server in favor of the DNS-Based Service Discovery method (inserted last below). The major problem with the DHCP usage was that you then also have to do something similar for: RA - Router Advertisement - in IPv6, addition to the IPCP protocol for PPPoE and something for the mobile OTT channel – wherever DHCP is NOT the method to give you an IP address. (There were also concerns whether OSs actually supports forwards such extended DHCP information for the browser to use.)

- 2nd Reverse DNS-Based Service Discovery method:

Justin Uberti pointed out:  How does this get bootstrapped? That is, how is the STUN server found?

[Karl] Oops, that got lost when leaving the DHCP track, and is a problem when using DNS discovery.

(There were also hesitations of having to provision this special reverse DNS for every access.)

- 3rd The Anycast method below – I see no problem

It also has the advantage of encouraging (but not requiring) the STUN/TURN to be built in the default gateway or NAT/firewall/access router itself, with a second interface to a public IP address on the WAN side. (Current volume deployed, low cost NSP triple play modems usually have a quality assured level 2 or level 3 WAN pipe for just voice (and another for IPTV) – The anycast discovered TURN-server can be the access gateway to such quality pipe for WebRTC media, in a single NSP provided CPE, scaling from residential and up.)

So I think we can finish this very quickly once we have a candidate

> draft. We just need authors. So I would target not long after Toronto.

> Simon

WEB BROWSER BEHAVIOUR:

Network provided TURN servers will not appear over night, applications may for long provide a TURN server address, and there are exceptions where the TURN server address is preferred to be “manually” configured. It is previously suggested, and to some extent discussed, that the WebRTC browser should select the TURN server to use in the following priority order, where ICE would assure that you get some connectivity if several candidates are found and needs to be tested:

1) TURN server address configured in the browser by the user (special cases, normally not used, but handy for testing)

2) TURN server address configured by the network administrator via an “admin policy template” or a WPAD method as mentioned below

3) TURN server address auto-discovered by the mechanism discussed here

4) TURN server address being supplied by the web application

With a good step 3), step 2) becomes obsolete since the network administrator e.g. simply can set a route in the enterprise firewall to use the Anycast mechanism instead. 

Even if the need for auto-discovery of the TURN server comes from WebRTC usage, a general mechanism that also can be used by SIP clients (and other protocols using TURN via ICE) is preferable. The anycast method has no application dependence, but e.g. WPAD has (a SIP Client typically does not have the luxury of a JS engine…)

/Karl

Från: Karl Stahl [ <mailto:[email-masked]> mailto:[email-masked]] 
Skickat: den 22 oktober 2013 16:37
Till: 'Justin Uberti'; 'Cullen Jennings (fluffy)'
Kopia: 'Bernard Aboba'; 'Harald Alvestrand'; [email-masked]'; [email-masked]'
Ämne: [rtcweb] [mmusic] Anycast discovery, Was TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

See my comments below. The problem of having to know a first STUN server in order to use DNS discovery, makes the suggestions below less good.

Another idea came up; to use anycast to allow a WebRTC browser to find a network provided TURN server (both local on a LAN or provided by a carrier). (There are some discussion around using anycast in the STUN and TURN RFCs.) This anycast-way should work both for a TURN server on a LAN and a TURN server outside the NAT/Firewall (any router in the chain can take care of an anycast address) and by the simple method below, return the available TURN server closest to the client. Finding a TURN server close to the client (the WebRTC browser) will also minimize “the turn” the real-time traffic has to take.  

The suggestion is to define an anycast IP address for STUN servers and:

- The network provider, offering a TURN server on his access, adds a route in his access router (or NAT/Firewall) so that the anycast address routes to his TURN/STUN server (a TURN server is an extension of STUN server, thus included in the same box).

- The TURN/STUN server is configured to respond to a binding request with a “300 Try alternate server”, that points out the same TURN/STUN server (by its real IP address, not the anycast address).

The WebRTC browser client would then:

- Issue a STUN binding request to the anycast address

- Issue another STUN binding request to the ALTERNATE SERVER IP address in the “300 Try alternate” response (as any client should do). 

- Interpret the received “300 Try alternate” response now having the same ALTERNATE SERVER IP address as the source IP address of that response, as an indication to use its TURN server (not the STUN server) at that address. 

That is the TURN server to use!

The only addition to existing standards is the interpretation above of the “300 Try alternate” response in the STUN RCF 5766 having the same ALTERNATE SERVER IP address as the source IP address of the response. It means: Use the TURN server at the specified address. That should be easy to clarify.

(The STUN server at the anycast address, may or may not be the same TURN/STUN server used in second binding request.) 

Authentication could simply be that the TURN/STUN server only is reachable from the IP addresses that the network provider want to support with the TURN server (easy for the network provider, since he is handing out those IP addresses).

This should be easy to provision for a carrier or a LAN administrator and trivial to try for the WebRTC browser.

An advantage is that the two STUN binding requests directly returns the TURN server address, whereby the following ICE process should be quick and easy. This could also be done only once when the browser is started or get a new IP address and cashed for later calls.

/Karl

PS If you wonder why not define an anycast address for a TURN server instead, read this thread from 2008:   <http://www.ietf.org/mail-archive/web/behave/current/msg03582.html> http://www.ietf.org/mail-archive/web/behave/current/msg03582.html. There, the use of anycast to a TURN server is discussed, but found not to work. (Here anycast is only used for the first request to the STUN server, where after the real address to the TURN/STUN server is used.)

Från: Justin Uberti [ <mailto:[email-masked]> mailto:[email-masked]] 
Skickat: den 8 oktober 2013 08:17
Till: Karl Stahl
Kopia: Bernard Aboba; Harald Alvestrand; Cullen Jennings (fluffy);  <mailto:[email-masked]> [email-masked];  <mailto:[email-masked]> [email-masked]
Ämne: Re: [rtcweb] [mmusic] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

On Mon, Oct 7, 2013 at 6:21 AM, Karl Stahl < <mailto:[email-masked]> [email-masked]> wrote:

So the WPAD-way of getting a network provider’s TURN server address for the real (white, global) IP address he has handed out to a user, the browser would:

- Use STUN to find the global IP address (done anyway in ICE)

How does this get bootstrapped? That is, how is the STUN server found?

[Karl] Oops, that got lost when leaving the DHCP track, and is a problem when using DNS discovery.

- Do a reverse DNS lookup (instead of the DNS-Based Service Discovery that is not yet deployed)

- Make a URL based on the hostname from the reverse DNS lookup, e.g. from 179.sub-174-252-35.myvzw.com, make h ttp://turnad.myvzw.com

I was hoping we could do something simpler, such as using the ISP's configured domain search list, to determine the domain.

 [Karl] But carriers don’t push out such things, do they? And if they could do it via DHCP we are back with those problems again.

- And there find a list (in JS) of TURN server addresses for the network provider’s IP addresses

 Or would an alternative be to add your own IP address to the URL and get only your specific TURN server address?

Doing it at this Web level, I think we also should consider clients using ICE/TURN, but not having the luxury of a JS engine: Would e.g. a SIP client be able to parse a “JS table” to find his TURN server address easily? Also, are there long time-outs to be considered when there is no h ttp://turned.myvzw.com to be found?

This method may be easier for a network provider to deploy (I don’t know, but for local use on a LAN I guess it is). On the other hand, the DNS-Based Service Discovery method is quick and easy for a WebRTC browser, so that may be tried as well.

Independent of how we find the network provided TURN server, one advantage with it is the authentication: The network provider simply sets up the TURN for usage from the IP addresses he has handed out.

/Karl

Från: Justin Uberti [mailto: <mailto:[email-masked]> [email-masked]] 
Skickat: den 3 oktober 2013 20:59
Till: Karl Stahl
Kopia: Bernard Aboba; Harald Alvestrand; Cullen Jennings (fluffy);  <mailto:[email-masked]> [email-masked];  <mailto:[email-masked]> [email-masked]
Ämne: Re: [rtcweb] [mmusic] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

WPAD already supports DNS-based discovery (in addition to DHCP). If you have  <http://host-95-199-196-65.mobileonline.telia.com/> host-95-199-196-65.mobileonline.telia.com as your endpoint hostname, it will try to get a PAC file from  <http://wpad.mobileonline.telia.com> wpad.mobileonline.telia.com.

Since for all practical purposes, TURN is a "UDP proxy", I think it should be handled similar to other proxy autoconfig mechanisms.

On Mon, Sep 30, 2013 at 5:13 PM, Karl Stahl < <mailto:[email-masked]> [email-masked]> wrote:

I happily withdraw my suggestion to use DHCP to find a network provider offered TURN server in favor of the DNS-Based Service Discovery method (inserted last below). The major problem with the DHCP usage was that you then also have to do something similar for: RA - Router Advertisement - in IPv6, addition to the IPCP protocol for PPPoE and something for the mobile OTT channel – wherever DHCP is NOT the method to give you an IP address.

Further:

> On Thu, Sep 27, 2013 Justin Uberti wrote:

> Agree. I still think that extending PAC files to include TURN information is the right way to go.

> PAC files can already be discovered via DHCP or DNS, there is no need to reinvent this wheel.

>>On Thu, Sep 26, 2013 at 4:55 PM, Cullen Jennings (fluffy) < <mailto:[email-masked]> [email-masked]> wrote:

>>I think we need to give some advise to the browsers vendors on what they should implement to find turn servers

I Googled a bit on PAC and WPAD and saw that a HTTP proxy config JS file can be picked up through a URL based on the device name. Similar could work for finding a TURN server on a LAN, but what about the case with a network provider offered TURN server? The network provider hands out an IP address and wants to announce a related TURN server address: – Is there a “PAC-way” to announce it to a device on a LAN (behind a NAT/firewall)? The device must find such configuration file based on its public IP address (that he can find using STUN as in the suggestion below).

But generally, finding a TURN-server is a network-thing, ICE (or even TURN not using ICE), not a Web-thing, so for that reason the DNS-Based Service Discovery method is at a better level. Such method could also be used by SIP clients (even a Skype client could implement it to benefit from a real-time path with better quality, if the network provider offers such path through his TURN server).

The DNS-Based Service Discovery method should be easy to implement in a WebRTC browser (doing complex ICE things anyway). The question is rather how easy it is for the network provider to provision. Do they all do reverse DNS like with found with mobile operators TeliaSonera and Tele2 in Sweden? Then it should not be too difficult.

Or is there yet another better method to announce a TURN server address with the IP address offered?

/Karl

Från: [email-masked] [mailto:[email-masked]] För Bernard Aboba
Skickat: den 29 september 2013 02:41
Till: Harald Alvestrand
Kopia: [email-masked]

Ämne: Re: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

On Sep 26, 2013 8:46 PM, "Harald Alvestrand" < <mailto:[email-masked]> [email-masked]> wrote:

"So far, neither the POSIX standard nor any OS vendor has offered a generic facility to access information made available in DHCP packets."

[BA] The Windows DHCP client API does provide this: 

 <http://msdn.microsoft.com/en-us/library/windows/desktop/aa363351(v=vs.85).aspx> http://msdn.microsoft.com/en-us/library/windows/desktop/aa363351(v=vs.85).aspx

In particular, the SendParams argument to the DhcpRequestParams function can be used to request a particular parameter (e.g. TURN server address), which will then be returned in the RecdParams variable.  

Nevertheless, I still think that using DHCP to configure the TURN server address in a browser isn't a good idea.  For one thing, since DHCP is effectively unsecured, this mechanism could be used by a rogue DHCP server to force traffic to a rogue turnserver.   Great for surveillance!

On Sep 27, 2013 1:27 AM, "Karl Stahl" < <mailto:[email-masked]> [email-masked]> wrote:

Here comes the suggestion I got from my developer that would allow a network
provider to offer his TURN server for the WebRTC browser to use. This would
require NO new DHCP-options or similar, and NO OS changes (I do realize
those should be avoided if possible...).

The idea is still, that whoever is responsible for giving a device an IP
address (the network provider or a LAN administrator) can also announce a
TURN server for the WebRTC browser to use.

The suggestion is to use RFC6763 (DNS-Based Service Discovery, see chapter
11) where the network provider (the owner of the IP address) has set up a
DNS PTR record for the TURN server in the in-addr.arpa domain.

If the device got IP 173.164.252.149, then make a query for the PTR record
for:
_turn._udp.149.252.164.173.in-addr.arpa.
Then the SRV record would return the actual address to the TURN server (and
you may find several for load balancing and failover I guess)

If the device is on a LAN, the IP 173.164.252.149 to query would be the WAN
IP you get via STUN in the ICE process. But if the LAN administrator
provides a local TURN server, then he also should have blocked STUN in the
firewall, and the browser should query the device's local host address (as
in the ICE procedure) and the local LAN DNS server should answer the query
to give the local TURN server address on the LAN.

Shouldn't this work to allow network provider to offer his TURN server
"automatically and generally"?

And wouldn't this work nicely for mobile devices, whenever the device is on
a "WebRTC-ready access" (actually good for everything using ICE), whether
fixed, WiFi or 3G/4G OTT, you get also a TURN server (and the network
provider hopefully offers a prioritized pipe there as one usage of this
mechanism).

Not to slow down every call setup by doing this in the ICE process, I guess
this could be done when starting the browser and when the device gets a new
IP address, to have the TURN server address ready for later use.

/Karl

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 10 Feb 2014 10:49:34 +0000

Agree that this is top priority milestone for TRAM and I am willing to contribute to this.

It is great to here that a draft will be published soon on this subject only sorry that I have not found time to do it before now.

Regards
Andy

From: tram [mailto:[email-masked]] On Behalf Of Karl Stahl
Sent: 08 February 2014 13:11
To: [email-masked]; [email-masked]; 'Simon Perreault'
Subject: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs

Great, please consider the input and suggestions below:

> From: tram [mailto:tram-bounces at ietf.org] On Behalf Of Simon Perreault
…

--- Agree

WEB BROWSER BEHAVIOUR:

/Karl

Från: Karl Stahl [mailto:[email-masked]]

/Karl

PS If you wonder why not define an anycast address for a TURN server instead, read this thread from 2008:  http://www.ietf.org/mail-archive/web/behave/current/msg03582.html. There, the use of anycast to a TURN server is discussed, but found not to work. (Here anycast is only used for the first request to the STUN server, where after the real address to the TURN/STUN server is used.)

Från: Justin Uberti [mailto:[email-masked]]
Skickat: den 8 oktober 2013 08:17
Till: Karl Stahl
Kopia: Bernard Aboba; Harald Alvestrand; Cullen Jennings (fluffy); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Ämne: Re: [rtcweb] [mmusic] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

On Mon, Oct 7, 2013 at 6:21 AM, Karl Stahl <[email-masked]<mailto:[email-masked]>> wrote:
So the WPAD-way of getting a network provider’s TURN server address for the real (white, global) IP address he has handed out to a user, the browser would:
- Use STUN to find the global IP address (done anyway in ICE)

- Do a reverse DNS lookup (instead of the DNS-Based Service Discovery that is not yet deployed)
- Make a URL based on the hostname from the reverse DNS lookup, e.g. from 179.sub-174-252-35.myvzw.com<http://179.sub-174-252-35.myvzw.com>, make h ttp://turnad.myvzw.com<http://turnad.myvzw.com>

Doing it at this Web level, I think we also should consider clients using ICE/TURN, but not having the luxury of a JS engine: Would e.g. a SIP client be able to parse a “JS table” to find his TURN server address easily? Also, are there long time-outs to be considered when there is no h ttp://turned.myvzw.com<http://turned.myvzw.com> to be found?

/Karl

Från: Justin Uberti [mailto:[email-masked]<mailto:[email-masked]>]
Skickat: den 3 oktober 2013 20:59
Till: Karl Stahl
Kopia: Bernard Aboba; Harald Alvestrand; Cullen Jennings (fluffy); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Ämne: Re: [rtcweb] [mmusic] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

WPAD already supports DNS-based discovery (in addition to DHCP). If you have host-95-199-196-65.mobileonline.telia.com<http://host-95-199-196-65.mobileonline.telia.com/> as your endpoint hostname, it will try to get a PAC file from wpad.mobileonline.telia.com<http://wpad.mobileonline.telia.com>.

On Mon, Sep 30, 2013 at 5:13 PM, Karl Stahl <[email-masked]<mailto:[email-masked]>> wrote:
I happily withdraw my suggestion to use DHCP to find a network provider offered TURN server in favor of the DNS-Based Service Discovery method (inserted last below). The major problem with the DHCP usage was that you then also have to do something similar for: RA - Router Advertisement - in IPv6, addition to the IPCP protocol for PPPoE and something for the mobile OTT channel – wherever DHCP is NOT the method to give you an IP address.

>>On Thu, Sep 26, 2013 at 4:55 PM, Cullen Jennings (fluffy) <[email-masked]<mailto:[email-masked]>> wrote:

/Karl

Från: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] För Bernard Aboba
Skickat: den 29 september 2013 02:41
Till: Harald Alvestrand
Kopia: [email-masked]<mailto:[email-masked]>

On Sep 26, 2013 8:46 PM, "Harald Alvestrand" <[email-masked]<mailto:[email-masked]>> wrote:

[BA] The Windows DHCP client API does provide this:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa363351(v=vs.85).aspx

On Sep 27, 2013 1:27 AM, "Karl Stahl" <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Simon Perreault <[email-masked]>
Date: Mon, 10 Feb 2014 09:16:01 -0500

Karl,

It is great to see such enthusiasm! Thanks!

I have a couple technical questions...

Le 2014-02-08 08:11, Karl Stahl a écrit :
> - Note that to achieve some of the above points, TURN must be favored
> over STUN to enforce that the TURN-path actually is used. (The Anycast
> method suggested below, “automatically” does this.)

I understand the STUN vs TURN priority issue. But I don't see how
anycast affects it in any way. Can you please explain?

> - 3^rd The Anycast method below – I see no problem
> 
> It also has the advantage of encouraging (but not requiring) the
> STUN/TURN to be built in the default gateway or NAT/firewall/access
> router itself, with a second interface to a public IP address on the WAN
> side. (Current volume deployed, low cost NSP triple play modems usually
> have a quality assured level 2 or level 3 WAN pipe for just voice (and
> another for IPTV) – The anycast discovered TURN-server can be the access
> gateway to such quality pipe for WebRTC media, in a single NSP provided
> CPE, scaling from residential and up.)

Suppose we define well-known anycast TURN server addresses. How would
this not be subject to the same service quality issues that plagued
6to4? That is, anyone could set up a badly-maintained, under-provisioned
TURN server and announce it over BGP to the world, as it was done for
6to4 relays. Or just bad BGP outbound filter configuration. And how can
we prevent triangle routing? There is nothing guaranteeing that the
anycast server you see is being provided to you by your ISP, rather than
a server sitting on the other side of the planet.

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

---

From: "Karl Stahl" <[email-masked]>
Date: Tue, 11 Feb 2014 00:18:05 +0100

Simon,

Good questions - see inline below --> . 
Some more thought is required!

/Karl

-----Ursprungligt meddelande-----
Från: tram [mailto:[email-masked]] För Simon Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl Stahl; [email-masked]; [email-masked]
Ämne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs

Karl,

> method suggested below, “automatically” does this.)

I understand the STUN vs TURN priority issue. But I don't see how anycast affects it in any way. Can you please explain?

--- Good point - I was a bit quick here (maybe too quick)
We have given this quite bit of thought, since even if a TURN server is provided and discovered, CURRENT usage of ICE may suggest a candidate from the remote party that will make a connection without the need/usage of the TURN server (that we wanted to be used for the good purposes listed).

The only way we found around this, was to stop STUN through the IP default gateway (like a restrictive Enterprise firewall does inhibiting ICE connectivity, which others are concerned about...). Since the provisioning of auto-discovery using the anycast mechanism, would be adding a route in a default gateway, adding a firewall rule to eat STUN packets would assure that the provisioned TURN server actually becomes used (and not bypassed "by accident"). (That was the thought behind the “automatically” within quotes.)

BUT, since you brought up the question, assuming that we have the power to enforce WebRTC usage of ICE, I believe a MUST requirement to use an auto-discovered TURN server instead of STUN, would solve the same problem. However, thinking further (in relation to your next question - "anyone could set up a badly-maintained" - enforcing such ICE usage may not be good.)  

> router itself, with a second interface to a public IP address on the 
> WAN side. (Current volume deployed, low cost NSP triple play modems 
> usually have a quality assured level 2 or level 3 WAN pipe for just 
> voice (and another for IPTV) – The anycast discovered TURN-server can 
> be the access gateway to such quality pipe for WebRTC media, in a 
> single NSP provided CPE, scaling from residential and up.)

Suppose we define well-known anycast TURN server addresses. How would this not be subject to the same service quality issues that plagued 6to4? That is, anyone could set up a badly-maintained, under-provisioned TURN server and announce it over BGP to the world, as it was done for
6to4 relays. Or just bad BGP outbound filter configuration. And how can we prevent triangle routing? There is nothing guaranteeing that the anycast server you see is being provided to you by your ISP, rather than a server sitting on the other side of the planet.

--- Good point - needs to be resolved. For this I don't have a ready answer...
An auto-discovered TURN server must be trusted (whatever method it is discovered by). We are trusting the one providing us with an IP address and default gateway anyway. It would be easy if we could reuse that trust, instead of another mechanisms.

Is there a good way for the browser to check that the anycast address is not handled beyond the network service provider's default gateway? Ideas?

Thanks,
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
[email-masked]
https://www.ietf.org/mailman/listinfo/tram

---

From: Justin Uberti <[email-masked]>
Date: Mon, 10 Feb 2014 17:30:31 -0800

Good to see there is a lot of interest for this milestone. But based on the
description here, it seems like we want to use TURN primarily to identify
WebRTC flows, as opposed to using it as a NAT traversal tool. This makes me
concerned that we may be using the wrong technology to solve the problem.

On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl <[email-masked]> wrote:

> I understand the STUN vs TURN priority issue. But I don't see how anycast
> affects it in any way. Can you please explain?
>
> We have given this quite bit of thought, since even if a TURN server is
> provided and discovered, CURRENT usage of ICE may suggest a candidate from
> the remote party that will make a connection without the need/usage of the
> TURN server (that we wanted to be used for the good purposes listed).
>
> The only way we found around this, was to stop STUN through the IP default
> gateway (like a restrictive Enterprise firewall does inhibiting ICE
> connectivity, which others are concerned about...). Since the provisioning
> of auto-discovery using the anycast mechanism, would be adding a route in a
> default gateway, adding a firewall rule to eat STUN packets would assure
> that the provisioned TURN server actually becomes used (and not bypassed
> "by accident"). (That was the thought behind the “automatically” within
> quotes.)
>
> BUT, since you brought up the question, assuming that we have the power to
> enforce WebRTC usage of ICE, I believe a MUST requirement to use an
> auto-discovered TURN server instead of STUN, would solve the same problem.
> However, thinking further (in relation to your next question - "anyone
> could set up a badly-maintained" - enforcing such ICE usage may not be
> good.)
>
>
> Suppose we define well-known anycast TURN server addresses. How would this
> not be subject to the same service quality issues that plagued 6to4? That
> is, anyone could set up a badly-maintained, under-provisioned TURN server
> and announce it over BGP to the world, as it was done for
> 6to4 relays. Or just bad BGP outbound filter configuration. And how can we
> prevent triangle routing? There is nothing guaranteeing that the anycast
> server you see is being provided to you by your ISP, rather than a server
> sitting on the other side of the planet.
>
> An auto-discovered TURN server must be trusted (whatever method it is
> discovered by). We are trusting the one providing us with an IP address and
> default gateway anyway. It would be easy if we could reuse that trust,
> instead of another mechanisms.
>
> Is there a good way for the browser to check that the anycast address is
> not handled beyond the network service provider's default gateway? Ideas?
>
>
>
> Thanks,
> Simon
> --

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 11 Feb 2014 02:39:33 +0000

> gateway (like a restrictive Enterprise firewall does inhibiting ICE connectivity,
> which others are concerned about...). Since the provisioning of auto-
> discovery using the anycast mechanism, would be adding a route in a default
> gateway, adding a firewall rule to eat STUN packets would assure that the
> provisioned TURN server actually becomes used (and not bypassed "by
> accident"). (That was the thought behind the “automatically” within quotes.)

There are various ways to prioritize WebRTC media streams and I don't see a need to block P2P connectivity.  Using TURN server itself endpoint can learn server-reflexive candidates. If there is a restrictive firewall that blocks P2P connectivity then relayed candidate would eventually be nominated because ICE connectivity check fails with other candidate types. 

I don't see any need to advertise only relayed candidates in the offer/answer other than for privacy reasons.

-Tiru.

> Sent: Tuesday, February 11, 2014 4:48 AM
> To: 'Simon Perreault'; [email-masked]; [email-masked]
> Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for
> enterprise and ISPs
> 
> Simon,
> 
> --- Good point - I was a bit quick here (maybe too quick) We have given this
> quite bit of thought, since even if a TURN server is provided and discovered,
> CURRENT usage of ICE may suggest a candidate from the remote party that
> will make a connection without the need/usage of the TURN server (that we
> wanted to be used for the good purposes listed).
> 
> gateway (like a restrictive Enterprise firewall does inhibiting ICE connectivity,
> which others are concerned about...). Since the provisioning of auto-
> discovery using the anycast mechanism, would be adding a route in a default
> gateway, adding a firewall rule to eat STUN packets would assure that the
> provisioned TURN server actually becomes used (and not bypassed "by
> accident"). (That was the thought behind the “automatically” within quotes.)
> 
> enforce WebRTC usage of ICE, I believe a MUST requirement to use an auto-
> discovered TURN server instead of STUN, would solve the same problem.
> However, thinking further (in relation to your next question - "anyone could
> set up a badly-maintained" - enforcing such ICE usage may not be good.)
> 
> 
> this not be subject to the same service quality issues that plagued 6to4? That
> Is there a good way for the browser to check that the anycast address is not
> handled beyond the network service provider's default gateway? Ideas?
> 
> 
> 
> Thanks,
> Simon
> --

---

From: Dan Wing <[email-masked]>
Date: Mon, 10 Feb 2014 21:39:11 -0800

On Feb 10, 2014, at 5:30 PM, Justin Uberti <[email-masked]> wrote:

> Good to see there is a lot of interest for this milestone. But based on the description here, it seems like we want to use TURN primarily to identify WebRTC flows, as opposed to using it as a NAT traversal tool. This makes me concerned that we may be using the wrong technology to solve the problem.

+1.

I would prefer allowing flows to establish themselves using their 'best' path, and the best path is seldom through a TURN server.  When we imagine IPv6 in our future, we don't want to force an application-level proxy (TURN) server on the path solely for traversing an IPv6 firewall.

It seems this thread is conflating all the possible reasons / justifications for TURN:
  * mobility
  * NAT traversal (both endpoints are behind endpoint-dependent mapping NATs)
  * firewall traversal (firewall blocks UDP)
  * enhancing privacy

Unfortunately the TURN server nor the endpoint really know which of those use-cases is desired (by the user or by the IT network administrator) or necessary (for the call to work at all).  This seems problematic.  Perhaps we need a way to signal the desired use-case ("trait"), or as Justin suggests, using a different technology for some of these use-cases.

-d

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 11 Feb 2014 12:08:51 -0500

Le 2014-02-11 à 00:39, Dan Wing <[email-masked]> a écrit :

> Unfortunately the TURN server nor the endpoint really know which of those use-cases is desired (by the user or by the IT network administrator) or necessary (for the call to work at all).

Dan, while I agree in principle, I doubt that a user could ever say "I want mobility or I want NAT traversal". I think the user only want the call to succeed, whatever the properties of its network point of attachment are.

>  This seems problematic.  Perhaps we need a way to signal the desired use-case ("trait"), or as Justin suggests, using a different technology for some of these use-cases.
> 
> -d
> 
> 
> 
>> 
>>

---

From: Dan Wing <[email-masked]>
Date: Tue, 11 Feb 2014 09:25:03 -0800

> Dan, while I agree in principle, I doubt that a user could ever say "I want mobility or I want NAT traversal". I think the user only want the call to succeed, whatever the properties of its network…

So what can we do?  Should the TURN server provide any and all services the TURN client might possibly want, as that is what a robust TURN server will do, and the endpoint should prefer TURN candidates over all others because there might be some functionality / usefulness of TURN that the user might gain through TURN (e.g., enhanced privacy)?

-d

---

From: "Karl Stahl" <[email-masked]>
Date: Tue, 11 Feb 2014 20:17:05 +0100

Tireddy wrote below > There are various ways to prioritize WebRTC media streams and I don't see a need to block P2P connectivity. 

--- We need not only to think about prioritizing WebRTC, it is about "traffic shaping also".
- If we consider the case of WebRTC traffic over Internet/mobile OTT (not talking about feeding WebRTC into some  
application specific network like IMS where they may be other quality measures), we get lost quality wise already when (if) we allow prioritized WebRTC traffic to go into a congestion point (like a NAT/firewall or default gateway, where there may be heavy data traffic already filling the pipe.
- Quality loss here (lost WebRTC media packets) cannot be recovered later
- That is the "need to block P2P connectivity" (which may sound ugly but is really about assuring that we CAN get P2P connectivity with best quality, with help of service providers and LAN administrators that want WebRTC traffic to be good and accessible...)

--- Or do see another/better way around this that I cannot see?

-----Ursprungligt meddelande-----
Från: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]] 
Skickat: den 11 februari 2014 03:40
Till: Karl Stahl; 'Simon Perreault'; [email-masked]; [email-masked]
Ämne: RE: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs

> The only way we found around this, was to stop STUN through the IP 
> default gateway (like a restrictive Enterprise firewall does 
> inhibiting ICE connectivity, which others are concerned about...). 
> Since the provisioning of auto- discovery using the anycast mechanism, 
> would be adding a route in a default gateway, adding a firewall rule 
> to eat STUN packets would assure that the provisioned TURN server 
> actually becomes used (and not bypassed "by accident"). (That was the 
> thought behind the “automatically” within quotes.)

There are various ways to prioritize WebRTC media streams and I don't see a need to block P2P connectivity. 
--- We need not only to think about prioritizing WebRTC, it is about "traffic shaping also".
- If we consider the case of WebRTC traffic over Internet/mobile OTT (not talking about feeding WebRTC into some  
application specific network like IMS where they may be other quality measures), we get lost quality wise already when (if) we allow prioritized WebRTC traffic to go into a congestion point (like a NAT/firewall or default gateway, where there may be heavy data traffic already filling the pipe.
- Quality loss here (lost WebRTC media packets) cannot be recovered later
- That is the "need to block P2P connectivity" (which may sound ugly but is really about assuring that we CAN get P2P connectivity with best quality, with help of service providers and LAN administrators that want WebRTC traffic to be good and accessible...)

--- Or do see another/better way around this that I cannot see?

 Using TURN server itself endpoint can learn server-reflexive candidates. If there is a restrictive firewall that blocks P2P connectivity then relayed candidate would eventually be nominated because ICE connectivity check fails with other candidate types. 

-Tiru.

> Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism 
> for enterprise and ISPs
> 
> Simon,
> 
> > - Note that to achieve some of the above points, TURN must be 
> > favored over STUN to enforce that the TURN-path actually is used. 
> > (The Anycast method suggested below, “automatically” does this.)
> 
> --- Good point - I was a bit quick here (maybe too quick) We have 
> given this quite bit of thought, since even if a TURN server is 
> provided and discovered, CURRENT usage of ICE may suggest a candidate 
> from the remote party that will make a connection without the 
> need/usage of the TURN server (that we wanted to be used for the good purposes listed).
> 
> The only way we found around this, was to stop STUN through the IP 
> default gateway (like a restrictive Enterprise firewall does 
> inhibiting ICE connectivity, which others are concerned about...). 
> Since the provisioning of auto- discovery using the anycast mechanism, 
> would be adding a route in a default gateway, adding a firewall rule 
> to eat STUN packets would assure that the provisioned TURN server 
> actually becomes used (and not bypassed "by accident"). (That was the 
> thought behind the “automatically” within quotes.)
> 
> BUT, since you brought up the question, assuming that we have the 
> power to enforce WebRTC usage of ICE, I believe a MUST requirement to 
> use an auto- discovered TURN server instead of STUN, would solve the same problem.
> > voice (and another for IPTV) – The anycast discovered TURN-server 
> > can be the access gateway to such quality pipe for WebRTC media, in 
> > a single NSP provided CPE, scaling from residential and up.)
> 
> 6to4? That is, anyone could set up a badly-maintained, 
> under-provisioned TURN server and announce it over BGP to the world, 
> as it was done for
> 6to4 relays. Or just bad BGP outbound filter configuration. And how 
> can we prevent triangle routing? There is nothing guaranteeing that 
> the anycast server you see is being provided to you by your ISP, 
> rather than a server sitting on the other side of the planet.
> 
> discovered by). We are trusting the one providing us with an IP 
> address and default gateway anyway. It would be easy if we could reuse 
> that trust, instead of another mechanisms.
> 
> Is there a good way for the browser to check that the anycast address 
> is not handled beyond the network service provider's default gateway? Ideas?
> 
> 
> 
> Thanks,
> Simon
> --

---

From: "Karl Stahl" <[email-masked]>
Date: Tue, 11 Feb 2014 23:37:04 +0100

Listening to this thread, I am afraid we are missing the very point and
necessity for this milestone!

- There are severe NAT traversal and quality issues that should and can be
dealt with by a good auto-discovery mechanism and the right usage by the
turn client (the WebRTC browser)

There are ways, not only: Enterprises or ISPs wishing to provide their own
TURN server, in an attempt to reduce so-called "triangle routing",need a new
auto-discovery mechanism

But also: - NSPs (Network Service Providers) want to provide a path where
the bandwidth of WebRTC is better coped with.

- NSPs or Enterprises want to offer an Internet access quality pipe for
prioritized RTC (Real Time Communication) traffic. 

- Enterprises having restrictive firewalls, want to provide a UDP-path for
WebRTC and possibly also for better quality where RTC do not compete with
data traffic. 

Also considering

- Mobility; It is common to move from a LAN to accessing via WiFi or 3G/4G
OTT channels, all should be able to automatically offer their own optimal
TURN server

This leads us into  “TURN…to identify WebRTC flows” etc! It is not a
mistake, but the very need for this milestone!

What are the hesitations raised here?

> TURN primarily to identify WebRTC flows, as opposed to using it as a NAT
traversal tool. This makes me concerned that we may be using the wrong
technology to solve the problem

It is correct that ICE/STUN/TURN was designed to address the NAT/Firewall
traversal problem associated with real-time communication (SIP at that
time). However, its largest flaw/problem is that quality things were not
(could not be?) considered. The method’s very idea (like all similar methods
for getting RTC through ordinary NAT/Firewalls) is to fool the media through
a NAT/Firewall that is unaware of what is happening. Thus, this is root of
quality issues (and bandwidth allocation optimization) that needs to be
dealt with: Real-time traffic fighting with a data traffic crowded
congestion point.

But, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate
request for a suitable pipe for quality demanding real time traffic. J 

ICE is a pre-protocol you use because you want a path for real-time media
between parties. Here: The browser says knock knock, I want to get media
through (and of course with as good quality as required and possible). 

If the NAT/Firewall owner and network owner are allowed to see these
requests, they can help/assist in achieving the good media path. If they are
not aware, they cannot help!

Hope this made it understandable on an overview level how this can become
“TURN…to identify WebRTC flows”

It is also the ONLY way I can see to achieve what we want to achieve and
should be the aim and requirement of this milestone.

I am talking about general usage of WebRTC over Internet/mobile OTT (not
feeding WebRTC into application specific networks like IMS where other
methods may exist). 

This is good, not evil!

If the hesitations are raised because of a belief/hope/wish that there are
no or will not be severe quality issues “because it is all about bandwidth”,
“it will resolve itself with time” etc., I strongly object! That is wrong
and will be very detrimental for WebRTC usage. We already see it and I can
give numerous examples of how much less quality demanding VoIP is/is not
handled quality wise and that it matters. And, what would be bad considering
quality issues and allowing/encouraging methods to deal with them?

If the hesitations are raised, because of suspicion that the methods we may
recommend may be misused to stop/block/destroy WebRTC usage (e.g. to protect
income from carrier telephony traffic), I could understand and would fight
the same battle. But hopefully, those days are (soon) over – At least
forward thinking carrier’s realize that already. Web RTC will happen. Which
customers want to pay for an access with blocked WebRTC? The carrier’s
offering/assuring good WebRTC will rather get the customers and income J.
(Maybe the Web browser can detect and encourage this…)

If there are technical concerns of bad result, or better methods allowing
network providers and LAN managers to offer and inform the browser that
there are good media paths to be used, and that the web browser
automatically can chose those, then let us all understand those, so we can
achieve what should be achieved by this milestone. 

/Karl

Från: Dan Wing [mailto:[email-masked]] 
Skickat: den 11 februari 2014 18:25
Till: Marc Blanchet
Kopia: Justin Uberti; [email-masked]; Karl Stahl; [email-masked]; Simon
Perreault
Ämne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for
enterprise and ISPs

On Feb 11, 2014, at 9:08 AM, Marc Blanchet <[email-masked]>
wrote:

+1.

I would prefer allowing flows to establish themselves using their 'best'
path, and the best path is seldom through a TURN server.  When we imagine
IPv6 in our future, we don't want to force an application-level proxy (TURN)
server on the path solely for traversing an IPv6 firewall.

It seems this thread is conflating all the possible reasons / justifications
for TURN:

  * mobility

  * NAT traversal (both endpoints are behind endpoint-dependent mapping
NATs)

  * enhancing privacy

Unfortunately the TURN server nor the endpoint really know which of those
use-cases is desired (by the user or by the IT network administrator) or
necessary (for the call to work at all). 

Dan, while I agree in principle, I doubt that a user could ever say "I want
mobility or I want NAT traversal". I think the user only want the call to
succeed, whatever the properties of its network point of attachment are.

So what can we do?  Should the TURN server provide any and all services the
TURN client might possibly want, as that is what a robust TURN server will
do, and the endpoint should prefer TURN candidates over all others because
there might be some functionality / usefulness of TURN that the user might
gain through TURN (e.g., enhanced privacy)?

-d

 This seems problematic.  Perhaps we need a way to signal the desired
use-case ("trait"), or as Justin suggests, using a different technology for
some of these use-cases.

-d

 

Simon,

/Karl

-----Ursprungligt meddelande-----
Från: tram [mailto:[email-masked]] För Simon Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl Stahl; [email-masked]; [email-masked]
Ämne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for
enterprise and ISPs

Karl,

that the provisioned TURN server actually becomes used (and not bypassed "by

--- Good point - needs to be resolved. For this I don't have a ready
answer...

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

_______________________________________________
tram mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/tram>
https://www.ietf.org/mailman/listinfo/tram

---

From: Justin Uberti <[email-masked]>
Date: Tue, 11 Feb 2014 22:13:14 -0800

Inline.

On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl <[email-masked]> wrote:

> There are ways, not only: Enterprises or ISPs wishing to provide their
> own TURN server, in an attempt to reduce so-called "triangle routing",need
> a new auto-discovery mechanism
>

Again, it has not been demonstrated why TURN is the right technology here,
compared to a more transparent flow identification tool like MALICE. We
don't force all HTTP requests to locate a HTTP proxy via anycast, I don't
see why we need to do the same for WebRTC.

> (could not be?) considered. The method’s very idea (like all similar
> methods for getting RTC through ordinary NAT/Firewalls) is to fool the
> media through a NAT/Firewall that is unaware of what is happening. Thus,
> this is root of quality issues (and bandwidth allocation optimization) that
> needs to be dealt with: Real-time traffic fighting with a data traffic
> crowded congestion point.
>

I think that "fooling" is an incorrect description. The NAT is supposed to
be transparent to the client.

> requests, they can help/assist in achieving the good media path. If they
> are not aware, they cannot help!
>

>
> Hope this made it understandable on an overview level how this can become“TURN…to identify WebRTC flows”
>
> no or will not be severe quality issues “because it is all about
> bandwidth”, “it will resolve itself with time” etc., I strongly object!
> That is wrong and will be very detrimental for WebRTC usage. We already see
> it and I can give numerous examples of how much less quality demanding VoIP
> is/is not handled quality wise and that it matters. And, what would be bad
> considering quality issues and allowing/encouraging methods to deal with
> them?
>

>
> If the hesitations are raised, because of suspicion that the methods we
> may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to
> protect income from carrier telephony traffic), I could understand and
> would fight the same battle. But hopefully, those days are (soon) over – At
> least forward thinking carrier’s realize that already. Web RTC will happen.
> Which customers want to pay for an access with blocked WebRTC? The
> carrier’s offering/assuring good WebRTC will rather get the customers and
> income J. (Maybe the Web browser can detect and encourage this…)
>

> achieve what should be achieved by this milestone.

Skype, Hangouts, Facetime are doing billions of minutes per week and the
Internet has not melted yet. If we need to do flow identification to allow
traffic to be prioritized, fine (see above regarding my preferred
approach), but forcing all WebRTC traffic through a MITM (TURN server) is a
much bigger jump that I don't yet see the justification for.

In short: TURN is a technology that is supposed to fade away with the move
to IPv6. I don't think we want to make it a critical element of WebRTC.

>
>
> /Karl
>
>
>
>
>
> *Från:* Dan Wing [mailto:[email-masked]]
> *Skickat:* den 11 februari 2014 18:25
> *Till:* Marc Blanchet
> *Kopia:* Justin Uberti; [email-masked]; Karl Stahl; [email-masked];
> Simon Perreault
>
> *Ämne:* Re: [tram] Milestone 3: TURN server auto-discovery mechanism for
> enterprise and ISPs
>
>
>
>
>
> Good to see there is a lot of interest for this milestone. But based on
> the description here, it seems like we want to use TURN primarily to
> identify WebRTC flows, as opposed to using it as a NAT traversal tool. This
> makes me concerned that we may be using the wrong technology to solve the
> problem.
>
>
>
> +1.
>
>
>
> IPv6 in our future, we don't want to force an application-level proxy
> (TURN) server on the path solely for traversing an IPv6 firewall.
>
>
>
>
>
> Dan, while I agree in principle, I doubt that a user could ever say "I
> want mobility or I want NAT traversal". I think the user only want the call
> to succeed, whatever the properties of its network point of attachment are.
>
>
>
> So what can we do?  Should the TURN server provide any and all services
> the TURN client might possibly want, as that is what a robust TURN server
> will do, and the endpoint should prefer TURN candidates over all others
> because there might be some functionality / usefulness of TURN that the
> user might gain through TURN (e.g., enhanced privacy)?
>
>
>
> -d
>
>
>
>
>
>
>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 12 Feb 2014 07:01:18 +0000

Hi Karl,

Yes, there is a problem but P2P WebRTC streams (both media and data channels) can be identified and QoS can be provided by the access network without forcing TURN to be used. You may want to look into PCP FLOWDATA (http://tools.ietf.org/html/draft-wing-pcp-flowdata-00), MALICE (http://tools.ietf.org/html/draft-martinsen-mmusic-malice-00). 

-Tiru.

> From: Karl Stahl [mailto:[email-masked]]
> Sent: Wednesday, February 12, 2014 12:47 AM
> To: Tirumaleswar Reddy (tireddy); 'Simon Perreault'; [email-masked];
> [email-masked]
> Subject: SV: [tram] Milestone 3: TURN server auto-discovery mechanism for
> enterprise and ISPs
> 
> Tireddy wrote below > There are various ways to prioritize WebRTC media
> streams and I don't see a need to block P2P connectivity.
> 
> - If we consider the case of WebRTC traffic over Internet/mobile OTT (not
> talking about feeding WebRTC into some application specific network like
> IMS where they may be other quality measures), we get lost quality wise
> already when (if) we allow prioritized WebRTC traffic to go into a congestion
> point (like a NAT/firewall or default gateway, where there may be heavy data
> traffic already filling the pipe.
> - That is the "need to block P2P connectivity" (which may sound ugly but is
> really about assuring that we CAN get P2P connectivity with best quality, with
> help of service providers and LAN administrators that want WebRTC traffic to
> be good and accessible...)
> 
> - If we consider the case of WebRTC traffic over Internet/mobile OTT (not
> talking about feeding WebRTC into some application specific network like
> IMS where they may be other quality measures), we get lost quality wise
> already when (if) we allow prioritized WebRTC traffic to go into a congestion
> point (like a NAT/firewall or default gateway, where there may be heavy data
> traffic already filling the pipe.
> - That is the "need to block P2P connectivity" (which may sound ugly but is
> really about assuring that we CAN get P2P connectivity with best quality, with
> help of service providers and LAN administrators that want WebRTC traffic to
> be good and accessible...)
> 
>  Using TURN server itself endpoint can learn server-reflexive candidates. If
> there is a restrictive firewall that blocks P2P connectivity then relayed
> candidate would eventually be nominated because ICE connectivity check
> fails with other candidate types.
>

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 12 Feb 2014 07:32:05 +0000

+1

Forcing all traffic through a TURN server and expecting it would provide the best user experience doesn't look the right approach. Instead, if a path through a TURN server exists and does provide lower RTT, jitter etc, being able to detect and use (or switch to) that path might be desirable..

Muthu

From: tram [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: Wednesday, February 12, 2014 11:43 AM
To: Karl Stahl
Cc: [email-masked]; Marc Blanchet; [email-masked]; Dan Wing (dwing); Simon Perreault
Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs

Inline.

On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl <[email-masked]<mailto:[email-masked]>> wrote:
Listening to this thread, I am afraid we are missing the very point and necessity for this milestone!
- There are severe NAT traversal and quality issues that should and can be dealt with by a good auto-discovery mechanism and the right usage by the turn client (the WebRTC browser)

There are ways, not only: Enterprises or ISPs wishing to provide their own TURN server, in an attempt to reduce so-called "triangle routing",need a new auto-discovery mechanism
But also: - NSPs (Network Service Providers) want to provide a path where the bandwidth of WebRTC is better coped with.
- NSPs or Enterprises want to offer an Internet access quality pipe for prioritized RTC (Real Time Communication) traffic.
- Enterprises having restrictive firewalls, want to provide a UDP-path for WebRTC and possibly also for better quality where RTC do not compete with data traffic.
Also considering
- Mobility; It is common to move from a LAN to accessing via WiFi or 3G/4G OTT channels, all should be able to automatically offer their own optimal TURN server

This leads us into  “TURN…to identify WebRTC flows” etc! It is not a mistake, but the very need for this milestone!

Again, it has not been demonstrated why TURN is the right technology here, compared to a more transparent flow identification tool like MALICE. We don't force all HTTP requests to locate a HTTP proxy via anycast, I don't see why we need to do the same for WebRTC.

> TURN primarily to identify WebRTC flows, as opposed to using it as a NAT traversal tool. This makes me concerned that we may be using the wrong technology to solve the problem
It is correct that ICE/STUN/TURN was designed to address the NAT/Firewall traversal problem associated with real-time communication (SIP at that time). However, its largest flaw/problem is that quality things were not (could not be?) considered. The method’s very idea (like all similar methods for getting RTC through ordinary NAT/Firewalls) is to fool the media through a NAT/Firewall that is unaware of what is happening. Thus, this is root of quality issues (and bandwidth allocation optimization) that needs to be dealt with: Real-time traffic fighting with a data traffic crowded congestion point.

I think that "fooling" is an incorrect description. The NAT is supposed to be transparent to the client.

But, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate request for a suitable pipe for quality demanding real time traffic. ☺
ICE is a pre-protocol you use because you want a path for real-time media between parties. Here: The browser says knock knock, I want to get media through (and of course with as good quality as required and possible).

If the NAT/Firewall owner and network owner are allowed to see these requests, they can help/assist in achieving the good media path. If they are not aware, they cannot help!

Hope this made it understandable on an overview level how this can become “TURN…to identify WebRTC flows”
It is also the ONLY way I can see to achieve what we want to achieve and should be the aim and requirement of this milestone.

I am talking about general usage of WebRTC over Internet/mobile OTT (not feeding WebRTC into application specific networks like IMS where other methods may exist).

This is good, not evil!

If the hesitations are raised because of a belief/hope/wish that there are no or will not be severe quality issues “because it is all about bandwidth”, “it will resolve itself with time” etc., I strongly object! That is wrong and will be very detrimental for WebRTC usage. We already see it and I can give numerous examples of how much less quality demanding VoIP is/is not handled quality wise and that it matters. And, what would be bad considering quality issues and allowing/encouraging methods to deal with them?

If the hesitations are raised, because of suspicion that the methods we may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to protect income from carrier telephony traffic), I could understand and would fight the same battle. But hopefully, those days are (soon) over – At least forward thinking carrier’s realize that already. Web RTC will happen. Which customers want to pay for an access with blocked WebRTC? The carrier’s offering/assuring good WebRTC will rather get the customers and income ☺. (Maybe the Web browser can detect and encourage this…)

If there are technical concerns of bad result, or better methods allowing network providers and LAN managers to offer and inform the browser that there are good media paths to be used, and that the web browser automatically can chose those, then let us all understand those, so we can achieve what should be achieved by this milestone.

Skype, Hangouts, Facetime are doing billions of minutes per week and the Internet has not melted yet. If we need to do flow identification to allow traffic to be prioritized, fine (see above regarding my preferred approach), but forcing all WebRTC traffic through a MITM (TURN server) is a much bigger jump that I don't yet see the justification for.

In short: TURN is a technology that is supposed to fade away with the move to IPv6. I don't think we want to make it a critical element of WebRTC.

/Karl

Från: Dan Wing [mailto:[email-masked]<mailto:[email-masked]>]
Skickat: den 11 februari 2014 18:25
Till: Marc Blanchet
Kopia: Justin Uberti; [email-masked]<mailto:[email-masked]>; Karl Stahl; [email-masked]<mailto:[email-masked]>; Simon Perreault

On Feb 11, 2014, at 9:08 AM, Marc Blanchet <[email-masked]<mailto:[email-masked]>> wrote:

Le 2014-02-11 à 00:39, Dan Wing <[email-masked]<mailto:[email-masked]>> a écrit :

On Feb 10, 2014, at 5:30 PM, Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:

+1.

-d

-d

On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl <[email-masked]<mailto:[email-masked]>> wrote:
Simon,

/Karl

-----Ursprungligt meddelande-----
Från: tram [mailto:[email-masked]<mailto:[email-masked]>] För Simon Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl Stahl; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Ämne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs

Karl,

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

_______________________________________________
tram mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tram

_______________________________________________
tram mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tram

_______________________________________________
tram mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tram

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 11 Feb 2014 23:37:12 -0800

The TURN server has to be used when it is either the only option, or if it
provides a better path (I guess the second case is rather rare).

On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi Perumal (mperumal) <
[email-masked]> wrote:

>  +1
>
>
>
> Forcing all traffic through a TURN server and expecting it would provide
> the best user experience doesn't look the right approach. Instead, if a
> path through a TURN server exists and does provide lower RTT, jitter etc,
> being able to detect and use (or switch to) that path might be desirable..
>
>
>
> Muthu
>
>
>
> *From:* tram [mailto:[email-masked]] *On Behalf Of *Justin Uberti
> *Sent:* Wednesday, February 12, 2014 11:43 AM
> *To:* Karl Stahl
> *Cc:* [email-masked]; Marc Blanchet; [email-masked]; Dan Wing (dwing);
> Simon Perreault
> *Subject:* Re: [tram] Milestone 3: TURN server auto-discovery mechanism
> for enterprise and ISPs
>
>
>
> Inline.
>
>
>
> This leads us into  "TURN...to identify WebRTC flows" etc! It is not a
> (could not be?) considered. The method's very idea (like all similar
> Hope this made it understandable on an overview level how this can become"TURN...to identify WebRTC flows"
>
> no or will not be severe quality issues "because it is all about
> bandwidth", "it will resolve itself with time" etc., I strongly object!
> would fight the same battle. But hopefully, those days are (soon) over - At
> least forward thinking carrier's realize that already. Web RTC will happen.
> carrier's offering/assuring good WebRTC will rather get the customers and
> income J. (Maybe the Web browser can detect and encourage this...)
>
>
>
> On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl <[email-masked]
> > wrote:
>
> Simon,
>
> > method suggested below, "automatically" does this.)
>
> "by accident"). (That was the thought behind the "automatically" within
> quotes.)
>
> > - 3^rd The Anycast method below - I see no problem
> >
> > voice (and another for IPTV) - The anycast discovered TURN-server can

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Wed, 12 Feb 2014 09:13:36 +0000

Inline and a lot of context clipped away.

> On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl <[email-masked]> wrote:
[cut]
> Again, it has not been demonstrated why TURN is the right technology here, compared to a more transparent flow identification tool like MALICE. We don't force all HTTP requests to locate a HTTP pro…
We renamed MALICE to DISCUSS.  To get rid of Meta-data associations and ICE from the name, and to indicate that this is a much simplified version.

DISCUSS is posted here: http://tools.ietf.org/html/draft-martinsen-tram-discuss-00

Started a separate thread on the topic. Just wanted to make explain the MALICE -> DISCUSS correlation.
Is it possible to get a link from the expired MALICE draft to the new DISCUSS draft? How? 

.-.
Pål-Erik

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 12 Feb 2014 09:27:57 +0000

Yes, I believe the second case is rare, but would be better than a rat race b/w administrators trying to block p2p traffic and force it through a TURN server and apps/endpoints finding smarter ways to bypass them.

Muthu

From: Oleg Moskalenko [mailto:[email-masked]]
Sent: Wednesday, February 12, 2014 1:07 PM
To: Muthu Arul Mozhi Perumal (mperumal)
Cc: Justin Uberti; Karl Stahl; [email-masked]; Marc Blanchet; [email-masked]; Dan Wing (dwing); Simon Perreault
Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs

The TURN server has to be used when it is either the only option, or if it provides a better path (I guess the second case is rather rare).

On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi Perumal (mperumal) <[email-masked]<mailto:[email-masked]>> wrote:
+1

Muthu

From: tram [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Justin Uberti
Sent: Wednesday, February 12, 2014 11:43 AM
To: Karl Stahl
Cc: [email-masked]<mailto:[email-masked]>; Marc Blanchet; [email-masked]<mailto:[email-masked]>; Dan Wing (dwing); Simon Perreault
Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs

Inline.

This leads us into  "TURN...to identify WebRTC flows" etc! It is not a mistake, but the very need for this milestone!

> TURN primarily to identify WebRTC flows, as opposed to using it as a NAT traversal tool. This makes me concerned that we may be using the wrong technology to solve the problem
It is correct that ICE/STUN/TURN was designed to address the NAT/Firewall traversal problem associated with real-time communication (SIP at that time). However, its largest flaw/problem is that quality things were not (could not be?) considered. The method's very idea (like all similar methods for getting RTC through ordinary NAT/Firewalls) is to fool the media through a NAT/Firewall that is unaware of what is happening. Thus, this is root of quality issues (and bandwidth allocation optimization) that needs to be dealt with: Real-time traffic fighting with a data traffic crowded congestion point.

But, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate request for a suitable pipe for quality demanding real time traffic. :)
ICE is a pre-protocol you use because you want a path for real-time media between parties. Here: The browser says knock knock, I want to get media through (and of course with as good quality as required and possible).

Hope this made it understandable on an overview level how this can become "TURN...to identify WebRTC flows"
It is also the ONLY way I can see to achieve what we want to achieve and should be the aim and requirement of this milestone.

This is good, not evil!

If the hesitations are raised because of a belief/hope/wish that there are no or will not be severe quality issues "because it is all about bandwidth", "it will resolve itself with time" etc., I strongly object! That is wrong and will be very detrimental for WebRTC usage. We already see it and I can give numerous examples of how much less quality demanding VoIP is/is not handled quality wise and that it matters. And, what would be bad considering quality issues and allowing/encouraging methods to deal with them?

If the hesitations are raised, because of suspicion that the methods we may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to protect income from carrier telephony traffic), I could understand and would fight the same battle. But hopefully, those days are (soon) over - At least forward thinking carrier's realize that already. Web RTC will happen. Which customers want to pay for an access with blocked WebRTC? The carrier's offering/assuring good WebRTC will rather get the customers and income :). (Maybe the Web browser can detect and encourage this...)

/Karl

+1.

-d

-d

/Karl

-----Ursprungligt meddelande-----
Från: tram [mailto:[email-masked]<mailto:[email-masked]>] För Simon Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl Stahl; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Ämne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs

Karl,

The only way we found around this, was to stop STUN through the IP default gateway (like a restrictive Enterprise firewall does inhibiting ICE connectivity, which others are concerned about...). Since the provisioning of auto-discovery using the anycast mechanism, would be adding a route in a default gateway, adding a firewall rule to eat STUN packets would assure that the provisioned TURN server actually becomes used (and not bypassed "by accident"). (That was the thought behind the "automatically" within quotes.)

Thanks,
Simon

---

From: Justin Uberti <[email-masked]>
Date: Wed, 12 Feb 2014 09:46:11 -0800

Agree. If TURN is indeed being provided for the user's benefit, the
client's ICE logic (based on RTT or similar) should result in it preferring
the TURN path.

On Wed, Feb 12, 2014 at 1:27 AM, Muthu Arul Mozhi Perumal (mperumal) <
[email-masked]> wrote:

>  Yes, I believe the second case is rare, but would be better than a rat
> race b/w administrators trying to block p2p traffic and force it through a
> TURN server and apps/endpoints finding smarter ways to bypass them.
>
>
>
> Muthu
>
>
>
> *From:* Oleg Moskalenko [mailto:[email-masked]]
> *Sent:* Wednesday, February 12, 2014 1:07 PM
> *To:* Muthu Arul Mozhi Perumal (mperumal)
> *Cc:* Justin Uberti; Karl Stahl; [email-masked]; Marc Blanchet;
> [email-masked]; Dan Wing (dwing); Simon Perreault
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 12 Feb 2014 19:30:07 +0000

The case where the TURN server is the only option may become common within enterprise networks and that might be deliberate enterprise policy because it provides the better path (UDP through the F/W) and protects the users and the network.

Andy

From: tram [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: 12 February 2014 17:46
To: Muthu Arul Mozhi Perumal (mperumal)
Cc: [email-masked]; Simon Perreault; Oleg Moskalenko; [email-masked]; Marc Blanchet; Dan Wing (dwing); Karl Stahl
Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs

Agree. If TURN is indeed being provided for the user's benefit, the client's ICE logic (based on RTT or similar) should result in it preferring the TURN path.

On Wed, Feb 12, 2014 at 1:27 AM, Muthu Arul Mozhi Perumal (mperumal) <[email-masked]<mailto:[email-masked]>> wrote:
Yes, I believe the second case is rare, but would be better than a rat race b/w administrators trying to block p2p traffic and force it through a TURN server and apps/endpoints finding smarter ways to bypass them.

Muthu

From: Oleg Moskalenko [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, February 12, 2014 1:07 PM
To: Muthu Arul Mozhi Perumal (mperumal)
Cc: Justin Uberti; Karl Stahl; [email-masked]<mailto:[email-masked]>; Marc Blanchet; [email-masked]<mailto:[email-masked]>; Dan Wing (dwing); Simon Perreault

Muthu

Inline.

This is good, not evil!

/Karl

+1.

-d

-d

/Karl

-----Ursprungligt meddelande-----
Från: tram [mailto:[email-masked]<mailto:[email-masked]>] För Simon Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl Stahl; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Ämne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs

Karl,

Thanks,
Simon

---

From: Justin Uberti <[email-masked]>
Date: Wed, 12 Feb 2014 15:11:05 -0800

Agreed, but enterprises are already doing this with HTTP proxies, so the
precedent (and mechanisms that can be used) are much clearer.

On Wed, Feb 12, 2014 at 11:30 AM, Hutton, Andrew <[email-masked]>wrote:

>  The case where the TURN server is the only option may become common
> within enterprise networks and that might be deliberate enterprise policy
> because it provides the better path (UDP through the F/W) and protects the
> users and the network.
>
>
>
> Andy
>
>
>
>
>
> *Sent:* 12 February 2014 17:46
>
> *Cc:* [email-masked]; Simon Perreault; Oleg Moskalenko; [email-masked];
> Marc Blanchet; Dan Wing (dwing); Karl Stahl
>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 13 Feb 2014 03:40:01 +0000

Hi Andy,

There are other ways to solve the problem for example using PCP. Can you clarify how deploying a TURN server in the Enterprise protects the users and the network ?

-Tiru.
From: tram [mailto:[email-masked]] On Behalf Of Hutton, Andrew
Sent: Thursday, February 13, 2014 1:00 AM
To: Justin Uberti; Muthu Arul Mozhi Perumal (mperumal)
Cc: [email-masked]; Simon Perreault; Oleg Moskalenko; [email-masked]; Marc Blanchet; Dan Wing (dwing); Karl Stahl
Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs

Andy

Cc: [email-masked]<mailto:[email-masked]>; Simon Perreault; Oleg Moskalenko; [email-masked]<mailto:[email-masked]>; Marc Blanchet; Dan Wing (dwing); Karl Stahl

Muthu

Muthu

Inline.

This is good, not evil!

/Karl

+1.

-d

-d

/Karl

-----Ursprungligt meddelande-----
Från: tram [mailto:[email-masked]<mailto:[email-masked]>] För Simon Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl Stahl; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Ämne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs

Karl,

Thanks,
Simon

---

From: "Karl Stahl" <[email-masked]>
Date: Thu, 13 Feb 2014 11:07:52 +0100

-- I meant the firewall is being ”fooled” (within quotes) by ICE usage – The firewall is usually stopping incoming unannounced/not recognized traffic

/Karl  

Från: Justin Uberti [mailto:[email-masked]] 
Skickat: den 12 februari 2014 07:13
Till: Karl Stahl
Kopia: Dan Wing; Marc Blanchet; [email-masked]; [email-masked]; Simon Perreault
Ämne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs

Inline.

Also considering

-- I meant the firewall is being ”fooled” (withing quotes) – it is usually stopping incoming unannounced/not recognised traffic

/Karl  

But, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate request for a suitable pipe for quality demanding real time traffic. J 

This is good, not evil!

If the hesitations are raised, because of suspicion that the methods we may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to protect income from carrier telephony traffic), I could understand and would fight the same battle. But hopefully, those days are (soon) over – At least forward thinking carrier’s realize that already. Web RTC will happen. Which customers want to pay for an access with blocked WebRTC? The carrier’s offering/assuring good WebRTC will rather get the customers and income J. (Maybe the Web browser can detect and encourage this…) 

/Karl

Från: Dan Wing [mailto:[email-masked]] 
Skickat: den 11 februari 2014 18:25
Till: Marc Blanchet
Kopia: Justin Uberti; [email-masked]; Karl Stahl; [email-masked]; Simon Perreault

 

+1.

 

  * mobility

  * enhancing privacy

-d

-d

 

Simon,

/Karl

-----Ursprungligt meddelande-----
Från: tram [mailto:[email-masked]] För Simon Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl Stahl; [email-masked]; [email-masked]
Ämne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs

Karl,

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

_______________________________________________
tram mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/tram> https://www.ietf.org/mailman/listinfo/tram

---

From: "Karl Stahl" <[email-masked]>
Date: Thu, 13 Feb 2014 11:59:48 +0100

Justin said > Skype, Hangouts, Facetime are doing billions of minutes per week and the Internet has not melted yet. If we need to do flow identification to allow traffic to be prioritized, fine (see above regarding my preferred approach), but forcing all WebRTC traffic through a MITM (TURN server) is a much bigger jump that I don't yet see the justification for.

In short: TURN is a technology that is supposed to fade away with the move to IPv6. I don't think we want to make it a critical element of WebRTC.are doing billions of minutes per week and the Internet has not melted yet. If we need to do flow identification to allow traffic to be prioritized, fine (see above regarding my preferred approach), but forcing all WebRTC traffic through a MITM (TURN server) is a much bigger jump that I don't yet see the justification for.

--- You (and the ones you communicate with) must be blessed with very good Internet pipes!

As an illustration; here is my experience from ITEXPO a few weeks ago where I/Ingate made several live tests and demos of WebRTC and over the AT&T and Verizon LTE/4G networks. Walking around the halls, the Verizon LTE showed 2-3 signal strength bars and the AT&T LTE with a closer cell tower showed 4-5 bars. The Verizon network was “unusable” for WebRTC video, while the AT&T long times showed perfect HD WebRTC video, mixed with severe quality degradation (incl Chrome’s shrinking VP8 video window size remedy mechanism), and even total loss media.

I have similar experiences with Hangouts, even over fixed pipes. 

How do think bandwidth reservation type of networks (Cable and Mobile) will be able to receive and deliver unannounced/unrecognized high bandwidth traffic in a lossless way  to the client if the pipe is data crowded? (a few more things than discussed now are actually required to ease that) 

- We need flow enforcement (not only identification), to cope with the problems and be able to enjoy all the good benefits and capabilities of WebRTC! And WebRTC in itself has/allows “Telepresence quality/resolution” – Let us get that on our desktops and in our pockets! We must realize that we are talking about 30 times higher bandwidth needs than for old POTS telephony (that is run over quality managed networks). Now we are about to do 30 times more demanding things over best effort Internet, and through severe NAT/Firewall congestion points….

- See the standardization of WebRTC (compared to proprietary Skype, Hangouts, Facetime) as a very good opportunity of finally dealing with this and getting/enabling quality for RTC over the Internet. This is a huge opportunity and a necessity! 

- If we do it right Skype, Hangouts, Facetime Can/Will also benefit from it by using WebRTC J. I actually think they will do just that in a future when the standards are settled and WebRTC are in all browsers. 

Justin said > In short: TURN is a technology that is supposed to fade away with the move to IPv6. I don't think we want to make it a critical element of WebRTC.

--- ICE and at least STUN will be necessary also in an all IPv6 world. Firewalls stopping unannounced/not recognized traffic (=media) will still be there hindering media to clients.

/Karl

Inline.

Also considering

This is good, not evil!

/Karl

 

+1.

 

  * mobility

  * enhancing privacy

-d

-d

 

Simon,

/Karl

-----Ursprungligt meddelande-----
Från: tram [mailto:[email-masked]] För Simon Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl Stahl; [email-masked]; [email-masked]
Ämne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs

Karl,

Thanks,
Simon

---

From: "Karl Stahl" <[email-masked]>
Date: Thu, 13 Feb 2014 12:36:11 +0100

>Again, it has not been demonstrated why TURN is the right technology here, compared to a more transparent flow identification tool like MALICE. We don't force all HTTP requests to locate a HTTP proxy via anycast, I don't see why we need to do the same for WebRTC

---- You may think what I am about to say sounds even worse, but it is good!

This discussion actually does not (only) lead to  “TURN…to identify WebRTC flows”, 

It leads us to ENFORE media (WebRTC flows) (into paths announced by the enterprise or NSP/ISP)  (my “etc” …in flows” etc!” was this )

I read up on MALICE or rather DISCUSS as it is now called: 

- Good ideas and methods, but to have any effect, the media arrive at the point in the network where such good measures can applied.

So we need a way to ENFORCE that the media takes certain paths in the network. For RTC protocols using ICE (like WebRTC and SIP) we can/must use TURN for this (the only way I see, and it is a good way).

/Karl

Inline.

Also considering

This is good, not evil!

/Karl

 

+1.

 

  * mobility

  * enhancing privacy

-d

-d

 

Simon,

/Karl

-----Ursprungligt meddelande-----
Från: tram [mailto:[email-masked]] För Simon Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl Stahl; [email-masked]; [email-masked]
Ämne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs

Karl,

Thanks,
Simon

---

From: "Karl Stahl" <[email-masked]>
Date: Thu, 13 Feb 2014 12:36:27 +0100

I checked Malice=discussed and just commented in previous response

But we need to ENFORCE paths adviced/offered by the enterprise and/or NSP/ISP to be used (to cope with the problems).

Do you see an alternate way/method of doing that, not using TURN?
 
/Karl

-----Ursprungligt meddelande-----
Från: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]] 
Skickat: den 12 februari 2014 08:01
Till: Karl Stahl; 'Simon Perreault'; [email-masked]; [email-masked]
Ämne: RE: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs

Hi Karl,

-Tiru.

> Subject: SV: [tram] Milestone 3: TURN server auto-discovery mechanism 
> for enterprise and ISPs
> 
> Tireddy wrote below > There are various ways to prioritize WebRTC 
> media streams and I don't see a need to block P2P connectivity.
> 
> - If we consider the case of WebRTC traffic over Internet/mobile OTT 
> (not talking about feeding WebRTC into some application specific 
> network like IMS where they may be other quality measures), we get 
> lost quality wise already when (if) we allow prioritized WebRTC 
> traffic to go into a congestion point (like a NAT/firewall or default 
> gateway, where there may be heavy data traffic already filling the pipe.
> - That is the "need to block P2P connectivity" (which may sound ugly 
> but is really about assuring that we CAN get P2P connectivity with 
> best quality, with help of service providers and LAN administrators 
> that want WebRTC traffic to be good and accessible...)
> 
> > Since the provisioning of auto- discovery using the anycast 
> > mechanism, would be adding a route in a default gateway, adding a 
> > firewall rule to eat STUN packets would assure that the provisioned 
> > TURN server actually becomes used (and not bypassed "by accident"). 
> > (That was the thought behind the “automatically” within quotes.)
> 
> - If we consider the case of WebRTC traffic over Internet/mobile OTT 
> (not talking about feeding WebRTC into some application specific 
> network like IMS where they may be other quality measures), we get 
> lost quality wise already when (if) we allow prioritized WebRTC 
> traffic to go into a congestion point (like a NAT/firewall or default 
> gateway, where there may be heavy data traffic already filling the pipe.
> - That is the "need to block P2P connectivity" (which may sound ugly 
> but is really about assuring that we CAN get P2P connectivity with 
> best quality, with help of service providers and LAN administrators 
> that want WebRTC traffic to be good and accessible...)
> 
>  Using TURN server itself endpoint can learn server-reflexive 
> candidates. If there is a restrictive firewall that blocks P2P 
> connectivity then relayed candidate would eventually be nominated 
> because ICE connectivity check fails with other candidate types.
> 
> I don't see any need to advertise only relayed candidates in the 
> offer/answer other than for privacy reasons.
> 
> -Tiru.
> 
> > provided and discovered, CURRENT usage of ICE may suggest a 
> > candidate from the remote party that will make a connection without 
> > the need/usage of the TURN server (that we wanted to be used for the 
> > good
> purposes listed).
> >
> > Since the provisioning of auto- discovery using the anycast 
> > mechanism, would be adding a route in a default gateway, adding a 
> > firewall rule to eat STUN packets would assure that the provisioned 
> > TURN server actually becomes used (and not bypassed "by accident"). 
> > (That was the thought behind the “automatically” within quotes.)
> >
> > power to enforce WebRTC usage of ICE, I believe a MUST requirement 
> > to use an auto- discovered TURN server instead of STUN, would solve 
> > the
> same problem.
> > However, thinking further (in relation to your next question - 
> > "anyone could set up a badly-maintained" - enforcing such ICE usage 
> > may not be
> > good.)
> >
> >
> > > STUN/TURN to be built in the default gateway or 
> > > NAT/firewall/access router itself, with a second interface to a 
> > > public IP address on the WAN side. (Current volume deployed, low 
> > > cost NSP triple play modems usually have a quality assured level 2 
> > > or level 3 WAN pipe for just voice (and another for IPTV) – The 
> > > anycast discovered TURN-server can be the access gateway to such 
> > > quality pipe for WebRTC media, in a single NSP provided CPE, 
> > > scaling from residential and up.)
> >
> > Suppose we define well-known anycast TURN server addresses. How 
> > would this not be subject to the same service quality issues that 
> > plagued 6to4? That is, anyone could set up a badly-maintained, 
> > An auto-discovered TURN server must be trusted (whatever method it 
> > is discovered by). We are trusting the one providing us with an IP 
> > address and default gateway anyway. It would be easy if we could 
> > reuse that trust, instead of another mechanisms.
> >
> > Is there a good way for the browser to check that the anycast 
> > address is not handled beyond the network service provider's default gateway?
> Ideas?
> >
> >
> >
> > Thanks,
> > Simon
> > --

---

From: "Karl Stahl" <[email-masked]>
Date: Thu, 13 Feb 2014 12:37:23 +0100

“Forcing all traffic through” a path announced by the enterprise and/or NSP/ISP is NECESSARY to copy with the problems to be able to “provide the best user experience”

/Karl

Från: Muthu Arul Mozhi Perumal (mperumal) [mailto:[email-masked]] 
Skickat: den 12 februari 2014 08:32
Till: Justin Uberti; Karl Stahl
Kopia: [email-masked]; Marc Blanchet; [email-masked]; Dan Wing (dwing); Simon Perreault
Ämne: RE: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs

+1

Muthu

Inline.

Also considering

This is good, not evil!

/Karl

 

+1.

 

  * mobility

  * enhancing privacy

-d

-d

 

Simon,

/Karl

-----Ursprungligt meddelande-----
Från: tram [mailto:[email-masked]] För Simon Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl Stahl; [email-masked]; [email-masked]
Ämne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs

Karl,

Thanks,
Simon

---

From: "Karl Stahl" <[email-masked]>
Date: Thu, 13 Feb 2014 12:37:52 +0100

An auto-discovered TURN server should advice the best (and maybe only) path.
The Enterprise and/or NSP/ISP making this announcement/offer of the TURN
server are the ones that knows (can know).

/Karl

Från: Oleg Moskalenko [mailto:[email-masked]] 
Skickat: den 12 februari 2014 08:37
Till: Muthu Arul Mozhi Perumal (mperumal)
Kopia: Justin Uberti; Karl Stahl; [email-masked]; Marc Blanchet;
[email-masked]; Dan Wing (dwing); Simon Perreault
Ämne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for
enterprise and ISPs

On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi Perumal (mperumal)
<[email-masked]> wrote:

+1

Forcing all traffic through a TURN server and expecting it would provide the
best user experience doesn't look the right approach. Instead, if a path
through a TURN server exists and does provide lower RTT, jitter etc, being
able to detect and use (or switch to) that path might be desirable..

Muthu

From: tram [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: Wednesday, February 12, 2014 11:43 AM
To: Karl Stahl
Cc: [email-masked]; Marc Blanchet; [email-masked]; Dan Wing (dwing);
Simon Perreault
Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for
enterprise and ISPs

Inline.

Also considering

This is good, not evil!

Skype, Hangouts, Facetime are doing billions of minutes per week and the
Internet has not melted yet. If we need to do flow identification to allow
traffic to be prioritized, fine (see above regarding my preferred approach),
but forcing all WebRTC traffic through a MITM (TURN server) is a much bigger
jump that I don't yet see the justification for.

/Karl

 

+1.

 

  * mobility

  * enhancing privacy

-d

-d

 

Simon,

/Karl

-----Ursprungligt meddelande-----
Från: tram [mailto:[email-masked]] För Simon Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl Stahl; [email-masked]; [email-masked]
Ämne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for
enterprise and ISPs

Karl,

Thanks,
Simon

---

From: "Karl Stahl" <[email-masked]>
Date: Thu, 13 Feb 2014 12:38:48 +0100

Just ICE may result in that the remote end’s proposal overrides a path that quality wise is better to use.

That is why we (also) must assure that an auto-discovered TURN server actually is used, (instead of a path suggested by the remote end).  

/Karl

Från: Justin Uberti [mailto:[email-masked]] 
Skickat: den 12 februari 2014 18:46
Till: Muthu Arul Mozhi Perumal (mperumal)
Kopia: Oleg Moskalenko; Karl Stahl; [email-masked]; Marc Blanchet; [email-masked]; Dan Wing (dwing); Simon Perreault
Ämne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs

On Wed, Feb 12, 2014 at 1:27 AM, Muthu Arul Mozhi Perumal (mperumal) <[email-masked]> wrote:

Muthu

On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi Perumal (mperumal) <[email-masked]> wrote:

+1

Muthu

Inline.

Also considering

This is good, not evil!

/Karl

 

+1.

 

  * mobility

  * enhancing privacy

-d

-d

 

Simon,

/Karl

-----Ursprungligt meddelande-----
Från: tram [mailto:[email-masked]] För Simon Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl Stahl; [email-masked]; [email-masked]
Ämne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs

Karl,

Thanks,
Simon

---

From: "Karl Stahl" <[email-masked]>
Date: Thu, 13 Feb 2014 12:39:32 +0100

It is the Enterprise and/or NSP/ISP making the announcement/offer of the
TURN server (by the auto-discovery discussed here) that are the ones that
knows and controls the path advised! And their intent/purpose should be
good….

/Karl

Från: Muthu Arul Mozhi Perumal (mperumal) [mailto:[email-masked]] 
Skickat: den 12 februari 2014 10:28
Till: Oleg Moskalenko
Kopia: Justin Uberti; Karl Stahl; [email-masked]; Marc Blanchet;
[email-masked]; Dan Wing (dwing); Simon Perreault
Ämne: RE: [tram] Milestone 3: TURN server auto-discovery mechanism for
enterprise and ISPs

Yes, I believe the second case is rare, but would be better than a rat race
b/w administrators trying to block p2p traffic and force it through a TURN
server and apps/endpoints finding smarter ways to bypass them.

Muthu

Cc: Justin Uberti; Karl Stahl; [email-masked]; Marc Blanchet;

+1

Muthu

Inline.

Also considering

This is good, not evil!

/Karl

 

+1.

 

  * mobility

  * enhancing privacy

-d

-d

 

Simon,

/Karl

-----Ursprungligt meddelande-----
Från: tram [mailto:[email-masked]] För Simon Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl Stahl; [email-masked]; [email-masked]
Ämne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for
enterprise and ISPs

Karl,

Thanks,
Simon

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Thu, 13 Feb 2014 12:20:12 +0000

|Just ICE may result in that the remote end’s proposal overrides a path
|that quality wise is better to use.

Then, that's an ICE implementation and should be fixed.

|That is why we (also) must assure that an auto-discovered TURN server
|actually is used, (instead of a path suggested by the remote end).

Again, if the auto-discovered TURN server provides a better quality path, ICE should be able to discover that path and use it -- that's the best long term solution, IMO.

Muthu

From: tram [mailto:[email-masked]] On Behalf Of Karl Stahl
Sent: Thursday, February 13, 2014 5:09 PM
To: 'Justin Uberti'; Muthu Arul Mozhi Perumal (mperumal)
Cc: [email-masked]; 'Simon Perreault'; 'Oleg Moskalenko'; [email-masked]; 'Marc Blanchet'; Dan Wing (dwing)
Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs

/Karl

Kopia: Oleg Moskalenko; Karl Stahl; [email-masked]<mailto:[email-masked]>; Marc Blanchet; [email-masked]<mailto:[email-masked]>; Dan Wing (dwing); Simon Perreault

Muthu

Muthu

Inline.

This is good, not evil!

/Karl

+1.

-d

-d

/Karl

-----Ursprungligt meddelande-----
Från: tram [mailto:[email-masked]<mailto:[email-masked]>] För Simon Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl Stahl; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Ämne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs

Karl,

Thanks,
Simon

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Thu, 13 Feb 2014 12:23:18 +0000

What if the user is multihomed, connected to 2 ISPs, and both advertise a TURN server? How would you rank their intents?

Muthu

From: tram [mailto:[email-masked]] On Behalf Of Karl Stahl
Sent: Thursday, February 13, 2014 5:10 PM
To: Muthu Arul Mozhi Perumal (mperumal); 'Oleg Moskalenko'
Cc: [email-masked]; 'Simon Perreault'; [email-masked]; 'Justin Uberti'; 'Marc Blanchet'; Dan Wing (dwing)
Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs

It is the Enterprise and/or NSP/ISP making the announcement/offer of the TURN server (by the auto-discovery discussed here) that are the ones that knows and controls the path advised! And their intent/purpose should be good....
/Karl

Från: Muthu Arul Mozhi Perumal (mperumal) [mailto:[email-masked]]
Skickat: den 12 februari 2014 10:28
Till: Oleg Moskalenko
Kopia: Justin Uberti; Karl Stahl; [email-masked]; Marc Blanchet; [email-masked]; Dan Wing (dwing); Simon Perreault
Ämne: RE: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs

Muthu

Muthu

Inline.

This is good, not evil!

/Karl

+1.

-d

-d

/Karl

-----Ursprungligt meddelande-----
Från: tram [mailto:[email-masked]<mailto:[email-masked]>] För Simon Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl Stahl; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Ämne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs

Karl,

Thanks,
Simon

---

From: "Karl Stahl" <[email-masked]>
Date: Thu, 13 Feb 2014 14:13:53 +0100

Good point!

Then the user/its enterprise must decide, which should be taken care by
recommended 

WEB BROWSER BEHAVIOUR:

It is previously suggested, and to some extent discussed, that the WebRTC
browser should select the TURN server to use in the following priority
order, where ICE would assure that you get some connectivity if several
candidates are found and needs to be tested:

1) TURN server address configured in the browser by the user (special cases,
normally not used, but handy for testing)

2) TURN server address configured by the network administrator via an “admin
policy template” or a WPAD method as mentioned below

 

Step 2) and step 3) allows the Enterprise to select/advice to place the
media to the best ISP 

(whether he will do it based on quality, cost or availability)

I cannot see there is a good way rank intents with the Enterprise in charge
(using 2, or 3)

/Karl

Från: tram [mailto:[email-masked]] För Muthu Arul Mozhi Perumal
(mperumal)
Skickat: den 13 februari 2014 13:23
Till: Karl Stahl; 'Oleg Moskalenko'
Kopia: [email-masked]; 'Simon Perreault'; [email-masked]; 'Justin
Uberti'; 'Marc Blanchet'; Dan Wing (dwing)
Ämne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for
enterprise and ISPs

What if the user is multihomed, connected to 2 ISPs, and both advertise a
TURN server? How would you rank their intents?

Muthu

From: tram [mailto:[email-masked]] On Behalf Of Karl Stahl
Sent: Thursday, February 13, 2014 5:10 PM
To: Muthu Arul Mozhi Perumal (mperumal); 'Oleg Moskalenko'
Cc: [email-masked]; 'Simon Perreault'; [email-masked]; 'Justin Uberti';
'Marc Blanchet'; Dan Wing (dwing)
Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for
enterprise and ISPs

/Karl

Muthu

+1

Muthu

Inline.

Also considering

This is good, not evil!

/Karl

 

+1.

 

  * mobility

  * enhancing privacy

-d

-d

 

Simon,

/Karl

-----Ursprungligt meddelande-----
Från: tram [mailto:[email-masked]] För Simon Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl Stahl; [email-masked]; [email-masked]
Ämne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for
enterprise and ISPs

Karl,

Thanks,
Simon

---

From: "Karl Stahl" <[email-masked]>
Date: Thu, 13 Feb 2014 14:23:03 +0100

Från: Muthu Arul Mozhi Perumal (mperumal) [mailto:[email-masked]] 
Skickat: den 13 februari 2014 13:20
Till: Karl Stahl; 'Justin Uberti'
Kopia: [email-masked]; 'Simon Perreault'; 'Oleg Moskalenko'; [email-masked]; 'Marc Blanchet'; Dan Wing (dwing)
Ämne: RE: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs

--- ICE can unfortunately do this by itself. We and the browser have to use ICE in a way that this is achieved (or the enterprise/NSP can stop STUN tests from reaching the public side, thus inhibiting overriding path-proposals from the remote side). 

--- Yes, but ICE needs our and the browsers help/advice how to do it (no change to ICE needed)

Muthu

/Karl

Muthu

+1

Muthu

Inline.

Also considering

This is good, not evil!

/Karl

 

+1.

 

  * mobility

  * enhancing privacy

-d

-d

 

Simon,

/Karl

-----Ursprungligt meddelande-----
Från: tram [mailto:[email-masked]] För Simon Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl Stahl; [email-masked]; [email-masked]
Ämne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs

Karl,

Thanks,
Simon

---

From: Simon Perreault <[email-masked]>
Date: Thu, 13 Feb 2014 09:17:07 -0500

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?
b) Is TURN the best, most appropriate solution?

Simon

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Thu, 13 Feb 2014 14:40:30 +0000

> 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

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 13 Feb 2014 16:57:42 +0000

> Sent: Thursday, February 13, 2014 5:06 PM
> But we need to ENFORCE paths adviced/offered by the enterprise and/or
> NSP/ISP to be used (to cope with the problems).
> 

Yes, http://tools.ietf.org/search/draft-penno-pcp-mobile-qos-00 explains how P2P media streams can be identified and differentiated QoS services can be provided by the ISP without forcing WebRTC client to only advertise relayed candidates.

-Tiru.

> Yes, there is a problem but P2P WebRTC streams (both media and data
> channels) can be identified and QoS can be provided by the access network
> without forcing TURN to be used. You may want to look into PCP FLOWDATA
> (http://tools.ietf.org/html/draft-wing-pcp-flowdata-00), MALICE
> (http://tools.ietf.org/html/draft-martinsen-mmusic-malice-00).
> 
> -Tiru.
>

---

From: "Karl Stahl" <[email-masked]>
Date: Mon, 17 Feb 2014 12:51:39 +0100

Interesting thoughts, inline comments below -->

-----Ursprungligt meddelande-----
Från: tram [mailto:[email-masked]] För Pal Martinsen (palmarti)
Skickat: den 13 februari 2014 15:40
Till: [email-masked]
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 <[email-masked]>
wrote:

> problem identified by Karl. (I understand the problem to be: "ISP 
> wants to provide enhanced QoS to WebRTC.")
> 
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