Hi Brian and all,
thanks for the review.
see my comment/answers in line
/Sal
Rosen, Brian wrote:
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.
[Sal] yes, it is applicable to both you are right, so I propose to
change the text as follow:
These mechanisms are applicable to any event subscription, both to a
single event subscription and to a event 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?
[Sal] not really, the two sentences describe the behaviour of the two
sides, the Notifier and the Subscriber.
The second statement in particular describe the possibility for the
Subscriber (the Tracking application)
to modify the average interval and doing so force the Notifier to
recalculate the maximum time allowed
between two subscriptions.
So I propose to change the second statement in the following way:
The tracking application can also modify the average interval during the
lifetime of the subscription by setting the event average extension to
a different value.
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
[Sal] right I'll change them in:
REQ1: The subscriber must be able to set the minimum time period (throttle)
between two notifications in a specific subscription.
REQ2: The subscriber must be able to set the maximum time period (force)
between two notifications in a specific subscription.
In REQ 5, would "any event" be better than "all events"?
[Sal] OK
REQ5: It must be possible to use of the throttle, force and average
mechanisms in subscriptions to any 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"
[Sal] OK
REQ6: It must be possible to use the throttle, force and average
mechanisms together with any other event filtering 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.
[Sal] Not really, as you pointed out the idea behind this requirement is
that the notifier should be able to increase it, if necessary.
So maybe it should be better change the word "adjusted" in "increased"
REQ7: The notifier must be allowed to use a throttling policy in
which the minimum time period between two notifications is
increased from the value given by the subscriber.
For example, due to congestion reasons, local policy at
the notifier could temporarily dictate a throttling policy
that in effect increases the subscriber-configured minimum
time period between two notifications.
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".
[Sal] I propose to change REQ8 in
REQ8: The throttle mechanism must discuss corner cases
for setting the minimum period between two notifications. At
a minimum, the throttling mechanism must include discussion
of the situation resulting from a minimum time period which
exceeds the subscription duration, and should provide
mechanisms for avoiding this situation.
You might be better to continue to use the word "modify" instead of
"adapt" in REQ9.
[Sal] yes I agree.
REQ9: A throttle, force and average must be possible to be
installed, modified, or removed in the course of an active
subscription.
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.
[Sal] thanks, I'll insert the suggested text.
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.
[Sal] we say that the buffer policies depend on the mode in which the
notifier is operating.
So it is how the notifier has been setted.
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.
[Sal] it is only for the throttle mechanism. So I propose:
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. However if a local policy
at the notifier can not meet the requested throttle values, then the
notifier can increase opportunely the received
value.
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.
[Sal] we do not say "no sense" we say little sense, that means that
there could be corner case where
they can be used together.
I propose to add the following test:
Force and Average: as both the parameters are designed to force an
update, this combination makes sense
only in some corner cases.
A subscriber SHOULD choose a "force" value higher than the "average"
value, otherwise the
notifier MUST not consider the "force" value.
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.
[Sal] that is a general discussion. The time in all the Event packages
is always calculate in *integral* seconds.
So a modification would have a general impact.
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.
[Sal] the section already has some text about it.
"The notifier is responsible for adjusting the proposed throttle value
based on its local policy or other properties.
The notifier MAY lower the throttle value, e.g., because of lowering the
subscription expiration. The notifier MAY
also choose a higher throttle value, e.g., because of static throttle
value configuration given by local policy.
The notifier MUST include the adjusted throttle value in the
Subscription-State header field's "throttle" parameter
in each of the NOTIFY requests. In addition, different event packages
MAY define additional constraints to the allowed
throttle intervals. Such constraints are out of the scope of this
specification."
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?
[Sal] exactly the formula is used to vary the absolute pacing in a way
that will meet the average requested
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.
[Sal] yes that is exactly what the timeout is. I'll use your definition!
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.
[Sal] right. I don not have any objection to remove the reference to
RFC3261
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
_______________________________________________
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
