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

Oleg Moskalenko <mom040267@gmail.com> Wed, 12 February 2014 07:37 UTC

Return-Path: <mom040267@gmail.com>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5201A087A for <tram@ietfa.amsl.com>; Tue, 11 Feb 2014 23:37:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wlb3tQOyiMON for <tram@ietfa.amsl.com>; Tue, 11 Feb 2014 23:37:13 -0800 (PST)
Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0311A0875 for <tram@ietf.org>; Tue, 11 Feb 2014 23:37:13 -0800 (PST)
Received: by mail-pd0-f171.google.com with SMTP id g10so8647016pdj.30 for <tram@ietf.org>; Tue, 11 Feb 2014 23:37:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lkTTqiYBtA6YRlsbs8J/cml0v9QExtECPNyITm0quv4=; b=vqohQ7DJttzyAajquSEmo2R0cxuv/+jZF/UDDkm3cGIw4oCWePYI1Oe7/Gzy2qKBu1 YP95URyF7TWGLINrAWyRIZwON5Z0FNRW7v5IdXX/vjW0adt35EnRlNQ8LPtVN0KFFuCi qCB0dMBvbkmtBPzk9OJrRHwMVoDUHc5XaOpEepyWfyT3FrWGO5VxHAbTAdQU4TipMn3e F6wKTseRMsw96+bhQdZPNGa2tbRkPna1Bl7U5dDMiN2Pj/bdamo4Z70qPN8I+aJiYRlY DLkMi92jZWMOw2K7Uf+eYoPi/1a0lkRzcI/ueeJyFql1SPdH/l9EJrm6+DiVKBjRcDJd XDdA==
MIME-Version: 1.0
X-Received: by 10.68.89.162 with SMTP id bp2mr15646186pbb.151.1392190632139; Tue, 11 Feb 2014 23:37:12 -0800 (PST)
Received: by 10.68.147.131 with HTTP; Tue, 11 Feb 2014 23:37:12 -0800 (PST)
In-Reply-To: <E721D8C6A2E1544DB2DEBC313AF54DE2243DA8E0@xmb-rcd-x02.cisco.com>
References: <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <52F8DF21.2080303@viagenie.ca> <52f95e41.89fb420a.24a8.5a07SMTPIN_ADDED_BROKEN@mx.google.com> <CAOJ7v-27jSO3j4v5H3Dz6+pL=TxNaT8y2Gc9Q2iTPmqwpabUsA@mail.gmail.com> <41A536B1-DDCC-4D6A-9764-6842CB4187E6@cisco.com> <283E6481-73BB-48CA-8BD7-8B4903C8A450@viagenie.ca> <93531CB5-C41D-4FA2-9972-2AF195A30572@cisco.com> <52faa614.0602980a.0752.7852SMTPIN_ADDED_BROKEN@mx.google.com> <CAOJ7v-1MwEejzK_zFtEFsZZP4AYcGm=-aWPWRJvOaHpf3iH3qw@mail.gmail.com> <E721D8C6A2E1544DB2DEBC313AF54DE2243DA8E0@xmb-rcd-x02.cisco.com>
Date: Tue, 11 Feb 2014 23:37:12 -0800
Message-ID: <CALDtMrLxfn3aJDbo=yeNTzhXk1mhFYbvtaKMCFCWi0gpyoA8ew@mail.gmail.com>
From: Oleg Moskalenko <mom040267@gmail.com>
To: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
Content-Type: multipart/alternative; boundary="047d7b675e3e16a10b04f230a485"
Cc: "tireddy@icisco.com" <tireddy@icisco.com>, Simon Perreault <simon.perreault@viagenie.ca>, "tram@ietf.org" <tram@ietf.org>, Justin Uberti <juberti@google.com>, Marc Blanchet <marc.blanchet@viagenie.ca>, "Dan Wing (dwing)" <dwing@cisco.com>, Karl Stahl <karl.stahl@intertex.se>
Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Feb 2014 07:37:22 -0000

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) <
mperumal@cisco.com> 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:tram-bounces@ietf.org] *On Behalf Of *Justin Uberti
> *Sent:* Wednesday, February 12, 2014 11:43 AM
> *To:* Karl Stahl
> *Cc:* tireddy@icisco.com; Marc Blanchet; tram@ietf.org; 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 <karl.stahl@intertex.se>
> 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:dwing@cisco.com]
> *Skickat:* den 11 februari 2014 18:25
> *Till:* Marc Blanchet
> *Kopia:* Justin Uberti; tireddy@icisco.com; Karl Stahl; tram@ietf.org;
> 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 <marc.blanchet@viagenie.ca>
> wrote:
>
>
>
> Le 2014-02-11 à 00:39, Dan Wing <dwing@cisco.com> a écrit :
>
>
>
>
> On Feb 10, 2014, at 5:30 PM, Justin Uberti <juberti@google.com> 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 <karl.stahl@intertex.se
> > wrote:
>
> Simon,
>
> Good questions - see inline below --> .
> Some more thought is required!
>
> /Karl
>
> -----Ursprungligt meddelande-----
> Från: tram [mailto:tram-bounces@ietf.org] För Simon Perreault
> Skickat: den 10 februari 2014 15:16
> Till: Karl Stahl; tram@ietf.org; tireddy@icisco.com
> Ä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
> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
> STUN/TURN server               --> http://numb.viagenie.ca
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram
>
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram
>
>
>
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram
>
>
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram
>
>
>
>
>
>
>
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram
>
>