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

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