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

["Roy, Radhika R CIV USARMY (US)" <[e-mail]>]

Classification: UNCLASSIFIED
Caveats: NONE

Folks:

I also agree with Harald on his proposal that PCP would be considered later.
In addition, I like to add the following:

1. Let PCP becomes an RFC.
2. Let there be some use cases/call-flows (as a PCP call-flow IETF draft is
there) using PCP for FW/NAT crossing by RTCWEB, SIP (audio/video)
conferencing, and related real-time applications.

Once above two items are completed, a separate draft using PCP for FW/NAT
crossing by RTCWEB applications can be written as soon as possible including
co-existing with ICE/STUN/TURN complementing each other capabilities.

Best regards,
Radhika

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Harald Alvestrand
Sent: Tuesday, March 12, 2013 9:39 AM
To: [e-mail]
Cc: [e-mail]
Subject: Re: [rtcweb] FW: I-D Action:
draft-hutton-rtcweb-nat-firewall-considerations-00.txt

On 03/12/2013 02:42 AM, [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.

I absolutely agree with this summary about the usefulness and status of PCP.

My concern with RTCWEB at the moment is getting things out the door with all
the features we really need to have, and as few additional features as
possible.

That's why I don't want to add PCP into the mix at this time - once we're
finished with the basic stuff, we can discuss adding support for new
features at our leisure, but making the specs more complex than they
currently are really should be done only when it's a really important
feature that needs adding.

            Harald

_______________________________________________
rtcweb mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rtcweb

Classification: UNCLASSIFIED
Caveats: NONE