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

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of
> Markus.Isomaki@nokia.com
> Sent: Tuesday, March 12, 2013 7:12 AM
> To: Reinaldo Penno (repenno); andrew.hutton@siemens-enterprise.com;
> harald@alvestrand.no; rtcweb@ietf.org
> Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-
> considerations-00.txt
> 
> Hi,
> 
> ICE/STUN/TURN and PCP are not really competitors or alternatives to each
> other.

Good point. http://tools.ietf.org/html/rfc6544#section-5.3 explains to gather candidates also using PCP in addition to using STUN/TURN. ICE connectivity checks
will reveal if PCP Unaware NAT exists or not. 

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

Enterprise use cases would be different. http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-09 explains some of the reasons to deploy TURN server in the campus itself. 

--Tiru.

> 
> 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
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb