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

Harald Alvestrand <harald@alvestrand.no> Tue, 12 March 2013 13:38 UTC

Return-Path: <harald@alvestrand.no>
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 BC17F21F8B5B for <rtcweb@ietfa.amsl.com>; Tue, 12 Mar 2013 06:38:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.581
X-Spam-Level:
X-Spam-Status: No, score=-110.581 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJECT_FUZZY_TION=0.156, USER_IN_WHITELIST=-100]
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 JfGZScrLCPEa for <rtcweb@ietfa.amsl.com>; Tue, 12 Mar 2013 06:38:41 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 977A621F8A99 for <rtcweb@ietf.org>; Tue, 12 Mar 2013 06:38:40 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 52D1239E1C4; Tue, 12 Mar 2013 14:38:38 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRT8ssf31cYK; Tue, 12 Mar 2013 14:38:37 +0100 (CET)
Received: from [IPv6:2001:df8:0:16:b4fd:eac0:98eb:c482] (unknown [IPv6:2001:df8:0:16:b4fd:eac0:98eb:c482]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 1234239E1AD; Tue, 12 Mar 2013 14:38:35 +0100 (CET)
Message-ID: <513F2FD9.4000308@alvestrand.no>
Date: Tue, 12 Mar 2013 14:38:33 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: Markus.Isomaki@nokia.com
References: <9F33F40F6F2CD847824537F3C4E37DDF06895013@MCHP04MSX.global-ad.net> <45A697A8FFD7CF48BCF2BE7E106F06040901B8ED@xmb-rcd-x04.cisco.com> <E44893DD4E290745BB608EB23FDDB7623BBBCD@008-AM1MPN1-042.mgdnok.nokia.com>
In-Reply-To: <E44893DD4E290745BB608EB23FDDB7623BBBCD@008-AM1MPN1-042.mgdnok.nokia.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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 13:38:41 -0000

On 03/12/2013 02:42 AM, 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.

I absolutely agree with this summary about the usefulness and status of PCP.

My concern with RTCWEB at the moment is getting things out the door with 
all the features we really need to have, and as few additional features 
as possible.

That's why I don't want to add PCP into the mix at this time - once 
we're finished with the basic stuff, we can discuss adding support for 
new features at our leisure, but making the specs more complex than they 
currently are really should be done only when it's a really important 
feature that needs adding.

            Harald