Document:draft-niemi-sipping-event-throttle-07.txt
Reviewer: Dale Worley
Review Date: 5 February 2009
Review Deadline:
Review Type: Pre-WGLC



> The concept is interesting.  I think that the draft could be improved 
> in some ways:
> 
> - The names of the parameters are not so easy to remember.  I would 
> suggest "min", "max", and "average".
> 
> - More thought probably needs to be put into the real algorithm, which 
> accommodates possibly having all 3 parameters set, as well as various 
> subsets.
> 
> - I expect it would be useful to have more explicit language 
> specifying how the subscriber requests particular parameters, how the 
> notifier agrees or not to those values, how they get un-set, etc.  It 
> seems that a request/response negotiation is expected, and there are a 
> lot of grey areas, but I think it would help to explicate the possibilities.
> 
> - Similarly, language should be added to make it clear that the 
> notifier SHOULD do what is asked, and the subscriber needs to be 
> prepared for behavior much different from what is asked.
> 
> - In regard to averaging, it turns out that you can make a spreadsheet 
> to apply the average rule.  For example, the attached spreadsheet (if 
> it comes through), is the case:  average = 10 sec, period = 100 sec, 
> an initial event at 0 sec.  The graph panel shows the successive 
> timeout values.  You can change the average and period values and the 
> spreadsheet will update the results.
> 
> - A little fiddling suggests that setting period to 10*average gives 
> good results -- the timeout values quickly converge to the desired 
> interval.  Plugging that into the formula of section 6.2 gives
> 
> timeout = average * (count of notifications in last 10*average) / 10
> 
> - Brian Rosen suggests a moving average instead of the interval-count.
> But an easier formula to implement is an exponential-smoothing formula:
> 
> timeout =
>      (1 + alpha - beta) * (last timeout value)
>      - alpha * (interval since last notification)
>      + beta * average
> 
> That has the same general properties -- if a stimulated event causes 
> the interval since the last notification to be small, it increases 
> timeout for the next few notifications.  But it requires remembering 
> only two numbers about the past:  the last timeout and the time of the 
> last notification.
>