Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-00.txt
"Reinaldo Penno (repenno)" <repenno@cisco.com> Tue, 12 March 2013 03:05 UTC
Return-Path: <repenno@cisco.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 2D26421F8563 for <rtcweb@ietfa.amsl.com>; Mon, 11 Mar 2013 20:05:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.162
X-Spam-Level:
X-Spam-Status: No, score=-10.162 tagged_above=-999 required=5 tests=[AWL=-0.320, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_HI=-8, 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 8yVQWGo4Aygj for <rtcweb@ietfa.amsl.com>; Mon, 11 Mar 2013 20:05:26 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB7321F856D for <rtcweb@ietf.org>; Mon, 11 Mar 2013 20:05:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3678; q=dns/txt; s=iport; t=1363057521; x=1364267121; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=KjS/cPdFjCnsxlPnX2yBfg6gwAywhDZdQr5HG4UzlR8=; b=Ym+KF7AWgQW4jMjr3Qm0a5eLa4v7Idm4J8JoU3izZThaZRm6r3oRNxJF V+6t3arJNfxh03QP7DwZajDfVi86UFmp+TI92szrLddhnXGHX/Pf+bKRp Rwj52TMY4YE4NXjazE+mBOvipUvlnwL+iZL2c2TcNwL98ukCe4w3wF9m8 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAOmYPlGtJV2Y/2dsb2JhbABDxGaBXxZ0gikBAQEEAQEBNzQXBgEIEQQBAQEKFAkuCxQIAQgCBAESCIgLDK9kkB+NQ4EaBiASBoJZYQOXc49XgVSBKQ2BczU
X-IronPort-AV: E=Sophos;i="4.84,827,1355097600"; d="scan'208";a="186361917"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 12 Mar 2013 03:05:21 +0000
Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2C35KvA010018 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Mar 2013 03:05:20 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Mon, 11 Mar 2013 22:05:20 -0500
From: "Reinaldo Penno (repenno)" <repenno@cisco.com>
To: "Markus.Isomaki@nokia.com" <Markus.Isomaki@nokia.com>, "andrew.hutton@siemens-enterprise.com" <andrew.hutton@siemens-enterprise.com>, "harald@alvestrand.no" <harald@alvestrand.no>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-00.txt
Thread-Index: AQHOHoKpVPM3WtZH0EiYxevcVicwOpihPEwA//+PMoCAANDogP//1DCA
Date: Tue, 12 Mar 2013 03:05:19 +0000
Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040901BCD4@xmb-rcd-x04.cisco.com>
In-Reply-To: <E44893DD4E290745BB608EB23FDDB7623BBBCD@008-AM1MPN1-042.mgdnok.nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [10.21.84.182]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <0944A1E260B55F4E8831318EF4BA7867@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 03:05:27 -0000
I think another advantage of PCP is to reduce call setup time in RTCweb. If a NAT/FW/Middlebox tells us that you have a mapping for 1 hour, during that hour you can reuse that external IP:port across calls over and over, or least reuse as your prime ICE candidate. On 3/11/13 9:42 PM, "Markus.Isomaki@nokia.com" <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/?inclu >de_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
- Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-… Reinaldo Penno (repenno)
- [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-… Hutton, Andrew
- Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-… Reinaldo Penno (repenno)
- Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-… Harald Alvestrand
- Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-… Reinaldo Penno (repenno)
- Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-… Cameron Byrne
- Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-… Hannes Tschofenig
- Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-… Reinaldo Penno (repenno)
- Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-… Simon Perreault
- Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-… Hutton, Andrew
- Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-… Reinaldo Penno (repenno)
- Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-… Harald Alvestrand
- Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-… Reinaldo Penno (repenno)
- Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-… Reinaldo Penno (repenno)
- Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-… Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-… Markus.Isomaki
- Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-… Cameron Byrne
- Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-… Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-… Cameron Byrne
- Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-… Reinaldo Penno (repenno)
- Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-… Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-… Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-… Harald Alvestrand
- Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-… Roy, Radhika R CIV USARMY (US)
- Re: [rtcweb] I-D Action: draft-hutton-rtcweb-nat-… Hadriel Kaplan