Re: [rtcweb] NAT behavior heuristics

["Muthu Arul Mozhi Perumal (mperumal)" <[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.

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: [e-mail] [mailto:[e-mail]] On Behalf Of Harald Alvestrand
|Sent: Friday, August 03, 2012 8:57 PM
|To: [e-mail]
|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: [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
|
|
|_______________________________________________
|rtcweb mailing list
|[e-mail]
|https://www.ietf.org/mailman/listinfo/rtcweb