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

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

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

/Karl

 

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

 

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

 

Muthu

 

From: Oleg Moskalenko [mailto:[e-mail]] 
Sent: Wednesday, February 12, 2014 1:07 PM
To: Muthu Arul Mozhi Perumal (mperumal)
Cc: Justin Uberti; Karl Stahl; [e-mail]; Marc Blanchet;
[e-mail]; 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)
<[e-mail]> 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:[e-mail]] On Behalf Of Justin Uberti
Sent: Wednesday, February 12, 2014 11:43 AM
To: Karl Stahl
Cc: [e-mail]; Marc Blanchet; [e-mail]; 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 <[e-mail]> 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. 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:[e-mail]] 
Skickat: den 11 februari 2014 18:25
Till: Marc Blanchet
Kopia: Justin Uberti; [e-mail]; Karl Stahl; [e-mail]; 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 <[e-mail]>
wrote:

 

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

 


On Feb 10, 2014, at 5:30 PM, Justin Uberti <[e-mail]> 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 <[e-mail]> wrote:

Simon,

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

/Karl

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

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

 

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


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

 

 

 


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