Overall, I like this draft, and what it is trying to achieve. I would
like to see it progress further.
Abstract:
I don't find the terms 'throttle' and 'force' very intuitive. I note
that elsewhere someone has suggested 'rate-max' and 'rate-min' which I
don't agree with. It seems that you are specifying the interval rather
than the rate, so I would suggest 'min-interval' and 'max-interval' for
'throttle' and 'force' respectively.
Section 3.2:
This section seems to suggest that the 'force' threshold will only
trigger an update if a state change has occurred but has been filtered
(3rd para, "if the state is changed, even when it has not changed
enough"). I was expecting a NOTIFY to be forced even in the absence of
a change, not just when changes have been filtered.
I suggest rewording para 3 to something like:
"The application is interested in receiving the current state, even when
it is unchanged or has not changed enough to satisfy any of the trigger
criteria."
Section 3.3, 3rd paragraph:
I found the wording a little hard to follow. I suggest:
"In order to decrease the processing and network load, the tracking
application wants to make a subscription that dynamically increases the
interval between notifications if the target has sent out several
notifications recently."
Section 3.3, 4th paragraph:
s/dinamically/dynamically/
Section 3.4: REQ 7
The direction of the adjustment is unspecified.
Adjusting the minimum interval down seems undesirable, since the
subscriber may have chosen that interval to satisfy its workload
capabilities. Adjusting the minimum interval up seems reasonable but
surely that would be normal operation anyway (assuming it isn't adjusted
above the maximum interval!).
Section 3.6, 2nd paragraph:
Suggest rewording the end of the last sentence:
"the notifications with smaller intervals than the throttle recommends."
Section 3.6, last paragraph:
Suggest rewording the end of the last sentence:
"generated within the timing constraints requested."
Section 4.2, 4th paragraph:
s/frequent/frequently/
s/what//
Section 6.2:
I'm not convinced by the mechanism discussed in this section, and have
some suggestions to make it more friendly. But first, I want to ask the
question of whether we even need to specify what we mean by 'average'?
I think it might be better to say that achieving the average interval
can be done in a variety of ways, one of which is described here. If a
subscriber has specific operational requirements, it can specify them in
the throttle and force parameters. Let the notifier decide how best to
achieve the requested average interval.
Moving on to the specific calculations given, I don't like the 'count'
since this implies keeping variable amounts of history to calculate it.
I don't like 'period' since it essentially defines which timescale this
mechanism will work over. I would suggest replacing both with some form
of smoothed 'recent interval', such as an exponential moving average.
This has the advantage of not requiring additional historical
information (unlike the count), and working with recent intervals rather
than a fixed time period (unlike period). Something like:
smoothed += (last_interval - smoothed)*alpha;
I'd pick alpha = 1/8 to start with, and see how it behaved in simulations.
Having found a smoothed 'recent interval', you can calculate the next
desired timeout with something like:
timeout = average + (average - smoothed)*beta;
My first reaction is to set beta = 1/2, and see how it behaves.
Looking at this now, it doesn't seem that different to Dale's suggestion!
Either way, I would urge you not to standardise too precisely how the
notifier achieves the requested interval, instead leaving it up to the
notifier.
Section 7.2:
I think the 2nd and 3rd definitions of 'throttle-param' should probably
be 'force-param' and 'average-param' respectively.
Best regards,
Michael
_______________________________________________
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
