Re: [rtcweb] NAT behavior heuristics

[Harald Alvestrand <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Martin Thomson
> |Sent: Friday, August 03, 2012 4:32 AM
> |To: Dan Wing (dwing)
> |Cc: [e-mail]
> |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 <[e-mail]> 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
> |> [e-mail]
> |> https://www.ietf.org/mailman/listinfo/rtcweb
> |_______________________________________________
> |rtcweb mailing list
> |[e-mail]
> |https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb