Hi Dale.
thanks for the review.
see my comment
Dale Worley wrote:
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".
[Sal] any objection to change the names of the parameters. However I
have to say that the "throttle"
name is there for historical reason, and it is something well recognized.
- 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.
[Sal] section 4.2 and its subsections explain that for the Throttle
parameter. Section 4.3 explains how
it can be adjusted by the notifier, even if it is explicitly mentioned
that additional constrains to the
allowed value may be defined.
Section 5.2 and its subsections explain that for Force parameter. In
section 5.2.2 at the end of second
paragraph I'll add "This value can be adjusted by the notifier based on
its local policy or other properties."
To remove the parameter a subscriber constructs a SUBSCRIBE request that
does not includes the specific Event header field parameter.
A subscriber that wishes to remove a throttle to notifications in a
subscription constructs a SUBSCRIBE
request that does not includes a "throttle" Event header field
parameter.
I'll add a paragraph about this in Sections 4.1,5.1 and 6.1.
- 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.
[Sal] I agree that exponential-smoothing is a better formula, but it
adds some complication in the choice
of 'alfa' and 'beta' parameter. Do you have an idea on how they should
be chosen?
Dale
------------------------------------------------------------------------
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
