Subject: Re: [Sipping] Comments on draft-niemi-sipping-event-throttle-07.txt

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

Hi Hisham,

thanks for the review.
See my answers/comment below in line

/Sal

Hisham Khartabil wrote:
> - Section 3 talks about presence, location and tracking applications. 
> I was confused reading those sections the first time thinking the 
> presence application sits on the server. Can you replace the word 
> "application" with "client"?
[Sal] thanks I'll do in the next version of the document.
> As a suggestion, I would say the whoel document needs to be updated 
> with this suggestion
>  
> - Section 3.2 talks about filters. A reference is needed to filters RFC.
[Sal] actually the right reference is to "Location Event Filters" draft. 
I'll add it.
> Also, more text is needed around how this Force extention overrides a 
> filter criteria and why would someone set a filter only to override it 
> with a Force.
[Sal] it is not that the Force override the filter criteria, but that 
the application is interested in receiving a periodic update even when 
the filter criteria does not
satisfy any of the trigger criteria. For example you are interested to 
receive an update if someone or something has moved more then 10 meters 
(and you can
set a location filter criteria for that) or if it has not moved more 
then 10 meters you still want a periodic update to check if it has been 
completely still or it has
moved but less then 10 meters. 
Of course, the periodic update can be generalized and applied to all the 
possible filter criteria.
>  
> - Figure 1 needs to be modified to show how filters are affected
[Sal] Figure 1 only describes the Throttle mechanism that does not 
affect filters.
>  
> - Section 4.3: Need to expand on how the client can reject the 
> notifier's adjusted intervals?
[Sal] the client can not reject the notifier's adjusted intervals. The 
only things it can do is to perform an update subscription with a 
different value but that
meet the constraints or subscription that does not contain the throttle 
parameter at all.
>  
> - I think its a good idea to talk about how a notifier can suggest to 
> the client the throttling mechanism and throttle interval without the 
> client asking for it. At least the draft can talk about how if a 
> notifier has a policy to limit notifications according to 
> admin throttling settings, those can/cannot be applied without the 
> client requesting them. That's something that we need to decide, 
> although it is difficult to mandate that a notifier cannot apply 
> throttles unless it is asked to do so.
[Sal] I agree that is something we need to discuss and decide how to 
proceed.
>  
> - "average" I dont understand what that is? is it the average interval 
> between notifications sent so far? How is that value decided? is 
> average the wrong word to use here. More explanation is needed.

[Sal] The average rate control is a statistical calculation which varies 
slowly over time, it  allows the notifier to dynamically increase or 
decrease the Notification frequency.
>  
> Regards,
> Hisham
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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: Salvatore Loreto <[email-masked]>
Date: Tue, 17 Feb 2009 14:59:31 +0200

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

---

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

Hi Hisham,

Thanks for the review! Regarding your comment:
> notifier has a policy to limit notifications according to admin
> throttling settings, those can/cannot be applied without the client
> requesting them. That's something that we need to decide, although it
> is difficult to mandate that a notifier cannot apply throttles unless
> it is asked to do so.
[Sal] I agree that is something we need to discuss and decide how to proceed.

I agree that the notifier can apply "hidden" throttling according to local policy. It could do it without even informing the subscriber. Now that we have a negotiation mechanism in place, we could perhaps use the Subscription-State throttle parameter to "inform" the subscriber about the existence of "hidden" throttling at the notifier (when the client does not request it). It is probably useful to let the client know what is going on at the notifier and can be done easily with this mechanism. What is your view?

Cheers,
Krisztian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Salvatore Loreto
Sent: Tuesday, February 17, 2009 4:18 AM
To: Hisham Khartabil
Cc: [email-masked]
Subject: Re: [Sipping] Comments on draft-niemi-sipping-event-throttle-07.txt

Hi Hisham,

thanks for the review.

/Sal

> filter criteria and why would someone set a filter only to override it
[Sal] it is not that the Force override the filter criteria, but that the application is interested in receiving a periodic update even when the filter criteria does not satisfy any of the trigger criteria. For example you are interested to receive an update if someone or something has moved more then 10 meters (and you can set a location filter criteria for that) or if it has not moved more then 10 meters you still want a periodic update to check if it has been completely still or it has moved but less then 10 meters.
Of course, the periodic update can be generalized and applied to all the possible filter criteria.
> - Figure 1 needs to be modified to show how filters are affected
[Sal] Figure 1 only describes the Throttle mechanism that does not affect filters.
> notifier's adjusted intervals?
[Sal] the client can not reject the notifier's adjusted intervals. The only things it can do is to perform an update subscription with a different value but that meet the constraints or subscription that does not contain the throttle parameter at all.
> notifier has a policy to limit notifications according to admin
> throttling settings, those can/cannot be applied without the client
> requesting them. That's something that we need to decide, although it
> is difficult to mandate that a notifier cannot apply throttles unless
> it is asked to do so.
[Sal] I agree that is something we need to discuss and decide how to proceed.
> average the wrong word to use here. More explanation is needed.

[Sal] The average rate control is a statistical calculation which varies slowly over time, it  allows the notifier to dynamically increase or decrease the Notification frequency.
> 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