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

["Reinaldo Penno (repenno)" <[e-mail]>]

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, "[e-mail]" <[e-mail]>
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: [e-mail] [mailto:[e-mail]] On Behalf
>>Of ext Reinaldo Penno (repenno)
>>Sent: 11 March, 2013 22:14
>>To: Hutton, Andrew; Harald Alvestrand; [e-mail]
>>Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-
>>considerations-00.txt
>>
>>
>>
>>On 3/11/13 12:58 PM, "Hutton, Andrew"
>><[e-mail]> 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
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/rtcweb