Subject: Re: [Sipping] Review of draft-niemi-sipping-event-throttle-07

From: Salvatore Loreto <[email-masked]>
Date: Tue, 17 Feb 2009 14:08:38 +0200

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 [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
>
>

---

From: <[email-masked]>
Date: Fri, 27 Feb 2009 04:20:53 +0100

Hi Brian,

Please find below some comments/questions marked with [KK] on your review comments (some of my comments were also taken into account when we updated the draft from -07 to -08)

Thanks for the review!
Krisztian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Salvatore Loreto
Sent: Tuesday, February 17, 2009 4:09 AM
To: Rosen, Brian
Cc: [email-masked]
Subject: Re: [Sipping] Review of draft-niemi-sipping-event-throttle-07

Hi Brian and all,

thanks for the review.

/Sal

Rosen, Brian wrote:
> mechanism, and the draft is getting mature; more than enough to
> warrant advancing it to (some) work group item.
>
> My comments:
>
> In section 1:
[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.
> 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.
> mechanisms (throttle, force), but then you use the name in 4.  Perhaps
> 1 is reworded:
>

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.
[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"

[KK] It think "adjusted" was correct as the notifier may lower the throttle value in case it is conflicting with the subscription expiry time. The same is also said in another comment from you (copied here):
Brian> In 4.3, perhaps you should mention that if the subscriber requests a
Brian> min greater than the subscription expiration, the notifier should
Brian> change the throttle to the expiration time left.

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.
> 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] 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.

> 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.

[KK] I am not sure what are the two policies. I think the policy is that the throttle is effective on the list subscription itself (what is the other policy?). Whether the RLS propagates the throttle to back-end subscriptions or not is up to the RLS depending on the size of its buffers, I guess.

> doesn't discuss the notion that the notifier can change the values if
> it can't meet the requested values.
>

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.

[KK] I think "adjust" is the correct word here due to the reason discussed above.

> 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.

Force and Average: as both the parameters are designed to force an update, this combination makes sense only in some corner cases.

> sufficient.  I would think at least tenths of a second, if not finer
[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.

[KK] For presence, I think integral seconds are just fine. For location, tenths of a second is probably necessary/useful. Do you have a suggestion from GEOPRIV viewpoint?

> 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.
>

"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."
> 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.
> This list is for NEW development of the application of SIP Use
> [email-masked] for questions on current sip Use
> [email-masked] 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 [email-masked] for questions on current sip Use [email-masked] for new developments of core SIP