Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-00.txt

Cameron Byrne <cb.list6@gmail.com> Tue, 12 March 2013 01:57 UTC

Return-Path: <cb.list6@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39CC321F86D9 for <rtcweb@ietfa.amsl.com>; Mon, 11 Mar 2013 18:57:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.605
X-Spam-Level:
X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[AWL=0.838, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SUBJECT_FUZZY_TION=0.156]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-MuQVJuAqdX for <rtcweb@ietfa.amsl.com>; Mon, 11 Mar 2013 18:57:03 -0700 (PDT)
Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by ietfa.amsl.com (Postfix) with ESMTP id 2546D21F86D5 for <rtcweb@ietf.org>; Mon, 11 Mar 2013 18:57:02 -0700 (PDT)
Received: by mail-wg0-f43.google.com with SMTP id e12so5646823wge.10 for <rtcweb@ietf.org>; Mon, 11 Mar 2013 18:57:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=9jnBUFyITSjlenQMeskfXT5HZ5rppKhS/Id7DBp6hS4=; b=JfaSHiy7i7PPzDK073hC/GaY1y034mhAI40nUbHqhy9Ts0sWzu6FnqCq+IkgvPLzfw h+M0DS5//eao8UDrVcrt2BrJytDFYxdeQMCh5m1rwNFV1M7K2DFQndclDgg35dG+kRJJ T0BbmcwxZpzoPMaTqWJ2jWc1YsjcV+86mZvfqd5veH24tCf5HLXCJDEHkmjr4sc8lA6W 2qWLVR9SBCmfEnt6yjsSwCbEYRY4HXILycjkcYU34XlPF0sV4vvc9qeRBkcCamdJBRWg CW2hEDDgnnwEjA80GemUwiZfCcsOMvL5kKARV5T0jWe54nExR4xcntl1XitjfPzA9kbL xiDg==
MIME-Version: 1.0
X-Received: by 10.194.20.40 with SMTP id k8mr23352067wje.16.1363053422275; Mon, 11 Mar 2013 18:57:02 -0700 (PDT)
Received: by 10.194.20.35 with HTTP; Mon, 11 Mar 2013 18:57:02 -0700 (PDT)
In-Reply-To: <E44893DD4E290745BB608EB23FDDB7623BBBCD@008-AM1MPN1-042.mgdnok.nokia.com>
References: <9F33F40F6F2CD847824537F3C4E37DDF06895013@MCHP04MSX.global-ad.net> <45A697A8FFD7CF48BCF2BE7E106F06040901B8ED@xmb-rcd-x04.cisco.com> <E44893DD4E290745BB608EB23FDDB7623BBBCD@008-AM1MPN1-042.mgdnok.nokia.com>
Date: Mon, 11 Mar 2013 18:57:02 -0700
Message-ID: <CAD6AjGSCQME2mqKNawqtBoFvUq_URZ8mTFK94oX=aV8QrVj2tQ@mail.gmail.com>
From: Cameron Byrne <cb.list6@gmail.com>
To: Markus.Isomaki@nokia.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-00.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Mar 2013 01:57:04 -0000

On Mon, Mar 11, 2013 at 6:42 PM,  <Markus.Isomaki@nokia.com> wrote:
> Hi,
>
> ICE/STUN/TURN and PCP are not really competitors or alternatives to each other.
>
> A browser or any other client will anyway need to implement ICE/STUN/TURN to work its way through non-PCP supporting NATs, which will be the majority for a long time even if PCP became succesfull. The benefit of the ICE/STUN/TURN approach is that every organization or individual who deploys NATs or firewalls will not need to deploy STUN and TURN servers, but they can be deployed independently e.g. by the WebRTC service provider.
>
> However, PCP, even gradually deployed, would still be useful as well. As Reinaldo is saying, it would improve robustness it produces explict NAT mappings with explicit durations. Also, it can serve as an alternative to STUN/TURN in case the browser happens to be behind a PCP-capable NAT/FW. So, PCP can be seen as an optimization and should be used when it is available. PCP can also help clients behind NAT/FW to reduce their keep-alive rate which is applicable to WebRTC as well. However, as depicted in [1], knowing when a client can entirely rely on PCP is not always so easy to detect.
>
> I hope we will see PCP deployment especially in the mobile/cellular access, but as many people have pointed out, the success rate of this type of protocols has been quite low. So it will be a nice surprise rather than something I would count on if it happens.
>
> [1] http://datatracker.ietf.org/doc/draft-reddy-pcp-optimize-keepalives/?include_text=1.
>
> Markus
>

I am hopeful e2e connectivity will be provided by IPv6 prior to PCP
reaching critical mass. This more because i am on bullish on v6 than
bearish on PCP.  That said, the more interesting use-case is v4 to v6
via TURN, but i believe that is already covered well ... another
reason ICE is a good fit.

CB
>
>>-----Original Message-----
>>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
>>Of ext Reinaldo Penno (repenno)
>>Sent: 11 March, 2013 22:14
>>To: Hutton, Andrew; Harald Alvestrand; rtcweb@ietf.org
>>Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-
>>considerations-00.txt
>>
>>
>>
>>On 3/11/13 12:58 PM, "Hutton, Andrew"
>><andrew.hutton@siemens-enterprise.com> wrote:
>>
>>>On: 11 March 2013 14:03 Reinaldo Penno (repenno) Wrote:
>>>
>>>
>>>>
>>>> I'm sure STUN and TURN servers are not universally deployed ('100%')
>>>> in ISP networks either.
>>>
>>>It is not required for an ISP to deploy a TURN server the webrtc TURN
>>>server is much more likely to be deployed by the web application
>>>provider which will instruct the browser to use it when accessing its service.
>>
>>The line between Application providers and ISPs is very blurry today.
>>Application provider can be over the top or it can be the ISP itself.
>>
>>
>>>
>>>>
>>>> But I'm not proposing dropping STUN/TURN in lieu of PCP, but using
>>>> PCP as an additional technique. Maybe you misunderstood what I was
>>>> proposing.
>>>>
>>>
>>>Understood but would need to understand what the benefits of doing so
>>>would be.
>>
>>
>>Yes, certainly.
>>
>>A protocol that allows a host to explicit control FW/NAT mappings/pinholes
>>(both for incoming and outgoing connections IPv4/IPv6), including lifetime,
>>knowing when such device restart/reboot, is more deterministic.
>>Client is always free to use STUN/TURN.
>>
>>
>>>
>>>Regards
>>>Andy
>>
>>_______________________________________________
>>rtcweb mailing list
>>rtcweb@ietf.org
>>https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb