Re: [sipcore] AD review: draft-ietf-sipcore-event-rate-control-03

[<[e-mail]>]

Hi Janet,

Thanks for your comments, please find my answers in-line marked with [KK]:

------------------------------------------------------------------------------------------
From: [e-mail] [mailto:[e-mail]] On Behalf Of Janet P Gunn
Sent: 2010. június 11. 08:43
To: Robert Sparks
Cc: SIPCORE; [e-mail]
Subject: Re: [sipcore] AD review: draft-ietf-sipcore-event-rate-control-03


I have some further comments, mostly about the "average" mechanism. 

While “max-interval” is synonymous with “minimum rate”, and “min-interval” is synonymous with “maximum rate”, the constant switching back and forth between the two sets of terminology makes it very difficult to follow. 

Pick one set, and use that as the dominant term.  At a minimum, the section heading should be consistent. 

[KK] The dominant terms are “minimum rate” and “maximum rate”. I believe that’s consistent throughout the document including section headings. In the text we always refer to the mechanisms as “maximum rate mechanism” and “minimum rate mechanism” while we use “min-interval” and “max-interval” when defining the actual Event header field parameters.
I wish I could only use the terms “maximum rate mechanism” and “minimum rate mechanism” in the whole document including the parameter names but I am afraid of making such a non-backward compatible change at this very late phase. 
The other option could be to use only the terms “min-interval” and “max-interval” in the document but “min-interval mechanism” sounds much more confusing to me than “maximum rate mechanism”, that’s why we have this “mismatch”. I hope this does not cause a major confusion (minor one is acceptable :) and the document remains readable.
 
The description of the intended effect of the “average-interval” is unclear and inconsistent. 

In the introduction, it says 
“   average-interval:  specifies an average cadence at which notifications are desired, in seconds.” 

This implies that it will speed up the rate of notifications when they would otherwise be too slow, and slow them down when they would otherwise be too quick. 

[KK] The average rate mechanism is a "special" type of the minimum rate mechanism, which simply takes into account how many notifications have been sent recently. Obviously both the minimum rate mechanism and the average rate mechanism result in more notifications than "normal" notifications without these rate control mechanisms because the generation of notifications is not only triggered by event state changes but also timers (max-interval in minimum rate mechanism, and timeout in average rate mechanism).

Later in the intro it says 
“All those mechanisms are simply timer values that indicates (sic) the minimum, maximum and average time period allowed between two notifications. As a result of those mechanism, a compliant notifier will adjust the rate at which it generates notifications.” 

This also implies that the “average-interval” mechanism will both speed up and slow down the rate, as appropriate. 

In section 3.3, Use Case for specifying the average rate of notifications, it is contradictory.  First it says 
“dynamically increases the interval between notifications if the target has sent out several notifications recently.”  This is an INCREASE in the interval 

[KK] This is just an example use case explaining how to “decrease the processing and network load” which is stated in the first part of the sentence.

But then it says 
“The "average-interval" parameter value is used by the notifier to dynamically calculate the maximum time allowed between two subscriptions (sic).” 
First, I assume you mean “between two notifications”. Not “between two subscriptions”.  

[KK]. Right, fixed in -04 version.

But more importantly, dynamically calculating “the maximum time allowed between notifications” means that you will DECREASE the interval between notifications, if the target has not sent out any notifications recently. 

[KK] “Dynamically calculating the maximum time allowed between notifications” means decreasing or increasing the interval between two notifications (whichever is necessary) compared to the interval elapsed between the two notifications sent previously.

And further 
“This type of rate control allows the notifier to dynamically increase or decrease the Notification frequency.” 

When we get to section 6 (Operation of the average rate mechanism), it starts off by saying 
“The main consequence for the subscriber when applying the average rate mechanism is that it can receive a notification even if nothing has changed in the current state of the notifier.” 
This involves  a DECREASE in the interval. 

[KK] You mean "decrease compared to notifications without this rate control mechanism", right? I think we have a different understanding of this "increase and decrease in the interval" problem, let me try to explain. When we describe that the notifier can dynamically increase or decrease the notification frequency, we don't compare the average rate controlled notifications with "normal" notifications without rate control, instead, we compare the average rate mechanism with the minimum rate mechanism. The minimum rate mechanism does not have the functionality to increase or decrease the notification frequency, it just issues notifications at every min-interval seconds. In average rate mechanism, the notifier can increase or decrease the notification frequency based on recent number of notifications sent out in the last "period" of seconds. The sentence above simply states that a subscriber may receive unnecessary notifications (receives the same state it already has) due to the average rate mechanism (same is of course true for the minimum rate mechanism).

I found the use of the term “timeout” confusing as it implies (at least to me) “a time in which you must not send anything” rather than “a time after which you must send something”- but maybe that is just me.

[KK] “timeout” is a “time after which you must send something”. Section 6.2 states: “A compliant notifier SHOULD generate notifications whenever the time since the most recent notification exceeds the value calculated using the formula defined in Section 6.3”. It further states: “If the timeout period passes without a NOTIFY request being sent in the subscription, then the current resource state is sent (subject to any filtering associated with the subscription).” thus the notifier does not have to wait for the "timeout" to pass to send a new NOTIFY request. If the event state changes, one (or even more) NOTIFY request(s) can be sent out without waiting for "timeout". If several NOTIFY requests have been sent recently (due to event state changes) and the event state does not change further, the interval for the next NOTIFY request (due to "timeout") increases.

When we get to the formulae and the detailed mechanics, it is clear that this approach will only ever DECREASE the interval between notifications  (from what it would be without Event Rate Control), it will never INCREASE the interval between notifications  (from what it would be without Event Rate Control). 

[KK] Yes, you're right. Let me try to illustrate what we mean by "increase the interval between notifications":
timeout = (average-interval ^ 2) * count / period 
Let’s assume average-interval=30, period=60 and there have been 4 notifications during the last 60 sec, one at every 15th sec (count=4). Then, calculating the timeout value it turns out that the next timeout is 60 sec from the last notification assuming no state changes requiring a notification otherwise. Thus, the interval between notifications increased from 15 sec to 60 sec.

So you need make the document consistent.  Either remove the text that says (or implies)  the “average-interval”  mechanism will increase, as well as decrease, the interval, or modify the mechanism so it DOES “dynamically increase or decrease the Notification frequency”. (the latter would be, I think, preferred). 

Furthermore, in the description of the “average-interval” mechanism, there needs to be either a “MUST” or a “SHOULD” to ensure that “period” is GREATER THAN the “average-interval”.  Otherwise the described mechanism will send out a notification every “period” seconds, regardless of the value of “average-interval”.

[KK]. This is a valid point. I added the following text to the “period” definition in the -04 version: “The value of the "period" parameter MUST be greater than the value of the "average-interval" parameter.”
 
Thanks,
Krisztian

Janet

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. 
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. 

[e-mail] wrote on 06/10/2010 04:14:29 PM:

> [image removed] 
> 
> [sipcore] AD review: draft-ietf-sipcore-event-rate-control-03 
> 
> Robert Sparks 
> 
> to: 
> 
> SIPCORE 
> 
> 06/10/2010 04:14 PM 
> 
> Sent by: 
> 
> [e-mail] 
> 
> Summary: This draft has a few adjustments that are needed before 
> moving it into IETF Last Call.
> 
> Major question:
> 
> Why isn't this an Update to 3265? Is there text here that prevents asubscriber
> from generating Event headers in 200 OKs to NOTIFYs mid-subscription (when he
> didn't probe for support using the SUBSCRIBE?) How would they know the request
> got honored?  The possibility of running into implementations that 
> break should
> be called out.  4.2 indicates the subscriber only gets a "hint" about support
> for rate-control in the notifier - is the condition it describes really only a
> hint?
> 
> In several places, the notifier is given permission to adjust an 
> interval based
> on local policy.  The document should be explicit about allowing theadjustment
> in any direction (increasing or decreasing) since there are so many other uses
> of intervals in SIP and SIP Events that allow adjustment only in onedirection.
> A few places I noted when reading the document were the Note in REQ7, 4.3 4th
> paragraph, 5.2 paragraph 3, 6.2 paragraph 3.
> 
> The last paragraph of section 3.6 claims "exactly the same properties" except
> for being generated constrained to a schedule. Can you clarify whichproperties
> you mean? Many properties of the notifications beside their timing are clearly
> different (for instance, you may miss state transitions).
> 
> The security considerations section deserves more text: 
> * What is the forward reference from section 3.4 supposed to be pointing to?
> * Call out the implications on a Notifier having to store/aggregate 
> partial state
> * Note that the Event header (particularly in 200 OKs) is not 
> integrity protected. 
>   This would allow anything that could modify the message in flight (or an 
>   eavesdropper that could race a 200 OK in) to suppress (or flood) 
> notifications 
>   without the subscriber seeing what caused it.
> 
> The assertion that applying rate limiting and compression together results in
> savings as good as the sum of applying them independently should be supported
> or adjusted. I think it's sufficient to say they can be applied together.
> 
> Below are several suggestions for text tweaks. The first few (staring with *)
> are the most important. 
> 
> * Section 3.2 paragraph 4: suggest replacing "does not typically" 
> with "may not"
> 
> * Section 3.2 last paragraph: The sentence 'The "max-interval" parameter 
>       indicates ... complete state information' is difficult to 
> parse. Could it
>       be simplified?
> 
> * Section 4.3 first paragraph, last sentence: "For such cases" is ambiguous.
>   Suggest "If the min-interval value is greater than the subscription expiry".
> 
> * Section 6.2 last paragraph: This currently says the timeout mechanism does
>   not affect when 3261 transaction retransmissions are generated. It should
>   also explicitly note that retransmissions do not affect the calculation of
>   the next timeout.
> 
> Introduction, paragraph 2: suggest replacing "congestion" with "load"
> 
> Section 3.1  paragraph 3: suggest replacing "amount of traffic" with 
> "number of notifications"
> 
> Section 3.5 paragraph 1: Suggest a reference for RLS after "list 
> subscription".
> The sentence "Moreover, the list event notifier..." should be more explicit
> about using the rate mechanism for any back-end subscriptions it might have.
> 
> Suggest referencing 3261 in the last paragraph of 4.2
> 
> Section 4.3, 3rd paragraph last sentence. The only way the subscriber _can_
> resume notifications is to renew the subscription with a resubscribe request.
> Would this text work? "This results in receiving no further 
> notifications until
> the subscription expires or the subscriber sends a SUBSCRIBE requestrefreshing
> the subscription (perhaps resuming notifications)".
> 
> The text needs to be adjusted to reflect subnot-etags being issued as an RFC
> 
> Adam suggested some RFC-Editor notes in the proto writeup (which may address
> some of the above comments). Please be sure to incorporate those when revising
> the draft.
> 
> One last question:
> 
> If the combination of min-interval, max-interval, and average-interval make
> little sense, why does the document allow them to be combined? I 
> think what the
> group was trying to say is that we currently don't forsee a use for combining
> those options, but do not wish to forbid their combination.
> 
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore