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

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 13 Feb 2014 10:47:50 +0000

The prime use case for this is documented in http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-12#section-3.3.5.1 and I think that TRAM will probably make enhancements to TURN enabling such an “enterprise auditing TURN server” to do an effective job of managing WebRTC traffic in an enterprise.

There are of course more than one problem and many possibly ways to solve them and I recently updated http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-03 to list these for discussion including PCP.

Unfortunately solutions are needed today within existing networks and PCP does not seem so useful here so we have to look at multiple solutions and probably WebRTC browsers have to support a number of mechanisms.

Regards
Andy

From: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Sent: 13 February 2014 03:37
To: Hutton, Andrew; 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

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]<mailto:[email-masked]>; Simon Perreault; Oleg Moskalenko; [email-masked]<mailto:[email-masked]>; Marc Blanchet; Dan Wing (dwing); Karl Stahl
Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs

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]<mailto:[email-masked]>; Simon Perreault; Oleg Moskalenko; [email-masked]<mailto:[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

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

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]<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.

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.

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.

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

Ä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]<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:

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).

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

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

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

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

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?
--- 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.)

> - 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.
--- 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<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

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

---

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

On the side of this TRAM-list, I also got this question:

> Regarding the enterprise case, I am not sure I follow your argument.

> Do you mean that by setting up an enterprise TURN server, and open the firewall for media over UDP from/to TURN server be the solution?

---- As we all realize, that would of course not help or improve things

The intended solution in the enterprise case has not yet been spelled out in this TRAM-list discussion, so for better understanding, let me copy a few things from the discussion in September/October on the RTCWEB-list and what is (since long) spelled out in the draft-ietf-rtcweb-use-cases-and-requirements.

For better understanding, I also want to point out that a TURN can have two interfaces (acting like a router for media between different networks). This allows to easier understand that can TURN servers can direct a best media path (rather than just thinking that a TURN service is a device which media just bounces against at one interface). 

And, we can also hope for that a TURN server becomes a (common) component of a firewall, which would allow the firewall to understand that the media directed to it is RTC and should be prioritized whereby the firewall can traffic shaped (back-off data traffic that may be filling its Internet pipe) as well as e.g. set diffserve bits or take other measures to assist proper quality handling thought the network. (These are common mechanisms available and used in firewalls/NATs/access routers, but TURN servers are not yet included such devices.) The same goes for access routers/default gateways, DPIs in the transport network itself – TURN servers included in such points were media can pass and quality measures applied may/will be very useful to get us WebRTC media with through networks without quality destruction.

>From the RTCWEB mailing list September 20th (by me):

An enterprise network that want to keep a restrictive firewall not allowing UDP traffic, could provide a real-time path using a TURN server paralleling the firewall, instead of tunneling RTP through always open http or https ports resulting in RTP media over TCP – with severe quality problems from TCP retransmissions of dropped packets. The TURN server address is most easily provided in the same way as the IP address and DNS address. (That would also put the right party in control – The network provider (here the enterprise) decides what is allowed on his network.)

The browser should select which available TURN server address to use in the following priority order, where ICE could be used to try several:

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

2) TURN server address configured by the network administrator via an “admin policy template”

3) TURN server address supplied by DHCP or similar automatic network method

4) TURN server address being supplied by the web application"

And from yesterdays(!) http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14 these enterprise things and necessity are spelled out in:

F19     The browser must be able to use several STUN and TURN servers

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

A22

 <http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.5> 3.3.5.  Simple Video Communication Service, enterprise aspects

 <http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.5.1> 3.3.5.1.  Description

   This use-case is similar to the Simple Video Communication Service

   use-case (Section 3.3.1 <http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.1> ).

   What is added is aspects when using the service in enterprises.  ICE

   is assumed in the further description of this use-case.

   An enterprise that uses a RTCWEB based web application for

   communication desires to audit all RTCWEB based application sessions

   used from inside the company towards any external peer.  To be able

   to do this they deploy a TURN server that straddles the boundary

   between the internal and the external network.

   The firewall will block all attempts to use STUN with an external

   destination unless they go to the enterprise auditing TURN server.

   In cases where employees are using RTCWEB applications provided by an

   external service provider they still want the traffic to stay inside

   their internal network and in addition not load the straddling TURN

   server, thus they deploy a STUN server allowing the RTCWEB client to

   determine its server reflexive address on the internal side.  Thus

   enabling cases where peers are both on the internal side to connect

   without the traffic leaving the internal network.  It must be

   possible to configure the browsers used in the enterprise with

   network specific STUN and TURN servers.  This should be possible to

  achieve by auto-configuration methods.  The RTCWEB functionality will

   need to utilize both network specific STUN and TURN resources and

   STUN and TURN servers provisioned by the web application.

 <http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.5.2> 3.3.5.2.  Additional Requirements

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

   REQ-ID      DESCRIPTION

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

   F20     The browser must support the use of STUN and TURN

           servers that are supplied by entities other than

           the web application (i.e. the network provider).

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

There are further requirement listed, helping us to understand the need for auto discovery and a network provided TURN-server should be used to ENFORCE that media takes that path (and thus, other paths e.g. suggested by the remote MUST not happen to be used). This is related to the mobility aspect (valid even without the roaming idea):

 <http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.6> 3.3.6.  Simple Video Communication Service, access change

 <http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.6.1> 3.3.6.1.  Description

   This use-case is almost identical to the
   Simple Video Communication Service use-case (Section 3.3.1 <http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.1> ).  The
   difference is that the user changes network access during the
   session.
 
   The communication device used by one of the users has several network
   adapters (Ethernet, WiFi, Cellular).  The communication device is
   accessing the Internet using Ethernet, but the user has to start a
   trip during the session.  The communication device automatically
   changes to use WiFi when the Ethernet cable is removed and then moves
   to cellular access to the Internet when moving out of WiFi coverage.
   The session continues even though the access method changes.

 <http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.6.2> 3.3.6.2.  Additional Requirements

   ----------------------------------------------------------------
   REQ-ID      DESCRIPTION
   ----------------------------------------------------------------
   F17     The communication session must survive across a
           change of the network interface used by the
           session
   ----------------------------------------------------------------

 <http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.7> 3.3.7.  Simple Video Communication Service, QoS

 <http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.7.1> 3.3.7.1.  Description

   This use-case is almost identical to the
   Simple Video Communication Service, access change use-case
   (Section 3.3.6 <http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.6> ).  The use of Quality of Service (QoS) capabilities is
   added:
 
   The user in the previous use case that starts a trip is behind a
   common residential router that supports prioritization of traffic.
   In addition, the user's provider of cellular access has QoS support
   enabled.  The user is able to take advantage of the QoS support both
   when accessing via the residential router and when using cellular.

 <http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.7.2> 3.3.7.2.  Additional Requirements

   ----------------------------------------------------------------
   REQ-ID      DESCRIPTION
   ----------------------------------------------------------------
   F17     The communication session must survive across a
           change of the network interface used by the
           session
   ----------------------------------------------------------------
   F22     The browser must be able to receive streams and
           data from multiple peers concurrently.
   ----------------------------------------------------------------

Further from the RTCWEB mailing list September 20th (by me):

There are several reasons for a network service provider to supply a TURN server as part of his offered access:

- to keep media paths short, specifically not sending media outside its own network to some distant application provided TURN server

- to support mobility, i.e. you may want to move from a LAN with a configured TURN server to accessing via WiFi or 3G/4G OTT channels

- to offer a media path with better quality (than best effort data traffic).

Getting “WebRTC-ready” access and we look forward to telepresence for everyone.

I hope this (a bit lengthy) summary of already thought-out and discussed aspects/requirements will help us understand that the auto-discovered TURN server is an ORDER from the enterprise and/or the NSP/ISP  to send the media through this TURN path, and that other media paths that may exist MUST NOT BE USED. (That is why we especially have to watch/advice that workable media paths proposed by the remote party not becomes used “by accident”.

/Karl

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

Hi Andy,

-Tiru.

Andy

From: tram [ <mailto:[email-masked]> mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: 12 February 2014 17:46
To: Muthu Arul Mozhi Perumal (mperumal)
Cc:  <mailto:[email-masked]> [email-masked]; Simon Perreault; Oleg Moskalenko;  <mailto:[email-masked]> [email-masked]; Marc Blanchet; Dan Wing (dwing); Karl Stahl
Subject: 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

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

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

+1

Muthu

From: tram [mailto: <mailto:[email-masked]> [email-masked]] On Behalf Of Justin Uberti
Sent: Wednesday, February 12, 2014 11:43 AM
To: Karl Stahl
Cc:  <mailto:[email-masked]> [email-masked]; Marc Blanchet;  <mailto:[email-masked]> [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]> wrote:

Also considering

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: <mailto:[email-masked]> [email-masked]] 
Skickat: den 11 februari 2014 18:25
Till: Marc Blanchet
Kopia: Justin Uberti;  <mailto:[email-masked]> [email-masked]; Karl Stahl;  <mailto:[email-masked]> [email-masked]; Simon Perreault

 

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

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

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

+1.

 

  * mobility

  * enhancing privacy

-d

-d

 

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

Simon,

/Karl

-----Ursprungligt meddelande-----
Från: tram [mailto: <mailto:[email-masked]> [email-masked]] För Simon Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl Stahl;  <mailto:[email-masked]> [email-masked];  <mailto:[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
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/tram> 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

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

[email-masked]

---

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

IMPORTANT CLARIFICATIONS I THINK:

 

A22

   REQ-ID      DESCRIPTION

 

 

 

/Karl

Hi Andy,

-Tiru.

Andy

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: <mailto:[email-masked]> [email-masked]] För Simon Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl Stahl;  <mailto:[email-masked]> [email-masked];  <mailto:[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 13:04:24 +0100

Note that some things being questioned in this discussion already are in the draft-ietf-rtcweb-use-cases-and-requirements document (pointed out below). I think this may clarify some things also…

 

A22

   REQ-ID      DESCRIPTION

 

 

 

/Karl

Hi Andy,

-Tiru.

Andy

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

Karl,

Thanks,
Simon

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 13 Feb 2014 15:34:10 +0000

Hi Andy,

Yes, WebRTC browser will have to a support a number of mechanisms. This was discussed in RTCWEB mailing list sometime back and section 3.3.4.1 in http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14 has been updated to reflect this point.
Can you please clarify the enhancements TURN server you are looking for and what problems does it solve ?

-Tiru.
From: Hutton, Andrew [mailto:[email-masked]]
Sent: Thursday, February 13, 2014 4:18 PM
To: Tirumaleswar Reddy (tireddy)
Cc: [email-masked]
Subject: RE: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs

Regards
Andy

Hi Andy,

-Tiru.

Andy

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: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 13 Feb 2014 16:47:16 +0000

Hi Karl,

I did not understand how TURN server will identify if it’s WebRTC media streams or gaming traffic or some other data traffic relayed through it to set the diffserv bits correctly !

-Tiru.
From: Karl Stahl [mailto:[email-masked]]
Sent: Thursday, February 13, 2014 5:05 PM
To: Tirumaleswar Reddy (tireddy); 'Hutton, Andrew'; 'Justin Uberti'; Muthu Arul Mozhi Perumal (mperumal)
Cc: [email-masked]; 'Simon Perreault'; 'Oleg Moskalenko'; [email-masked]; 'Marc Blanchet'; Dan Wing (dwing)
Subject: IMPORTANT CLARIFICATIONS: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs

A22
3.3.5<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.5>.  Simple Video Communication Service, enterprise aspects
3.3.5.1<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.5.1>.  Description
   This use-case is similar to the Simple Video Communication Service
   use-case (Section 3.3.1<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.1>).

3.3.5.2<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.5.2>.  Additional Requirements

There are further requirement listed, helping us to understand the need for auto discovery and a network provided TURN-server should be used to ENFORCE that media takes that path (and thus, other paths e.g. suggested by the remote MUST not happen to be used). This is related to the mobility aspect (valid even without the roaming idea):
3.3.6<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.6>.  Simple Video Communication Service, access change
3.3.6.1<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.6.1>.  Description

   Simple Video Communication Service use-case (Section 3.3.1<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.1>).  The

   session.

3.3.6.2<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.6.2>.  Additional Requirements

   REQ-ID      DESCRIPTION

           session

3.3.7<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.7>.  Simple Video Communication Service, QoS
3.3.7.1<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.7.1>.  Description

   (Section 3.3.6<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.6>).  The use of Quality of Service (QoS) capabilities is

   added:

3.3.7.2<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.7.2>.  Additional Requirements

   REQ-ID      DESCRIPTION

           session

/Karl

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

Hi Andy,

-Tiru.

Andy

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: Justin Uberti <[email-masked]>
Date: Thu, 13 Feb 2014 10:45:58 -0800

Karl,

You sent 23 messages to the list on this same thread in the past few hours.
This is not an effective way of presenting your ideas; I myself have lost
track of what you are hoping to accomplish.

Right now the only currently viable mechanism for auto-discovery is WPAD.
If you think the anycast mechanism is worth pursuing, I suggest writing it
up as an I-D.

There have also been several mechanisms proposed for doing QoS
provisioning, namely
http://tools.ietf.org/search/draft-penno-pcp-mobile-qos-00 and
http://tools.ietf.org/html/draft-martinsen-tram-discuss-00. If you think
those proposals are insufficient, I suggest pointing out your concerns in
threads specific to those documents.

Justin

On Thu, Feb 13, 2014 at 4:04 AM, Karl Stahl <[email-masked]> wrote:

> Note that some things being questioned in this discussion already are in
> the draft-ietf-rtcweb-use-cases-and-requirements document (pointed out
> below). I think this may clarify some things also…
>
>
>
>
>
> > Do you mean that by setting up an enterprise TURN server, and open the
> firewall for media over UDP from/to TURN server be the solution?
>
> The intended solution in the enterprise case has not yet been spelled out
> in this TRAM-list discussion, so for better understanding, let me copy a
> few things from the discussion in September/October on the RTCWEB-list and
> what is (since long) spelled out in the
> draft-ietf-rtcweb-use-cases-and-requirements.
>
>
>
> For better understanding, I also want to point out that a TURN can have
> two interfaces (acting like a router for media between different networks).
> This allows to easier understand that can TURN servers can direct a best
> media path (rather than just thinking that a TURN service is a device which
> media just bounces against at one interface).
>
>
>
> And, we can also hope for that a TURN server becomes a (common) component
> of a firewall, which would allow the firewall to understand that the media
> directed to it is RTC and should be prioritized whereby the firewall can
> traffic shaped (back-off data traffic that may be filling its Internet
> pipe) as well as e.g. set diffserve bits or take other measures to assist
> proper quality handling thought the network. (These are common mechanisms
> available and used in firewalls/NATs/access routers, but TURN servers are
> not yet included such devices.) The same goes for access routers/default
> gateways, DPIs in the transport network itself – TURN servers included in
> such points were media can pass and quality measures applied may/will be
> very useful to get us WebRTC media with through networks without quality
> destruction.
>
>
>
> An enterprise network that want to keep a restrictive firewall not
> allowing UDP traffic, could provide a real-time path using a TURN server
> paralleling the firewall, instead of tunneling RTP through always open http
> or https ports resulting in RTP media over TCP – with severe quality
> problems from TCP retransmissions of dropped packets. The TURN server
> address is most easily provided in the same way as the IP address and DNS
> address. (That would also put the right party in control – The network
> provider (here the enterprise) decides what is allowed on his network.)
>
>
>
> The browser should select which available TURN server address to use in
> the following priority order, where ICE could be used to try several:
>
>
>
> And from yesterdays(!)
> http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14these enterprise things and necessity are spelled out in:
>
>
>
> *3.3.5*<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.5>*.
> Simple Video Communication Service, enterprise aspects*
>
> *3.3.5.1*<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.5.1>*.
> Description*
>
> *3.3.5.2*<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.5.2>*.
> Additional Requirements*
>
> There are further requirement listed, helping us to understand the need
> for auto discovery and a network provided TURN-server should be used to
> ENFORCE that media takes that path (and thus, other paths e.g. suggested by
> the remote MUST not happen to be used). This is related to the mobility
> aspect (valid even without the roaming idea):
> 3.3.6<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.6>.
> Simple Video Communication Service, access change 3.3.6.1<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.6.1>.
> Description
>
>    Simple Video Communication Service use-case (Section 3.3.1 <http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.1>).  The
>
> 3.3.7<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.7>.
> Simple Video Communication Service, QoS 3.3.7.1<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.7.1>.
> Description
>
>    (Section 3.3.6 <http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#section-3.3.6>).  The use of Quality of Service (QoS) capabilities is
>
>    added:
>
>
>
> - to keep media paths short, specifically not sending media outside its
> own network to some distant application provided TURN server
>
> - to support mobility, i.e. you may want to move from a LAN with a
> configured TURN server to accessing via WiFi or 3G/4G OTT channels
>
> I hope this (a bit lengthy) summary of already thought-out and discussed
> aspects/requirements will help us understand that the auto-discovered TURN
> server is an ORDER from the enterprise and/or the NSP/ISP  to send the
> media through this TURN path, and that other media paths that may exist
> MUST NOT BE USED. (That is why we especially have to watch/advice that
> workable media paths proposed by the remote party not becomes used “by
> accident”.
>
>
>
> /Karl
>
>
>
>
>
> *Från:* Tirumaleswar Reddy (tireddy) [mailto:[email-masked]<[email-masked]>]
>
> *Skickat:* den 13 februari 2014 04:37
> *Till:* Hutton, Andrew; Justin Uberti; Muthu Arul Mozhi Perumal (mperumal)
> *Kopia:* [email-masked]; Simon Perreault; Oleg Moskalenko;
> [email-masked]; Marc Blanchet; Dan Wing (dwing); Karl Stahl
> *Ämne:* RE: [tram] Milestone 3: TURN server auto-discovery mechanism for
> enterprise and ISPs
>
>
>
> 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] <[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
>
>
>
> 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] <[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.
>
>
>
> 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).
>
>
>
> 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.
>
>
>
> - 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.
>
>
>
> 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.
>
>
>
> 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
>
>
>
>
>
> On Feb 11, 2014, at 9:08 AM, Marc Blanchet <[email-masked]>
> wrote:
>
>
>
> Le 2014-02-11 à 00:39, Dan Wing <[email-masked]> a écrit :
>
>
>
>
> 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.
>
>
>
>
>
> 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
>
>
>
>
>
>
>
>
>
> On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl <[email-masked]
> > wrote:
>
> Simon,
>
> Från: tram [mailto:[email-masked]] För Simon Perreault
> Till: Karl Stahl; [email-masked]; [email-masked]
> 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
> --
> 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: Justin Uberti <[email-masked]>
Date: Thu, 13 Feb 2014 10:52:37 -0800

On Thu, Feb 13, 2014 at 10:45 AM, Justin Uberti <[email-masked]> wrote:

> Karl,
>
> You sent 23 messages to the list on this same thread in the past few
> hours. This is not an effective way of presenting your ideas; I myself have
> lost track of what you are hoping to accomplish.
>

I now see that http://www.ietf.org/id/draft-patil-tram-turn-serv-disc-00.txtcovers
the anycast mechanism.

> On Thu, Feb 13, 2014 at 4:04 AM, Karl Stahl <[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
>>
>>
>>
>>
>>
>> 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).
>>
>>
>>
>> *Cc:* [email-masked]; Marc Blanchet; [email-masked]; Dan Wing
>> (dwing); Simon Perreault
>> - 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
>> - 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
>>
>>
>>
>> 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
>> 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
>> 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
>>
>>
>>
>>
>>
>> The only way we found around this, was to stop STUN through the IP
>> default gateway (like a restrictive Enterprise firewall does inhibiting ICE
>> 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
>> 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

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 13 Feb 2014 19:25:46 +0000

One such enhancement is described in http://tools.ietf.org/html/draft-johnston-tram-stun-origin-01.

Andy

From: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Sent: 13 February 2014 15:34
To: Hutton, Andrew
Cc: [email-masked]
Subject: RE: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs

Hi Andy,

-Tiru.
Cc: [email-masked]<mailto:[email-masked]>

Regards
Andy

Hi Andy,

-Tiru.

Andy

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: Mon, 17 Feb 2014 14:10:34 +0100

Tiru > I did not did not understand how TURN server will identify if it’s WebRTC media streams or gaming traffic or some other data traffic relayed through it to set the diffserv bits correctly !

--- I think you do understand… – but I will spell out that DISCUSS/MALICE does it better and with useful detail J

Pål, Tiru, Dan and you other thinking about these things:

What has been discussed by me here so far, to give us quality of real-time traffic over the Internet (not a small task) is:

1) To direct the real-time traffic to where the network can handle such traffic (using a network offered TURN servers) (which is not within the scope of DISCUSS)

2) When such a TURN server flow is allocated, it can ASSUME that it is going to used for real-time traffic and instruct the network (e g via setting diffserve bits) to prioritize the assumed real-time traffic. (Giving the same prioritization to all TURN traffic works quite well. – Only if we fill the whole pipe with prioritized traffic (best effort totally pushed off) is it important that e.g. voice if prioritized higher than video).

3) When the TURN server sees the flow coming in (Note: in both directions) it can do smarter guesswork of what traffic it is (like a DPI-box), e.g. what is RTP and what is data channel to instruct the network better.

Now after browsing http://tools.ietf.org/html/draft-martinsen-tram-discuss-00 

4) DISCUSS transfers information directly from the application to the network at the time of setup of the STUN or TURN(?) server, which it therefore can do with better detail and prediction. This is valuable, also for reserving bandwidth in non diffserve networks like Cable and  Mobile where one reserves bandwidth rather than use diffserve for QoS.

5) Isn’t DISCUSS usable with TURN? Maybe even better! And it can be used with 1) above J

You can transfer the same information in the TURN allocate request as in the STUN binding request, can’t you?. I searched for “TURN” in the DISCUSS draft, but could not see it spelled out. TURN is an extension to STUN, so maybe it is just obvious? – I have not checked details in the specs so Pål, Tiru or Dan knowing better, please confirm or correct!

Some observations:

a. In DISCUSS using STUN, the network element doing the diffserv or reservation settings WOULD be in the default gateway.

b. In DISCUSS using TURN, the TURN server doing the diffserv or reservation settings COULD be in the default gateway. (The auto-discovery of the TURN server would simply point out the default gateway.)

Sound very similar: Could not DISCUSS over TURN always be used?

c. With DISCUSS using TURN, the application would directly talk to the network device doing the diffserve settings etc. (instead of through it, where typically the default gateway would snope that talk). Would that not easy some of the concerns in the draft left for further discussion? 

d. Can we add info in the response? E.g. if the network device is only willing to give 1 Mbps instead of needed 3 Mbps, so the application can be informed to reduce his video resolution? Would be a nice mechanism when RTC alone starts filling our pipes. (I saw a similar idea by Pål in the previous email I just commented.)

6) Please add to the DISCUSS draft that it also could reserve bandwidth in bandwidth reservation type of networks like Cable and  Mobile networks!

A few more things are needed for the ultimate goal, bringing end-to-end QoS or QoE for real-time communication to Best Effort Internet (which does not seem impossible, but quite doable now J ) remains though. I’ll come back to those. 

It will e.g. relate to how to do with INCOMING traffic, especially in reservation type of networks, and the wild changing/stripping of diffserve bits between ISPs.

You may want to check this old discussion to see if this useful:

http://www.ietf.org/mail-archive/web/rtcweb/current/msg09128.html 

http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html 

/Karl

Från: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]] 
Skickat: den 13 februari 2014 17:47
Till: Karl Stahl
Kopia: [email-masked]
Ämne: RE: IMPORTANT CLARIFICATIONS: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs

Hi Karl,

-Tiru.

 

A22

   REQ-ID      DESCRIPTION

 

 

 

/Karl

Hi Andy,

-Tiru.

Andy

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: <mailto:[email-masked]> [email-masked]] För Simon Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl Stahl;  <mailto:[email-masked]> [email-masked];  <mailto:[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: Mon, 17 Feb 2014 08:55:55 -0500

Le 2014-02-17 08:10, Karl Stahl a écrit :
> 2) When such a TURN server flow is allocated, it can ASSUME that it is
> going to used for real-time traffic and instruct the network (e g via
> setting diffserve bits) to prioritize the assumed real-time traffic.
> (Giving the same prioritization to all TURN traffic works quite well. –
> Only if we fill the whole pipe with prioritized traffic (best effort
> totally pushed off) is it important that e.g. voice if prioritized
> higher than video).

What happens if subscribers start using the TURN server for BitTorrent
traffic?

(It can and it will happen if an ISP offers significant QoS enhancements
to TURN traffic. It takes just one person to implement it in
Transmission and then overnight the TURN server becomes saturated.)

Simon

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Wed, 19 Feb 2014 11:21:16 +0000

On 17 Feb 2014, at 14:10 pm, Karl Stahl <[email-masked]<mailto:[email-masked]>> wrote:

Tiru > I did not did not understand how TURN server will identify if it’s WebRTC media streams or gaming traffic or some other data traffic relayed through it to set the diffserv bits correctly !
--- I think you do understand… – but I will spell out that DISCUSS/MALICE does it better and with useful detail :)

I can se the usefulness of a TURN server to OTT service providers that have their own backhaul network to transport the packets. Using such a provider might enable a user to avoid “hot potato” routing problems that might occur on the Internet. If you quickly want to get your packets into such a OTT network service TURN is a good alternative. But, in such a scenario I would like the ICE agent to actually be able to detect that this is the best path. We currently miss a few bits to be able to do this. The discuss draft might help with some of that, but there are still bits missing.

To me this is not a QoS feature, it is a way to avoid potential “hot potato” routing problems.

I think to assume that TURN equals real-time traffic is wrong. It is a generic relay service and should be treated like that.

Yes. The would be able to see most of the traffic and may make smart correlations. But again there is no guarantee in the future that the traffic will be as symmetric as it is today.  As long as you have set the permissions correct, the TURN server would forward you the packets.

Yes.

But the values are expected to change, so the network should be able to pick up any STUN messages carrying this information even after the sessions established. We want to limit the information exchange during the ICE connectivity check to a bare minimum, but still be able to possibly take smarter path decisions once the connectivity checks are finished. Once the session is established some security can probably be relaxed and we have more time to actually signal more detailed information.

5) Isn’t DISCUSS usable with TURN? Maybe even better! And it can be used with 1) above :)
You can transfer the same information in the TURN allocate request as in the STUN binding request, can’t you?. I searched for “TURN” in the DISCUSS draft, but could not see it spelled out. TURN is an extension to STUN, so maybe it is just obvious? – I have not checked details in the specs so Pål, Tiru or Dan knowing better, please confirm or correct!

Yes. The discuss draft only defines a se of new STUN attributes. They can be used in any STUN/TURN message.

But there are some interesting pitfalls though. TURN allocation messages are sent during the ICE candidate discovery phase.  Once the connectivity checks commences we will have some STUN Binding Request tunnelled over the allocation in Send and Data indication messages.  Some thought should be done on how the network element between the TURN agent and TURN server should treat such messages if both of them contain some discuss attributes.  (How “deep” should it search for STUN packets containing discuss attributes, and what would they tell you)

I will try to write something describing this in the next version of the discuss draft.

Some observations:

Sure discuss attributes can be used with TURN allocation and session refresh messages to inform possible discuss aware network elements on that path what is going on.

Adding discuss attributes to TURN messages would help between the agent and the TURN server. Those messages would not go end to end, and would not help other network elements to “do the right thing”. This is useful, but a limiting factor.

There is a ECN like response in discuss that allows you to faster rate limit instead of waiting for the RTCP reports to do the trick.

Reporting available bandwidth consistently from a network element is tricky. It varies from device to device that it can report. Is it the entire downlink speed, or maximum bandwidth pr user/ip or pr application. If we can figure out a consistent way to report that, it would be very useful to the ICE state machine when choosing the path.

We have on purpose avoided wording like reservation. It implies user authentication and that opens up another can of worms. But reusing some of the discuss attributes and adding functionality to do reservation in another draft makes sense.

The discuss draft have a very limited scope. We want to keep it simple to implement for both applications and network elements. If it brings any real value needs more discussion. Hopefully those discussion can happen here in TRAM.
.-.
Pål-Erik

A few more things are needed for the ultimate goal, bringing end-to-end QoS or QoE for real-time communication to Best Effort Internet (which does not seem impossible, but quite doable now :) ) remains though. I’ll come back to those.

/Karl

Från: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Skickat: den 13 februari 2014 17:47
Till: Karl Stahl
Kopia: [email-masked]<mailto:[email-masked]>
Ämne: RE: IMPORTANT CLARIFICATIONS: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs

Hi Karl,

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

A22

   session.

   REQ-ID      DESCRIPTION

           session

   added:

   REQ-ID      DESCRIPTION

           session

/Karl

Hi Andy,

-Tiru.

Andy

Muthu

Muthu

Inline.

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).

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 :). (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,

Thanks,
Simon

---

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

Hi Pål and Tiru,

I was just about to catch up and respond to some of the points raised below,
but see that Pål has addressed a lot of them to which I mostly agree. See
below and inline to move this further:

Let me also point out the attached draft-deng-tram-isp-turn-00 from China
Mobile that appeared on this mailing list yesterday. It points out the need
and willingness from the ISP/NSP side to do something about QoS for WebRTC
traffic, that they expect to be large and have to bring to their customers
with best QoE. In fact they and some more (a huge European carrier and the
cable operators in general - CableLabs) have expressed similar concerns to
me “This is exactly something we want to work on as the current way will
cause severe problem on traffic when rtcweb applications get popular” is a
direct quote from one of those.

So, in answer to Simon Perreault [[email-masked]]’s question in
another thread the 13th:

a) Is this a real problem that is worth fixing?

I think we can be confident that the answer is *YES*. Only these three
ISP/NSP referred to, may represent 50%(?) of the universe’s IP accesses! And
the other will follow these most forward looking carriers. 

Even if the mission to bring quality to real-time traffic over our best
effort Internet is a huge mission, I am convinced it not a huge task – We
just be a bit clever here J. I only see these few standard steps required,
before it can happen!

A) Auto-discovered TURN servers 

B) Enforcing the real-time traffic through the offered/discovered TURN
servers 

(Discussed below: Detecting a flow is not enough – we need to enforce – more
input below.) 

C) Providing real-time traffic information from the application/browser to
the network element that has the flow and can apply QoS measures (that would
be “the box containing the TURN server”**) 

(DISCUSS- or draft-thomson-tram-turn-bandwidth-00.txt-like methods are being
discussed, but they do not do it all e.g. provide info of incoming traffic
and varying bandwidth requirements of smart codecs.)

D) Adding real-time traffic information to the media packets themselves, to
fix QoS where the above is not sufficient. This can both fix the lack of
type and bandwidth info of incoming traffic (even varying) at the TURN
points and also be of a great help across network boundaries/peering points,
where DSCP-bits are changed and when going into reservation type of networks
(cable and mobile) since DSCP-bits gives no clue of what bandwidth needs to
be reserved

Here I see the recreation of the idea/intention of the RTP payload type (PT)
header as the obvious (and only?) solution. (That payload type info is no
longer available though, since we use dynamic payload types and the SDP
where it says what it is all about, nowadays cannot be said to be available
to the network (usually encrypted and somewhere else than the media flow).
There is a trivial way of doing this although it has been “considered
impossible”, see
http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html. 

It is simply to add the bandwidth requirement and traffic type into two
parameters in the RTP header extension (which is visible in also in SRTP –
it is outside the encrypted payload - and the network can read it). That
information should also stay with the traffic (and not be changed around
like DSCP bits). The application/browser will also be able to change this
info during a call, e.g. to announce higher or lower bandwidth requirements
of varying bandwidth type of codecs or from application measures taken by
QoS feedback via RTCP. Further, these RTP extension header bits are easily
set by any browser using any operating system (which is not the case with
DSCP-bits).

This “trivial” thing is needed for the “huge mission” of “bringing quality
to real-time traffic over the best effort Internet”.  A framework is even
done in 

http://tools.ietf.org/html/draft-carlberg-avtext-classifier-00. 

*Time to get it done!*

Some further detail discussion inline below:

Some of which are *IMPORTANT*.

Från: Pal Martinsen (palmarti) [mailto:[email-masked]] 
Skickat: den 19 februari 2014 12:21
Till: Karl Stahl
Kopia: Tirumaleswar Reddy (tireddy); Dan Wing (dwing); [email-masked]
Ämne: Re: QoS for RTC over the Internet, DISCUSS: [tram] Milestone 3: TURN
server auto-discovery mechanism for enterprise and ISPs

On 17 Feb 2014, at 14:10 pm, Karl Stahl <[email-masked]> wrote:

Tiru > I did not did not understand how TURN server will identify if it’s
WebRTC media streams or gaming traffic or some other data traffic relayed
through it to set the diffserv bits correctly !

--- I think you do understand… – but I will spell out that DISCUSS/MALICE
does it better and with useful detail J

What has been discussed by me here so far, to give us quality of real-time
traffic over the Internet (not a small task) is:

1) To direct the real-time traffic to where the network can handle such
traffic (using a network offered TURN servers) (which is not within the
scope of DISCUSS)

I can se the usefulness of a TURN server to OTT service providers that have
their own backhaul network to transport the packets. Using such a provider
might enable a user to avoid “hot potato” routing problems that might occur
on the Internet. If you quickly want to get your packets into such a OTT
network service TURN is a good alternative. 

[Karl] Mentioning OTT (as the mobile world like to call their Internet) are
you hinting at the same that comes into my mind? Their DPI box is a good
place (the obvious?) for a TURN server (the DPI box then really has the flow
to dig deeper into) and may apply quality measures (reservation type)
through their PCRF policy server. In such case we cannot assume that the DPI
also is the default gate (or can we?) where DISCUSS-STUN could be used. We
need to direct/enforce the flow using TURN (and could then use
“DISCUSS-TURN”).

[TR] I still don’t understand the need to force the media traffic to be sent
through the TURN server either with DISCUSS or PCP.

[Karl] Another hands-on example where we have to enforce the real-time
traffic flow using TURN (instead of just detecting it at the default gateway
which is the consequence of STUN) is the way quality already is
implemented/deployed in >>millions of fixed line accesses. Just think about
the residential “triple play” offerings (I/Intertex/Ingate do such access
boxes), where you have three IP-pipes separated at lower levels (ADSL/ATM,
VLAN on Ethernet or MPLS etc). The “Surf Pipe” is the default gateway (it is
there a STUN flow happens), but the quality pipe we want to direct the
real-time traffic through is another one of these pipes (so far for voice or
IP-TV), where we can and must use TURN to direct/enforce the real-time media
flow into. 

[Karl] Also, considering the enterprise case (the enterprise providing the
auto-discovered TURN server);  It needs to use TURN (not STUN) to BYPASS the
firewall.

- For NAT/firewall traversal reasons: TURN is required to bypass if the
enterprise wants to maintain a restrictive firewall policy that does not
allow STUN.

- For Quality Reasons (the same): TURN is required to bypass if the
enterprise wants to maintain a restrictive firewall policy that does not
allow STUN.

*[Karl]* So, in short, we need TURN and its usage to be enforced by the
auto-discovery.

[Karl] Tiru, I have not (had time to) check up PCP. Do you have a pointer?
Is it still relevant?

But, in such a scenario I would like the ICE agent to actually be able to
detect that this is the best path. We currently miss a few bits to be able
to do this. The discuss draft might help with some of that, but there are
still bits missing.

*[Karl]* That is interesting – I did not think that was possible and may
have answered someone incorrectly (was it Oleg?) whether this is possible.

Does it not conflict with the usage of auto-detected TURN server that I
think we need to allow the browser to have some control over for special
cases? I am thinking of:

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 (Justin’s)

3) TURN server address auto-discovered by the mechanism discussed here [TRAM
Milestone 3]

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. 

Pål, are you thinking of a modification of ICE to allow the browser to tell
ICE to do this selection?

To me this is not a QoS feature, it is a way to avoid potential “hot potato”
routing problems. 

[Karl] The examples I just gave above shows it is both

2) When such a TURN server flow is allocated, it can ASSUME that it is going
to used for real-time traffic and instruct the network (e g via setting
diffserve bits) to prioritize the assumed real-time traffic. (Giving the
same prioritization to all TURN traffic works quite well. – Only if we fill
the whole pipe with prioritized traffic (best effort totally pushed off) is
it important that e.g. voice if prioritized higher than video).

I think to assume that TURN equals real-time traffic is wrong. It is a
generic relay service and should be treated like that. 

[Karl] My capitalizaition of ASSUME indicated that I fully agree J (I just
pointed out what is possible – not recommended)

3) When the TURN server sees the flow coming in (Note: in both directions)
it can do smarter guesswork of what traffic it is (like a DPI-box), e.g.
what is RTP and what is data channel to instruct the network better.

Yes. The would be able to see most of the traffic and may make smart
correlations. But again there is no guarantee in the future that the traffic
will be as symmetric as it is today.  As long as you have set the
permissions correct, the TURN server would forward you the packets.

[Karl]  Again, I fully agree J (“guesswork” indicates it is possible – not
recommended)
[TR] This assumption is not right and could result in false positives. 

[TR] I don’t think DPI will help, how will the TURN server differentiate b/w
audio and video streams when it is DTLS-SRTP ? 

Even the Home Router needs to treat these media streams differently but may
not see the need to deploy a TURN server. 

[Karl] I think we also agree that there are better methods we should use
(even if “guesswork” could be even smarter by linking RTP ids into flows,
making assumptions about that voice are smaller packets, video are full
packets etc. etc). Also, we don’t want to waste CPU power on smart guesswork
if there are better ways and further, we don’t want to prioritize more than
required (thus vasting valuable quality bandwidth). So I fully agree to use
better methods available.

Now after browsing
<http://tools.ietf.org/html/draft-martinsen-tram-discuss-00>
http://tools.ietf.org/html/draft-martinsen-tram-discuss-00

4) DISCUSS transfers information directly from the application to the
network at the time of setup of the STUN or TURN(?) server, which it
therefore can do with better detail and prediction. This is valuable, also
for reserving bandwidth in non diffserve networks like Cable and  Mobile
where one reserves bandwidth rather than use diffserve for QoS.

Yes.

But the values are expected to change, so the network should be able to pick
up any STUN messages carrying this information even after the sessions
established. We want to limit the information exchange during the ICE
connectivity check to a bare minimum, but still be able to possibly take
smarter path decisions once the connectivity checks are finished. Once the
session is established some security can probably be relaxed and we have
more time to actually signal more detailed information. 

*[Karl]* If we enforce TURN usage of the auto-discovered TURN server, we
don’t need to fix such obstacle, do we?

5) Isn’t DISCUSS usable with TURN? Maybe even better! And it can be used
with 1) above J

You can transfer the same information in the TURN allocate request as in the
STUN binding request, can’t you?. I searched for “TURN” in the DISCUSS
draft, but could not see it spelled out. TURN is an extension to STUN, so
maybe it is just obvious? – I have not checked details in the specs so Pål,
Tiru or Dan knowing better, please confirm or correct!

Yes. The discuss draft only defines a se of new STUN attributes. They can be
used in any STUN/TURN message.

[Karl] Very good J

But there are some interesting pitfalls though. TURN allocation messages are
sent during the ICE candidate discovery phase.  Once the connectivity checks
commences we will have some STUN Binding Request tunnelled over the
allocation in Send and Data indication messages.  Some thought should be
done on how the network element between the TURN agent and TURN server
should treat such messages if both of them contain some discuss attributes.
(How “deep” should it search for STUN packets containing discuss attributes,
and what would they tell you)

*[Karl]* Can this be said to relate to what I (above and otherwise) said
about that DISCUSS only apply to outgoing traffic (not incoming). [I admit
not having read/grasped all details of DISCUSS]. Can/is this addressed by
using info from my D) above: Adding the bandwidth requirement and traffic
type info into the RTP header extension?

I will try to write something describing this in the next version of the
discuss draft. 

*[Karl]* Please consider my D) above: Whether adding the bandwidth
requirement and traffic type into the RTP header extension can ease or fix
this!

Some observations:

a. In DISCUSS using STUN, the network element doing the diffserv or
reservation settings WOULD be in the default gateway.

b. In DISCUSS using TURN, the TURN server doing the diffserv or reservation
settings COULD be in the default gateway. (The auto-discovery of the TURN
server would simply point out the default gateway.)

Sure discuss attributes can be used with TURN allocation and session refresh
messages to inform possible discuss aware network elements on that path what
is going on. 

c. With DISCUSS using TURN, the application would directly talk to the
network device doing the diffserve settings etc. (instead of through it,
where typically the default gateway would snope that talk). Would that not
easy some of the concerns in the draft left for further discussion?

Adding discuss attributes to TURN messages would help between the agent and
the TURN server. Those messages would not go end to end, and would not help
other network elements to “do the right thing”. This is useful, but a
limiting factor. 

d. Can we add info in the response? E.g. if the network device is only
willing to give 1 Mbps instead of needed 3 Mbps, so the application can be
informed to reduce his video resolution? Would be a nice mechanism when RTC
alone starts filling our pipes. (I saw a similar idea by Pål in the previous
email I just commented.)

There is a ECN like response in discuss that allows you to faster rate limit
instead of waiting for the RTCP reports to do the trick. 

Reporting available bandwidth consistently from a network element is tricky.
It varies from device to device that it can report. Is it the entire
downlink speed, or maximum bandwidth pr user/ip or pr application. If we can
figure out a consistent way to report that, it would be very useful to the
ICE state machine when choosing the path. 

6) Please add to the DISCUSS draft that it also could reserve bandwidth in
bandwidth reservation type of networks like Cable and  Mobile networks!

We have on purpose avoided wording like reservation. It implies user
authentication and that opens up another can of worms. But reusing some of
the discuss attributes and adding functionality to do reservation in another
draft makes sense. 

The discuss draft have a very limited scope. We want to keep it simple to
implement for both applications and network elements. If it brings any real
value needs more discussion. Hopefully those discussion can happen here in
TRAM.

**[Karl]* For similar reasons I have started to say things like “the box
containing the TURN server”. We should not change the TURN server spec into
including specific QoS methods to apply (like reservation, changing DSCP
bits or applying traffic shaping mechanism). What is happening here is that
we share the traffic information that the TURN server gets hold of, with a
QoS applying function (that will be different for different networks) in
“the same box”. With “the same box” I mean that we for now don’t care about
the interface/commands for sharing information between the TURN server and
the QoS applying function. There may be a future need to specify/standardize
this, but if we start doing that now and in TRAM, we risk ending up in a
10-year process before having something in place (which without a spec
automatically will happen in vendor’s product development, by putting the
TURN server into already available “QoS applying function” boxes (like
firewalls or the mobile DPI/PCRF combination).

*What we need to consider and specify, is only what traffic info is required
(to be provided by the application/browser) for “QoS applying functions” in
different networks (including the very common reservation types) to do job
(i.e. giving us good QoE for real-time applications).*

/Karl

.-.

Pål-Erik

A few more things are needed for the ultimate goal, bringing end-to-end QoS
or QoE for real-time communication to Best Effort Internet (which does not
seem impossible, but quite doable now J ) remains though. I’ll come back to
those.

It will e.g. relate to how to do with INCOMING traffic, especially in
reservation type of networks, and the wild changing/stripping of diffserve
bits between ISPs.

 <http://www.ietf.org/mail-archive/web/rtcweb/current/msg09128.html>
http://www.ietf.org/mail-archive/web/rtcweb/current/msg09128.html

 <http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html>
http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html

/Karl

Från: Tirumaleswar Reddy (tireddy) [ <mailto:[email-masked]>
mailto:[email-masked]] 
Skickat: den 13 februari 2014 17:47
Till: Karl Stahl
Kopia:  <mailto:[email-masked]> [email-masked]
Ämne: RE: IMPORTANT CLARIFICATIONS: [tram] Milestone 3: TURN server
auto-discovery mechanism for enterprise and ISPs

Hi Karl,

I did not understand how TURN server will identify if it’s WebRTC media
streams or gaming traffic or some other data traffic relayed through it to
set the diffserv bits correctly !

-Tiru.

From: Karl Stahl [ <mailto:[email-masked]>
mailto:[email-masked]] 
Sent: Thursday, February 13, 2014 5:05 PM
To: Tirumaleswar Reddy (tireddy); 'Hutton, Andrew'; 'Justin Uberti'; Muthu
Arul Mozhi Perumal (mperumal)
Cc:  <mailto:[email-masked]> [email-masked]; 'Simon Perreault';
'Oleg Moskalenko';  <mailto:[email-masked]> [email-masked]; 'Marc Blanchet';
Dan Wing (dwing)
Subject: IMPORTANT CLARIFICATIONS: [tram] Milestone 3: TURN server
auto-discovery mechanism for enterprise and ISPs

The intended solution in the enterprise case has not yet been spelled out in
this TRAM-list discussion, so for better understanding, let me copy a few
things from the discussion in September/October on the RTCWEB-list and what
is (since long) spelled out in the
draft-ietf-rtcweb-use-cases-and-requirements.

For better understanding, I also want to point out that a TURN can have two
interfaces (acting like a router for media between different networks). This
allows to easier understand that can TURN servers can direct a best media
path (rather than just thinking that a TURN service is a device which media
just bounces against at one interface).

And, we can also hope for that a TURN server becomes a (common) component of
a firewall, which would allow the firewall to understand that the media
directed to it is RTC and should be prioritized whereby the firewall can
traffic shaped (back-off data traffic that may be filling its Internet pipe)
as well as e.g. set diffserve bits or take other measures to assist proper
quality handling thought the network. (These are common mechanisms available
and used in firewalls/NATs/access routers, but TURN servers are not yet
included such devices.) The same goes for access routers/default gateways,
DPIs in the transport network itself – TURN servers included in such points
were media can pass and quality measures applied may/will be very useful to
get us WebRTC media with through networks without quality destruction.

>From the RTCWEB mailing list September 20th (by me):

An enterprise network that want to keep a restrictive firewall not allowing
UDP traffic, could provide a real-time path using a TURN server paralleling
the firewall, instead of tunneling RTP through always open http or https
ports resulting in RTP media over TCP – with severe quality problems from
TCP retransmissions of dropped packets. The TURN server address is most
easily provided in the same way as the IP address and DNS address. (That
would also put the right party in control – The network provider (here the
enterprise) decides what is allowed on his network.)

The browser should select which available TURN server address to use in the
following priority order, where ICE could be used to try several:

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

2) TURN server address configured by the network administrator via an “admin
policy template”

 

And from yesterdays(!)
<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14>
http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14
these enterprise things and necessity are spelled out in:

A22

<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#
section-3.3.5> 3.3.5.  Simple Video Communication Service, enterprise
aspects

<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#
section-3.3.5.1> 3.3.5.1.  Description

   use-case (
<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#
section-3.3.1> Section 3.3.1).

<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#
section-3.3.5.2> 3.3.5.2.  Additional Requirements

   REQ-ID      DESCRIPTION

There are further requirement listed, helping us to understand the need for
auto discovery and a network provided TURN-server should be used to ENFORCE
that media takes that path (and thus, other paths e.g. suggested by the
remote MUST not happen to be used). This is related to the mobility aspect
(valid even without the roaming idea):

<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#
section-3.3.6> 3.3.6.  Simple Video Communication Service, access change

<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#
section-3.3.6.1> 3.3.6.1.  Description

   This use-case is almost identical to the
   Simple Video Communication Service use-case (
<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#
section-3.3.1> Section 3.3.1).  The
   difference is that the user changes network access during the
   session.

<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#
section-3.3.6.2> 3.3.6.2.  Additional Requirements

<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#
section-3.3.7> 3.3.7.  Simple Video Communication Service, QoS

<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#
section-3.3.7.1> 3.3.7.1.  Description

   This use-case is almost identical to the
   Simple Video Communication Service, access change use-case
   (
<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#
section-3.3.6> Section 3.3.6).  The use of Quality of Service (QoS)
capabilities is
   added:

<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#
section-3.3.7.2> 3.3.7.2.  Additional Requirements

There are several reasons for a network service provider to supply a TURN
server as part of his offered access:

- to keep media paths short, specifically not sending media outside its own
network to some distant application provided TURN server

Getting “WebRTC-ready” access and we look forward to telepresence for
everyone.

I hope this (a bit lengthy) summary of already thought-out and discussed
aspects/requirements will help us understand that the auto-discovered TURN
server is an ORDER from the enterprise and/or the NSP/ISP  to send the media
through this TURN path, and that other media paths that may exist MUST NOT
BE USED. (That is why we especially have to watch/advice that workable media
paths proposed by the remote party not becomes used “by accident”.

/Karl

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

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]> 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:  <mailto:[email-masked]> [email-masked]; Simon Perreault; Oleg
Moskalenko;  <mailto:[email-masked]> [email-masked]; Marc Blanchet; Dan Wing
(dwing); Karl Stahl
Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for
enterprise and ISPs

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]> mailto:[email-masked]] On
Behalf Of Justin Uberti
Sent: 12 February 2014 17:46
To: Muthu Arul Mozhi Perumal (mperumal)
Cc:  <mailto:[email-masked]> [email-masked]; Simon Perreault; Oleg
Moskalenko;  <mailto:[email-masked]> [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) <
<mailto:[email-masked]> [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: <mailto:[email-masked]>
[email-masked]] 
Sent: Wednesday, February 12, 2014 1:07 PM
To: Muthu Arul Mozhi Perumal (mperumal)
Cc: Justin Uberti; Karl Stahl;  <mailto:[email-masked]>
[email-masked]; Marc Blanchet;  <mailto:[email-masked]> [email-masked];
Dan Wing (dwing); Simon Perreault

Subject: 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) <
<mailto:[email-masked]> [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: <mailto:[email-masked]> [email-masked]] On
Behalf Of Justin Uberti
Sent: Wednesday, February 12, 2014 11:43 AM
To: Karl Stahl
Cc:  <mailto:[email-masked]> [email-masked]; Marc Blanchet;
<mailto:[email-masked]> [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 <
<mailto:[email-masked]> [email-masked]> wrote:

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

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

Also considering

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.

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”

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…) 

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

Från: Dan Wing [mailto: <mailto:[email-masked]> [email-masked]] 
Skickat: den 11 februari 2014 18:25
Till: Marc Blanchet
Kopia: Justin Uberti;  <mailto:[email-masked]> [email-masked]; Karl
Stahl;  <mailto:[email-masked]> [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 <
<mailto:[email-masked]> [email-masked]> wrote:

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

On Feb 10, 2014, at 5:30 PM, Justin Uberti < <mailto:[email-masked]>
[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)

  * enhancing privacy

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

-d

 

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

Simon,

/Karl

-----Ursprungligt meddelande-----
Från: tram [mailto: <mailto:[email-masked]> [email-masked]]
För Simon Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl Stahl;  <mailto:[email-masked]> [email-masked];
<mailto:[email-masked]> [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.)

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.)

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

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

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

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