Subject: [rtcweb] NAT behavior heuristics

From: "Dan Wing" <[email-masked]>
Date: Thu, 2 Aug 2012 10:45:03 -0700

In today's RTCWEB meeting I said that NAT heuristics do not work reliably,
especially if a NAT is busy (high CPU or lots of ports consumed), but there
are other situations with a NAT that cause heuristics to be inaccurate.  The
IETF document regarding this is http://tools.ietf.org/html/rfc5780, and be
sure to read its Applicability Statement in Section 1,
http://tools.ietf.org/html/rfc5780#section-1.

An explicit protocol, such Port Control Protocol (PCP, draft-ietf-pcp-base)
is the only reliable way to communicate with a NAT and reduce application
keepalive traffic.  Several of us have noticed the need to document exactly
how PCP can be reliably used to reduce UDP keepalive traffic.  We will write
down those details before the next IETF, probably in an Internet Draft.

-d

---

From: Martin Thomson <[email-masked]>
Date: Thu, 2 Aug 2012 16:02:27 -0700

I assume that this applies only to the NAT that doesn't exist yet and
that we will have to live with status quo (and the current keep-alive
recommendations) until PCP becomes bountiful.

We might want to consider other options for things like power saving
in addition to this.  One option that springs to mind is the ability
to explicitly shut down streams that aren't in use and pay the price
for warm-up.  Optimizations to candidate pair select at warm-up might
be handy in this case.

On 2 August 2012 10:45, Dan Wing <[email-masked]> wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 2 Aug 2012 16:15:43 -0700

> -----Original Message-----
> From: Martin Thomson [mailto:[email-masked]]
> Sent: Thursday, August 02, 2012 4:02 PM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [rtcweb] NAT behavior heuristics
> 

Yes.  PCP is new, somewhat like RTCWEB.

There is an incentive for the existing CGNs, deployed by almost all 
3G/LTE carriers around the world, to have their vendors add PCP 
support to those NATs, as it saves battery lifetime for their 
subscribers and reduces chatter on their network.  Incentives are 
well aligned for that to happen.

I agree that home NATs, enterprise NATs, and enterprise firewalls 
do not have those same incentives.

> for warm-up.  Optimizations to candidate pair select at warm-up might

Such as draft-westerlund-avtext-rtp-stream-pause?

-d

---

From: Martin Thomson <[email-masked]>
Date: Thu, 2 Aug 2012 16:20:52 -0700

> Such as draft-westerlund-avtext-rtp-stream-pause?

That would work at the RTP layer.  That could flow down to the UDP
flow, but resumption is non-trivial.  If you lose the NAT bindings as
a result, you would have to be prepared to restart the flow.  The
(previously) active flow might simply have to represent the highest
priority candidate pair in an ICE reboot.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 2 Aug 2012 16:46:02 -0700

> Sent: Thursday, August 02, 2012 4:21 PM
> To: Dan Wing
> Cc: [email-masked]

Thanks.

Perhaps modeling the long-duration stopped flow as a long-duration
mobility event (draft-wing-mmusic-ice-mobility) might be worthwhile;
they feel the same to me at the moment.

-d

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Fri, 3 Aug 2012 07:58:55 +0000

|We might want to consider other options for things like power saving
|in addition to this.  One option that springs to mind is the ability
|to explicitly shut down streams that aren't in use and pay the price
|for warm-up.  

I think that can be done by slightly tweaking the consent freshness test in draft-muthu-behave-consent-freshness-01. We can also combine it with the session liveness test and optimize everything. Here is the algorithm I have in mind:

The browser starts two timers after ICE concludes:
- A consent timer t1 for 15 sec (configurable in the browser)
- A liveness timer t2 for 5 sec (configurable by the JS)

When t1 expires:
If nothing except consent freshness request(s) was sent in the last x sec then 
   goto power_saving_mode.
Else // We has been sending media on the candidate pair.
   If a STUN transaction isn't already active then 
      Send a consent freshness request.
   If the transaction fails then 
      goto power_saving_mode.
   Else // The transaction succeeds
      Reset t1.
         
When t2 expires:
If nothing was received since the last liveness test then 
   If a STUN transaction isn't already active then
      Send a liveness request. 
   If the transaction fails then
      Notify the JS.
   Else // The transaction succeeds
      Reset t2.
      
power_saving_mode:
   Stop sending everything on that candidate pair. 
   Stop both timers.
   Notify the JS. 

Notes:
The JS is responsible for restarting ICE in the power_saving_mode.
Consent freshness and liveness requests are STUN binding requests.
The default value for t1 is the same as the default for ICE keepalives (section 10 of RFC5245).
The default value for x is 60 sec (configurable by the JS).

By carefully choose t1, t2 and x we can:
1. Make it work for existing NATs.
2. Interoperate with existing ICE/ICE-lite implementations.
3. Save battery.
4. Achieve good user experience.

Comments welcome.

Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Thomson
|Sent: Friday, August 03, 2012 4:32 AM
|To: Dan Wing (dwing)
|Cc: [email-masked]
|Subject: Re: [rtcweb] NAT behavior heuristics
|
|I assume that this applies only to the NAT that doesn't exist yet and
|that we will have to live with status quo (and the current keep-alive
|recommendations) until PCP becomes bountiful.
|
|We might want to consider other options for things like power saving
|in addition to this.  One option that springs to mind is the ability
|to explicitly shut down streams that aren't in use and pay the price
|for warm-up.  Optimizations to candidate pair select at warm-up might
|be handy in this case.
|
|On 2 August 2012 10:45, Dan Wing <[email-masked]> wrote:
|> In today's RTCWEB meeting I said that NAT heuristics do not work reliably,
|> especially if a NAT is busy (high CPU or lots of ports consumed), but there
|> are other situations with a NAT that cause heuristics to be inaccurate.  The
|> IETF document regarding this is http://tools.ietf.org/html/rfc5780, and be
|> sure to read its Applicability Statement in Section 1,
|> http://tools.ietf.org/html/rfc5780#section-1.
|>
|> An explicit protocol, such Port Control Protocol (PCP, draft-ietf-pcp-base)
|> is the only reliable way to communicate with a NAT and reduce application
|> keepalive traffic.  Several of us have noticed the need to document exactly
|> how PCP can be reliably used to reduce UDP keepalive traffic.  We will write
|> down those details before the next IETF, probably in an Internet Draft.
|>
|> -d
|>
|>
|> _______________________________________________
|> rtcweb mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/rtcweb
|_______________________________________________
|rtcweb mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 03 Aug 2012 08:26:38 -0700

Don't forget that if you want to shut down a flow according to RTP 
rules, you have to stop sending RTCP on it, which, again according to 
RTP rules, will declare the flow ended after a timeout.

If you want to have the flow "active but not sending", you have to go on 
sending RTCP SR's, reporting that "I still have this flow, but I 
deliberately did not send any packets on it" - which of course will keep 
the radio awake.

If the flow is regarded as ended at all layers, resumption becomes a 
non-issue; you just add a new flow when the time comes.

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Sat, 4 Aug 2012 00:04:53 +0000

|Don't forget that if you want to shut down a flow according to 
|RTP rules, you have to stop sending RTCP on it, which, again 
|according to RTP rules, will declare the flow ended after a 
|timeout.

The idea is to completely shut down the flow. The RTP rules will ensure that the peer times out and releases its resources.

Muthu 

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On Behalf Of Harald Alvestrand
|Sent: Friday, August 03, 2012 8:57 PM
|To: [email-masked]
|Subject: Re: [rtcweb] NAT behavior heuristics
|
|Don't forget that if you want to shut down a flow according to RTP
|rules, you have to stop sending RTCP on it, which, again according to
|RTP rules, will declare the flow ended after a timeout.
|
|If you want to have the flow "active but not sending", you have to go on
|sending RTCP SR's, reporting that "I still have this flow, but I
|deliberately did not send any packets on it" - which of course will keep
|the radio awake.
|
|If the flow is regarded as ended at all layers, resumption becomes a
|non-issue; you just add a new flow when the time comes.
|
|On 08/03/2012 12:58 AM, Muthu Arul Mozhi Perumal (mperumal) wrote:
|> |We might want to consider other options for things like power saving
|> |in addition to this.  One option that springs to mind is the ability
|> |to explicitly shut down streams that aren't in use and pay the price
|> |for warm-up.
|>
|> I think that can be done by slightly tweaking the consent freshness test in draft-muthu-behave-
|consent-freshness-01. We can also combine it with the session liveness test and optimize everything.
|Here is the algorithm I have in mind:
|>
|> The browser starts two timers after ICE concludes:
|> - A consent timer t1 for 15 sec (configurable in the browser)
|> - A liveness timer t2 for 5 sec (configurable by the JS)
|>
|> When t1 expires:
|> If nothing except consent freshness request(s) was sent in the last x sec then
|>     goto power_saving_mode.
|> Else // We has been sending media on the candidate pair.
|>     If a STUN transaction isn't already active then
|>        Send a consent freshness request.
|>     If the transaction fails then
|>        goto power_saving_mode.
|>     Else // The transaction succeeds
|>        Reset t1.
|>
|> When t2 expires:
|> If nothing was received since the last liveness test then
|>     If a STUN transaction isn't already active then
|>        Send a liveness request.
|>     If the transaction fails then
|>        Notify the JS.
|>     Else // The transaction succeeds
|>        Reset t2.
|>
|> power_saving_mode:
|>     Stop sending everything on that candidate pair.
|>     Stop both timers.
|>     Notify the JS.
|>
|> Notes:
|> The JS is responsible for restarting ICE in the power_saving_mode.
|> Consent freshness and liveness requests are STUN binding requests.
|> The default value for t1 is the same as the default for ICE keepalives (section 10 of RFC5245).
|> The default value for x is 60 sec (configurable by the JS).
|>
|> By carefully choose t1, t2 and x we can:
|> 1. Make it work for existing NATs.
|> 2. Interoperate with existing ICE/ICE-lite implementations.
|> 3. Save battery.
|> 4. Achieve good user experience.
|>
|> Comments welcome.
|>
|> Muthu
|>
|> |-----Original Message-----
|> |From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Thomson
|> |Sent: Friday, August 03, 2012 4:32 AM
|> |To: Dan Wing (dwing)
|> |Cc: [email-masked]
|> |Subject: Re: [rtcweb] NAT behavior heuristics
|> |
|> |I assume that this applies only to the NAT that doesn't exist yet and
|> |that we will have to live with status quo (and the current keep-alive
|> |recommendations) until PCP becomes bountiful.
|> |
|> |We might want to consider other options for things like power saving
|> |in addition to this.  One option that springs to mind is the ability
|> |to explicitly shut down streams that aren't in use and pay the price
|> |for warm-up.  Optimizations to candidate pair select at warm-up might
|> |be handy in this case.
|> |
|> |On 2 August 2012 10:45, Dan Wing <[email-masked]> wrote:
|> |> In today's RTCWEB meeting I said that NAT heuristics do not work reliably,
|> |> especially if a NAT is busy (high CPU or lots of ports consumed), but there
|> |> are other situations with a NAT that cause heuristics to be inaccurate.  The
|> |> IETF document regarding this is http://tools.ietf.org/html/rfc5780, and be
|> |> sure to read its Applicability Statement in Section 1,
|> |> http://tools.ietf.org/html/rfc5780#section-1.
|> |>
|> |> An explicit protocol, such Port Control Protocol (PCP, draft-ietf-pcp-base)
|> |> is the only reliable way to communicate with a NAT and reduce application
|> |> keepalive traffic.  Several of us have noticed the need to document exactly
|> |> how PCP can be reliably used to reduce UDP keepalive traffic.  We will write
|> |> down those details before the next IETF, probably in an Internet Draft.
|> |>
|> |> -d
|> |>
|> |>
|> |> _______________________________________________
|> |> rtcweb mailing list
|> |> [email-masked]
|> |> https://www.ietf.org/mailman/listinfo/rtcweb
|> |_______________________________________________
|> |rtcweb mailing list
|> [email-masked]
|> |https://www.ietf.org/mailman/listinfo/rtcweb
|> _______________________________________________
|> rtcweb mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/rtcweb
|
|
|_______________________________________________
|rtcweb mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Randell Jesup <[email-masked]>
Date: Sun, 05 Aug 2012 03:18:24 -0400

> do not have those same incentives.

And that's a rub, since in many/most cases, the 3G/LTE people will 
likely be talking to non-3G/LTE people, and if either side needs 
keepalives, then radio will be kept active.  Note we're talking 
long-term inactive media flows and an inactive (or rarely active) 
datachannel, such as a client using PeerConnection and DataChannels to 
keep a registration or empty conference alive, or various non-phone-like 
applications.

An alternative mechanism for keepalives might help - you can use 
short-TTL packets to prop the local router without letting the packet go 
all the way to the other end.  If the fixed-station PC uses this TTL 
trick, and the mobile unit uses PCP, the mobile unit can keep its radio off.

Short-TTL can be handy for reducing loads on servers, especially where 
the port needs to stay open with no real traffic for long periods (think 
SIP).

The local router is rarely more than 5-7 hops from a device, though 
there are pathological cases; this could be configured (and 
disableable).  There are also ways to do discovery on the local router; 
these might work better than discovery of UDP port binding time, which 
is known to not work.

-- 
Randell Jesup
[email-masked]

---

From: Cameron Byrne <[email-masked]>
Date: Sun, 5 Aug 2012 05:32:26 -0700

On Aug 5, 2012 12:20 AM, "Randell Jesup" <[email-masked]> wrote:
> And that's a rub, since in many/most cases, the 3G/LTE people will likely
be talking to non-3G/LTE people, and if either side needs keepalives, then
radio will be kept active.  Note we're talking long-term inactive media
flows and an inactive (or rarely active) datachannel, such as a client
using PeerConnection and DataChannels to keep a registration or empty
conference alive, or various non-phone-like applications.
short-TTL packets to prop the local router without letting the packet go
all the way to the other end.  If the fixed-station PC uses this TTL trick,
and the mobile unit uses PCP, the mobile unit can keep its radio off.

Fyi. I have not seen any traction for pcp anywhere in the mobile space.
Not on host and not on the CGN. I would not assume it will catch on. As a
mobile operator i have zero plans for ever supporting it. I have operated
CGN in mobile for years, most mobile operators have, and we don't see
inbound connections to mobiles via the cgn as a requirement (nat44 works
today, and applying polish to crap is not productive)

I would avoid the rtcweb layer going into too much effort to optimize
batteries of devices. The intention is good, but at some point it becomes a
layer violation and suboptimization.

Ipv6 is the solution to these issue.

CB

>
> The local router is rarely more than 5-7 hops from a device, though there
are pathological cases; this could be configured (and disableable).  There
are also ways to do discovery on the local router; these might work better
than discovery of UDP port binding time, which is known to not work.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sun, 5 Aug 2012 21:49:49 +0000

> keep a registration or empty conference alive, or various non-phone-
> like applications.

If just 3G/LTE supports PCP and non-3G/LTE does not support PCP -> Any STUN indications coming from the non-3G can be dropped by the Mobile Network itself to avoid reaching the Mobile Node, since it knows NAT binding is alive using PCP. 

--Tiru.

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Randell Jesup
> Sent: Sunday, August 05, 2012 1:18 AM
> To: [email-masked]

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sun, 5 Aug 2012 22:05:51 +0000

> Fyi. I have not seen any traction for pcp anywhere in the mobile space.

http://tools.ietf.org/html/draft-chen-pcp-mobile-deployment-01 describes usage of PCP in Mobile Deployments.

--Tiru.

On Aug 5, 2012 12:20 AM, "Randell Jesup" <[email-masked]> wrote:
> And that's a rub, since in many/most cases, the 3G/LTE people will likely be talking to non-3G/LTE people, and if either side needs keepalives, then radio will be kept active.  Note we're talking long-term inactive media flows and an inactive (or rarely active) datachannel, such as a client using PeerConnection and DataChannels to keep a registration or empty conference alive, or various non-phone-like applications.
>
> An alternative mechanism for keepalives might help - you can use short-TTL packets to prop the local router without letting the packet go all the way to the other end.  If the fixed-station PC uses this TTL trick, and the mobile unit uses PCP, the mobile unit can keep its radio off.
>
Fyi. I have not seen any traction for pcp anywhere in the mobile space.  Not on host and not on the CGN. I would not assume it will catch on. As a mobile operator i have zero plans for ever supporting it. I have operated CGN in mobile for years, most mobile operators have, and we don't see inbound connections to mobiles via the cgn as a requirement (nat44 works today, and applying polish to crap is not productive)
I would avoid the rtcweb layer going into too much effort to optimize batteries of devices. The intention is good, but at some point it becomes a layer violation and suboptimization.
Ipv6 is the solution to these issue.
CB
> Short-TTL can be handy for reducing loads on servers, especially where the port needs to stay open with no real traffic for long periods (think SIP).
>
> The local router is rarely more than 5-7 hops from a device, though there are pathological cases; this could be configured (and disableable).  There are also ways to do discovery on the local router; these might work better than discovery of UDP port binding time, which is known to not work.
>
>
> -- 
> Randell Jesup
> [email-masked]
>

---

From: Cameron Byrne <[email-masked]>
Date: Sun, 5 Aug 2012 15:22:02 -0700

> http://tools.ietf.org/html/draft-chen-pcp-mobile-deployment-01 describes usage of PCP in Mobile Deployments.

Yep, that's  an I-D.

And, it says things like "Without
   the particular considerations , PCP may not provide desirable
   outcomes.  Some default behaviours may even cause negative impacts or
   system failures in a mobile environment.  "

Got an operators with a timeline on supporting it?  How about a mobile
OS that plans to support PCP, because you will need both.  And, that
would be interesting information.

I asked around in Vancouver about PCP, and all the operators i spoke
to said no-plans, no motivation.  But, that was a small sample.

In any event, my only point is that RTCWEB should NOT be counting on
PCP.  If PCP is a tool you have, use it.  My point: it is not a tool
you have.

CB

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sun, 5 Aug 2012 22:42:17 +0000

> From: Cameron Byrne [mailto:[email-masked]]
> Sent: Sunday, August 05, 2012 4:22 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: Randell Jesup; [email-masked]; [email-masked]
> > http://tools.ietf.org/html/draft-chen-pcp-mobile-deployment-01
> describes usage of PCP in Mobile Deployments.
> >
> > --Tiru.
> >
> 
> Yep, that's  an I-D.
> 

In my conversation Nokia supports PCP and my understanding is it can be implemented as library in user space without any support from kernel.

> PCP.  If PCP is a tool you have, use it.  My point: it is not a tool

Yes, If the tool is gets deployed in future it will not just help RTCWEB and various other applications. Even with IPv6 this draft refers to Firewalls deployed by Mobile Networks and Firewalls usually timeout UDP sessions in 30 seconds.

--Tiru.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 06 Aug 2012 12:31:52 +0200

> If just 3G/LTE supports PCP and non-3G/LTE does not support PCP -> Any STUN indications coming from the non-3G can be dropped by the Mobile Network itself to avoid reaching the Mobile Node, since i…
1) the at-the-moment theory is that consent verification will use ICE 
Bind requests, not indications
2) if the mobile network drops these, the end node will assume that 
consent is withdrawn, and stop.

Agreed with those who argue that we shouldn't spend too much energy on 
optimizing for a moving target.

---

From: <[email-masked]>
Date: Tue, 7 Aug 2012 14:13:18 +0000

Hi Cameron,

Cameron Byrne wrote:
>
>I asked around in Vancouver about PCP, and all the operators i spoke to said
>no-plans, no motivation.  But, that was a small sample.

This is probably a fair assessment about the concrete plans. Most mobile operators don't even follow IETF much, so I doubt that they have even heard about PCP so far. There are however a few operators, where at least the research and standardization people have been interested in PCP (as witnessed by http://datatracker.ietf.org/doc/draft-chen-pcp-mobile-deployment/). I think some operators are also proposing PCP to be included in the 3GPP specs (release 12). It is hard to say how much that means in the real world, but at least I'd expect we could find a few operators willing to do real-network trials withing the next 12 months. 

Personally I see PCP as a very useful tool in the cellular access environment, for probing the NAT/FW timers and in the best case even setting them. It will be a major chicken-and-egg situation between apps, mobile OS's and the networks, to get anything into use. I think we should still do our best to overcome it. I agree that RTCWeb or anyone else should not rely on PCP (or any similar mechanim), but have the ability to make use of it if it happens to be available. 

I'm unconvinced IPv6 will help at all in this case. How do you know how long the FW on the path will keep its state up without keepalives? It will probably be the same as for NATs: In some networks timeout is 2 minutes, while in others 60 minutes. Having something like PCP to check out that it indeed is 60 min. would be extremely helpful. While most app developers might not be willing/able to optimize for battery/mobile, there are already some that are doing a good job. So there is hope that the new mechanisms would get some traction.

Markus

>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of ext Cameron Byrne
>Sent: 06 August, 2012 01:22
>Got an operators with a timeline on supporting it?  How about a mobile OS
>that plans to support PCP, because you will need both.  And, that would be
>interesting information.
>
>I asked around in Vancouver about PCP, and all the operators i spoke to said
>no-plans, no motivation.  But, that was a small sample.
>
>In any event, my only point is that RTCWEB should NOT be counting on PCP.  If
>PCP is a tool you have, use it.  My point: it is not a tool you have.
>
>CB

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 7 Aug 2012 08:11:02 -0700

On Aug 7, 2012 7:13 AM, <[email-masked]> wrote:
> This is probably a fair assessment about the concrete plans. Most mobile
operators don't even follow IETF much, so I doubt that they have even heard
about PCP so far. There are however a few operators, where at least the
research and standardization people have been interested in PCP (as
witnessed by
http://datatracker.ietf.org/doc/draft-chen-pcp-mobile-deployment/). I think
some operators are also proposing PCP to be included in the 3GPP specs
(release 12). It is hard to say how much that means in the real world, but
at least I'd expect we could find a few operators willing to do
real-network trials withing the next 12 months.
>
> Personally I see PCP as a very useful tool in the cellular access
environment, for probing the NAT/FW timers and in the best case even
setting them. It will be a major chicken-and-egg situation between apps,
mobile OS's and the networks, to get anything into use. I think we should
still do our best to overcome it. I agree that RTCWeb or anyone else should
not rely on PCP (or any similar mechanim), but have the ability to make use
of it if it happens to be available.
>
> I'm unconvinced IPv6 will help at all in this case. How do you know how
long the FW on the path will keep its state up without keepalives? It will
probably be the same as for NATs: In some networks timeout is 2 minutes,
while in others 60 minutes. Having something like PCP to check out that it
indeed is 60 min. would be extremely helpful. While most app developers
might not be willing/able to optimize for battery/mobile, there are already
some that are doing a good job. So there is hope that the new mechanisms
would get some traction.

I know of one large USA mobile operator that is not SPI firewalling or
tracking state for ipv6 mobiels, so this is not a problem for them.

If operators choose to statefully inspect user traffic, those cost and
limitations are assumed as part of the cost and service definition from the
mobile operator.

IMHO, SPI FW in ipv6 is not prudent or cost justified in mobile networks.

CB

> >> http://tools.ietf.org/html/draft-chen-pcp-mobile-deployment-01describes
> >usage of PCP in Mobile Deployments.
> >>
> >> --Tiru.
> >>
> >
> >Yep, that's  an I-D.
> >
PCP.  If

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 7 Aug 2012 15:37:27 +0000

> I know of one large USA mobile operator that is not SPI firewalling or tracking state for ipv6 mobiels, so this is not a problem for them.
> If operators choose to statefully inspect user traffic, those cost and limitations are assumed as part of the cost and service definition from the mobile 
> operator.

http://www.bluecoat.com/sites/default/files/documents/files/Content_Filtering_for_Mobile_Operators.pdf
offers URL filtering based on user profile, claims to block Skype if sent over port 80/443  (http://www.bluecoat.com/sites/default/files/documents/files/How_Mobile_Operators_Can_Control_Skype.1.pdf), block viruses/worm. This product is targeted for Mobile Operators. 

--Tiru.

From: Cameron Byrne [mailto:[email-masked]] 
Sent: Tuesday, August 07, 2012 8:41 PM
To: [email-masked]
Cc: [email-masked]; Tirumaleswar Reddy (tireddy); [email-masked]; [email-masked]
Subject: RE: [rtcweb] NAT behavior heuristics

> I'm unconvinced IPv6 will help at all in this case. How do you know how long the FW on the path will keep its state up without keepalives? It will probably be the same as for NATs: In some networks…
I know of one large USA mobile operator that is not SPI firewalling or tracking state for ipv6 mobiels, so this is not a problem for them.
If operators choose to statefully inspect user traffic, those cost and limitations are assumed as part of the cost and service definition from the mobile operator.
IMHO, SPI FW in ipv6 is not prudent or cost justified in mobile networks. 
CB

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 7 Aug 2012 09:08:39 -0700

> offers URL filtering based on user profile, claims to block Skype if sent over port 80/443  (http://www.bluecoat.com/sites/default/files/documents/files/How_Mobile_Operators_Can_Control_Skype.1.pdf…

Since you just sent URLs without an explanation, i am not sure the
intent of your email.

If you are suggesting that mobile operators should buy this product to
block Skype, you are probably on the wrong mailing list.

If you are suggesting mobile operators should buy this product to
block Skype and then use PCP to allow Skype, ....  Not sure that will
get much traction either.

CB

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 7 Aug 2012 16:20:02 +0000

> block Skype, you are probably on the wrong mailing list.

I am not selling this product. I am just saying that these products are offered to Mobile Operators to detect Port Misuse/for other security purposes like detecting viruses and hence the Mobile Network will have a firewall/IPS that will do DPI. My argument is IPv6 Firewall/IPS in various modes like content filtering, Application Visibility and Control when deployed in Mobile Network will have sessions just like NAT but a different purpose and will have timeout mechanism. PCP can also be used to avoid keep-alive for Firewall sessions. It's up to the Mobile Operator policy to permit the flow or not, honor the PCP request or not to permit certain flow.

--Tiru.

> Sent: Tuesday, August 07, 2012 9:39 PM
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> >> I know of one large USA mobile operator that is not SPI firewalling
> or tracking state for ipv6 mobiels, so this is not a problem for them.
> >> If operators choose to statefully inspect user traffic, those cost
> and limitations are assumed as part of the cost and service definition
> from the mobile
> >> operator.
> > offers URL filtering based on user profile, claims to block Skype if
> sent over port 80/443
> (http://www.bluecoat.com/sites/default/files/documents/files/How_Mobile
> _Operators_Can_Control_Skype.1.pdf), block viruses/worm. This product
> is targeted for Mobile Operators.
> >
> 
> >> This is probably a fair assessment about the concrete plans. Most
> mobile operators don't even follow IETF much, so I doubt that they have
> even heard about PCP so far. There are however a few operators, where
> at least the research and standardization people have been interested
> in PCP (as witnessed by http://datatracker.ietf.org/doc/draft-chen-pcp-
> mobile-deployment/). I think some operators are also proposing PCP to
> be included in the 3GPP specs (release 12). It is hard to say how much
> that means in the real world, but at least I'd expect we could find a
> few operators willing to do real-network trials withing the next 12
> months.
> >>
> setting them. It will be a major chicken-and-egg situation between
> apps, mobile OS's and the networks, to get anything into use. I think
> we should still do our best to overcome it. I agree that RTCWeb or
> anyone else should not rely on PCP (or any similar mechanim), but have
> the ability to make use of it if it happens to be available.
> >>
> >> I'm unconvinced IPv6 will help at all in this case. How do you know
> how long the FW on the path will keep its state up without keepalives?
> It will probably be the same as for NATs: In some networks timeout is 2
> minutes, while in others 60 minutes. Having something like PCP to check
> out that it indeed is 60 min. would be extremely helpful. While most
> app developers might not be willing/able to optimize for
> battery/mobile, there are already some that are doing a good job. So
> there is hope that the new mechanisms would get some traction.
> >>
> > I know of one large USA mobile operator that is not SPI firewalling
> or tracking state for ipv6 mobiels, so this is not a problem for them.
> > If operators choose to statefully inspect user traffic, those cost
> and limitations are assumed as part of the cost and service definition
> from the mobile operator.
> Behalf