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

<Markus.Isomaki@nokia.com> Tue, 12 March 2013 01:42 UTC

Return-Path: <Markus.Isomaki@nokia.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 C36A621F8922 for <rtcweb@ietfa.amsl.com>; Mon, 11 Mar 2013 18:42:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.521
X-Spam-Level:
X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 5S-09lf91frh for <rtcweb@ietfa.amsl.com>; Mon, 11 Mar 2013 18:42:15 -0700 (PDT)
Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 778AD21F88EF for <rtcweb@ietf.org>; Mon, 11 Mar 2013 18:42:15 -0700 (PDT)
Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r2C1g6dR030194; Tue, 12 Mar 2013 03:42:06 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Mar 2013 03:42:06 +0200
Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.232]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.02.0328.011; Tue, 12 Mar 2013 01:42:05 +0000
From: <Markus.Isomaki@nokia.com>
To: <repenno@cisco.com>, <andrew.hutton@siemens-enterprise.com>, <harald@alvestrand.no>, <rtcweb@ietf.org>
Thread-Topic: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-00.txt
Thread-Index: AQHOHoKpQPNB80XASUa1nEzDk7aFy5ihPEwA//+PMoCAAC0HYA==
Date: Tue, 12 Mar 2013 01:42:05 +0000
Message-ID: <E44893DD4E290745BB608EB23FDDB7623BBBCD@008-AM1MPN1-042.mgdnok.nokia.com>
References: <9F33F40F6F2CD847824537F3C4E37DDF06895013@MCHP04MSX.global-ad.net> <45A697A8FFD7CF48BCF2BE7E106F06040901B8ED@xmb-rcd-x04.cisco.com>
In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040901B8ED@xmb-rcd-x04.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.129.134.1]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 12 Mar 2013 01:42:06.0620 (UTC) FILETIME=[CDD685C0:01CE1EC2]
X-Nokia-AV: Clean
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:42:17 -0000

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


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