Re: [rtcweb] FW: I-D Action: draft-muthu-behave-consent-freshness-03.txt

[Martin Thomson <[e-mail]>]

On 28 February 2013 09:45, Muthu Arul Mozhi Perumal (mperumal)
<[e-mail]> wrote:
> |Imagine that you are running Tr at 1 second, with a complete
> |transaction required before you do anything.  Do you run 39 in
> |parallel with hundreds of checks, or do you not create a new
> |transaction when another is outstanding?
>
> Yes, that's what I had in mind -- don't generate a new request when a response is pending. A couple more constraints that could be useful:

I would expect that to be hard for a low Tr value.  Overlapped
requests seem like a real possibility for Tr=1s.

> - Don't generate a new consent freshness check when no traffic was sent over the last x sec (could save battery).

Be careful here that you don't create a failure mode whereby you lose
NAT bindings.

> - Don't generate a new liveness check if any traffic was received since the last liveness check.

Definitely.  Mandatory even.

> |We've discussed tightening the timers once the session is live.  We've
> |also discussed tightening timers when the session is starting.  Both
> |of which I would have expected to see in the document as proposed
> |solutions.
>
> Not sure I understood. Do you mean tightening the backoff timer?

The initial timer and the number of rounds before giving up.  In fact,
I don't consider exponential back-off to be a useful feature for a
live flow.  It's there to help avoid overwhelming unknown peers with
checks.  Exponential back-off could go entirely.  Hence the suggestion
for a constant interval.  A constant interval also avoids having
transitory problems trigger unnecessarily harsh actions like ICE
restart.