I have reviewed this draft. I think this is a very worthwhile
mechanism, and the draft is getting mature; more than enough to warrant
advancing it to (some) work group item.
My comments:
In section 1:
These mechanisms are applicable to any event subscription, but the
throttle mechanism is mainly intended for use with an event list
subscription.
Why is this? Seems to me that throttle is as applicable to a single
event subscription as it is to a list subscription.
The average rate control allows the notifier to dynamically increase
or decrease the Notification frequency.
The tracking application can also modify the average during the
lifetime of the subscription.
Don't these two sentences say the same thing?
The wording of REQ 4 is awkward because in REQ1-2, you don't name the
mechanisms (throttle, force), but then you use the name in 4. Perhaps 1
is reworded:
The subscriber must be able to set the maximum time period (throttle)
between two notifications in a specific subscription.
and a similar change in REQ2
In REQ 5, would "any event" be better than "all events"?
In REQ 6, might you add the word "other" so that it reads "together with
any other event filtering mechanisms" and note the plural on
"mechanisms"
In REQ 7, do you really want to give the notifier the right to decrease
the minimum time? Seems like it should only be able to increase it. We
should allow the notifier to increase the maximum time; if the
subscriber asks for 10 sec max, but the notifier is only able to do 20
sec min, it has to increase it.
I am unhappy with the wording of REQ8. I don't know what "reasonable
resolution" is supposed to mean. Perhaps you want to talk about "corner
cases". I'm not even happy with that, but it's better than "reasonable
resolution".
You might be better to continue to use the word "modify" instead of
"adapt" in REQ9.
I find the introduction to 3.5 to be lacking. Perhaps something along
the lines of:
When applied to a list subscription, the event throttle mechanism has
some additional considerations. Specifically, the throttle applies
to
the aggregate notification stream resulting from the list
subscription,
rather than explicitly controlling the notification of each of the
implied constituent events.
Having said that, we may also want to observe that the list event
notifier can use the throttle mechanism on its own to control the rate
of the individual subscriptions to avoid overflowing its buffer.
Also in 3.5, you leave the notion that there are two policies without
any notion of whether it's just a choice of the notifier, or the
subscriber can influence the choice of policy. Since this is not
mentioned anywhere else I could spot, I'm guessing that the notifier
decides itself and tells no one. We at least ought to say that, and
consider whether the subscriber should be able to ask for one policy or
the other. Maybe I'm missing something.
In the 3.6 discussion, this para:
A notifier that supports the throttle, force and average mechanisms
will comply with value given in the throttle, force and average and
adjust its rate of notification accordingly.
doesn't discuss the notion that the notifier can change the values if it
can't meet the requested values.
In 3.7, I am not so sure that the last two combinations make no sense.
The average is a statistical calculation which varies slowly over time.
The max and min are instantaneous limits. It may very well be
appropriate to, for example, say "send me notifications with an average
of 1/sec, but send me at least one every 3 sec". See my discussion on
the average formula below.
In 4.2.1, I want to open a discussion of whether integral seconds is
sufficient. I would think at least tenths of a second, if not finer
grain is needed.
In 4.3, perhaps you should mention that if the subscriber requests a min
greater than the subscription expiration, the notifier should change the
throttle to the expiration time left.
In 6.2, The formula implies a fixed pacing: it gives an absolute value
for the next interval. Could we not say that the formula produces an
ideal pacing, but he notifier can vary the absolute pacing to achieve a
moving average that achieves this result over the period?
The usual formula for a the mth interval in a moving average of n
samples is
I + I + ... + I
m m-1 m-(n-1)
average= -------------------
n
Then, perhaps you want to define the term "timeout" by changing the
sentence after the formula to:
The output of the formula, "timeout", is the time to the next
notification,
expressed in seconds.
In 7.2 I don't understand the reference to RFC3261. We only want the
parameters allowed in the Subscribe and the Notify, not in any other
message.
Brian
_______________________________________________
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
