Subject: [Sipping] Comments on draft-niemi-sipping-event-throttle

From: Alan Johnston <[email-masked]>
Date: Fri, 13 Mar 2009 17:21:36 -0500

Here are a few comments on this draft.

Overall, I support this mechanism and think the work should progress.

While I understand the use and motivation for each of the parameters 
throttle, force, and average, I'm not thrilled with the names.  Force 
was decidedly nonintuitive to me ("Use the force, Luke"), and the three 
definitely don't go together as a cohesive set.  Something like 
rate-max, rate-min, and rate-average is much clearer.  However, if there 
is deployment and running code, then this is a good reason not to rename 
parameters.  At the very least, the abstract needs to be expanded to 
explain what these parameters do instead of just listing them.

In dealing with very large resource list-type presence subscriptions, we 
have found the need to not only limit the rate of notifications but also 
the size of the batches, i.e. the number of bodies present in a single 
NOTIFY.  This is described in 
http://tools.ietf.org/id/draft-johnston-sipping-batch-notify which uses 
a very similar mechanism.  I wonder if the authors could comment on this 
as a complementary mechanism.  I wonder if this throttling mechanism on 
its own could actually make this situation worse - i.e. fewer NOTIFYs 
are sent, but each NOTIFY is bigger.

One other comment on organization is to perhaps make a cleaner split 
between normative and non-normative text.  Most of Section 3 seems to be 
non-normative although 3.7 has normative language.  Section 4 seems like 
it would be the logical place to begin normative language, perhaps 
including a statement about this.

This next comment is just a suggestion - not a criticism.  Recently in 
my own drafts, I have been analyzing the normative language to make sure 
that it adequately covers expected behavior.  One way of doing this is 
to extract only the normative language from a draft and read just that, 
and see if the mechanism is fully specified.  I have found a number of 
examples of missing and conflicting normative language in doing this.  I 
haven't yet done this to this draft but suspect that it could use this 
analysis since it has nearly 10 pages of normative text.

One nit:  In the Abstract, it should be "force" not "forge".

Thanks,
Alan

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 16 Mar 2009 12:22:49 -0500

I agree with Alan's "support"/"work should progress", and with his 
suggestion that the parameter names might be clearer as rate-max, rate-min, 
and rate-average. I would support moving all normative text out of Section 3 
as Alan suggested, as well.

I'm also interested in Alan's question about the interaction between 
limitations on the rate of notifications and limitations on the size of 
notifications - but I hope that this question doesn't delay progressing the 
work.

Thanks,

Spencer

> throttle, force, and average, I'm not thrilled with the names.  Force was 
> decidedly nonintuitive to me ("Use the force, Luke"), and the three 
> definitely don't go together as a cohesive set.  Something like rate-max, 
> rate-min, and rate-average is much clearer.  However, if there is 
> deployment and running code, then this is a good reason not to rename 
> http://tools.ietf.org/id/draft-johnston-sipping-batch-notify which uses a 
> very similar mechanism.  I wonder if the authors could comment on this as 
> a complementary mechanism.  I wonder if this throttling mechanism on its 
> own could actually make this situation worse - i.e. fewer NOTIFYs are 
> sent, but each NOTIFY is bigger.
>
> This next comment is just a suggestion - not a criticism.  Recently in my 
> own drafts, I have been analyzing the normative language to make sure that 
> it adequately covers expected behavior.  One way of doing this is to 
> extract only the normative language from a draft and read just that, and 
> see if the mechanism is fully specified.  I have found a number of 
> _______________________________________________
> 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 Mar 2009 18:08:33 +0200

Hi Alan,

thanks for the comments, see my answers in line

regards
Sal

Alan Johnston wrote:
> was decidedly nonintuitive to me ("Use the force, Luke"), and the 
> three definitely don't go together as a cohesive set.  Something like 
> rate-max, rate-min, and rate-average is much clearer.  However, if 
> there is deployment and running code, then this is a good reason not 
> to rename parameters.
[Sal] I don't have any particular problem in changing the name, however 
I will check about deployment and running code especially about 
"throttle" that is already largely referenced and used by OMA
> At the very least, the abstract needs to be expanded to explain what 
> these parameters do instead of just listing them.
[Sal] sure, I'll do in the next version
>
> In dealing with very large resource list-type presence subscriptions, 
> we have found the need to not only limit the rate of notifications but 
> also the size of the batches, i.e. the number of bodies present in a 
> single NOTIFY.  This is described in 
> http://tools.ietf.org/id/draft-johnston-sipping-batch-notify which 
> uses a very similar mechanism.  I wonder if the authors could comment 
> on this as a complementary mechanism.  I wonder if this throttling 
> mechanism on its own could actually make this situation worse - i.e. 
> fewer NOTIFYs are sent, but each NOTIFY is bigger.
[Sal] I have read your draft, and I am going to comment it in a separate 
mail
> between normative and non-normative text.  Most of Section 3 seems to 
> be non-normative although 3.7 has normative language.  Section 4 seems 
> like it would be the logical place to begin normative language, 
> perhaps including a statement about this.
>
> my own drafts, I have been analyzing the normative language to make 
> sure that it adequately covers expected behavior.  One way of doing 
> this is to extract only the normative language from a draft and read 
> just that, and see if the mechanism is fully specified.  I have found 
> a number of examples of missing and conflicting normative language in 
> doing this.  I haven't yet done this to this draft but suspect that it 
> could use this analysis since it has nearly 10 pages of normative text.
[Sal] thanks for the suggestion