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

From: <[email-masked]>
Date: Tue, 13 Jul 2010 02:13:41 +0200

Hi Robert,

I submitted the -04 version today addressing your comments: http://www.ietf.org/id/draft-ietf-sipcore-event-rate-control-04.txt 

Please find my answers in-line with [KK]:

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Robert Sparks
Sent: 2010. június 10. 13:14
To: SIPCORE
Subject: [sipcore] AD review: draft-ietf-sipcore-event-rate-control-03

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? 

[KK] It's an extension to 3265. Implementations of 3265 not interested in rate control don't need to implement it. If people think it's an essential part of event-notifications, we could make it as an update of 3265. Any recommendations?

Is there text here that prevents a subscriber
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.  

[KK] I added text in -04 to address this: 
Section 4.1: "If the Event header field of the SUBSCRIBE request did not include the "min-interval" parameter, the subscriber MUST NOT include an initial value of the "min-interval" Event header field parameter in a 200-class response to the NOTIFY request." 
Section 4.2: "If the Event header field of the SUBSCRIBE request did not include the "min-interval" parameter, the notifier MUST ignore an initial value of the "min-interval" Event header field parameter in a 200-class response to the NOTIFY request, if present."
...and similar text covering max-interval and average-interval mechanisms.

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?

[KK] Replaced "serves as a hint" with "indicates".

In several places, the notifier is given permission to adjust an interval based
on local policy.  The document should be explicit about allowing the adjustment
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 one direction.
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.

[KK] I spelled out the possibility of increasing and decreasing at all of these sections you referenced.

The last paragraph of section 3.6 claims "exactly the same properties" except
for being generated constrained to a schedule. Can you clarify which properties
you mean? Many properties of the notifications beside their timing are clearly
different (for instance, you may miss state transitions).

[KK] I just deleted that sentence, there was no real added value in it.

The security considerations section deserves more text: 
* What is the forward reference from section 3.4 supposed to be pointing to?

[KK] Deleted.

* Call out the implications on a Notifier having to store/aggregate partial state

[KK] I added a reference to the security considerations listed in RFC 5263 (partial notifications).

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

[KK] I added a new paragraph on this:
"RFC 3265 [RFC3265] recommends the integrity protection of the Event header field of SUBSCRIBE requests. Implementations of this extension SHOULD also provide integrity protection for the Event header field included in the 200-class response to the NOTIFY request."
	
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.

[KK] OK, so no changes needed, right?

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"

[KK] Fixed.

* Section 3.2 last paragraph: The sentence 'The "max-interval" parameter 
      indicates ... complete state information' is difficult to parse. Could it
      be simplified?

[KK] Done.

* Section 4.3 first paragraph, last sentence: "For such cases" is ambiguous.
  Suggest "If the min-interval value is greater than the subscription expiry".

[KK]. Done. Re-wrote as: "If the subscription expiry is shortened during an active subscription,..."

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

[KK]. Fixed by extending the definition of "count":  
"count: The number of notifications that have been sent during the last "period" of seconds ***not including any retransmissions of	requests***." New text is between *** marks.

Introduction, paragraph 2: suggest replacing "congestion" with "load"

[KK] Fixed.

Section 3.1  paragraph 3: suggest replacing "amount of traffic" with 
"number of notifications"

[KK] Fixed.

Section 3.5 paragraph 1: Suggest a reference for RLS after "list subscription".

[KK] Fixed.

The sentence "Moreover, the list event notifier..." should be more explicit
about using the rate mechanism for any back-end subscriptions it might have.

[KK] Fixed.

Suggest referencing 3261 in the last paragraph of 4.2

[KK] Fixed. Same applies to section 6.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 request refreshing
the subscription (perhaps resuming notifications)".

[KK] Fixed as "or the subscriber sends a SUBSCRIBE request resuming notifications."

The text needs to be adjusted to reflect subnot-etags being issued as an RFC

[KK] Fixed throughout the document.

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.

[KK] Done. Fixed the text for subnot-etags references throughout the document.

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.

[KK] Fixed as "this combination makes little sense to be used although not forbidden". Recommendations added on choosing the right values similarly to previous options for combinations.

Thanks,
Krisztian

_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: <[email-masked]>
Date: Tue, 13 Jul 2010 03:12:14 +0200

Hi Janet,

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

------------------------------------------------------------------------------------------
From: [email-masked] [mailto:[email-masked]] On Behalf Of Janet P Gunn
Sent: 2010. június 11. 08:43
To: Robert Sparks
Cc: SIPCORE; [email-masked]
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. 

[email-masked] 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: 
> 
> [email-masked] 
> 
> Why isn't this an Update to 3265? Is there text here that prevents asubscriber
> be called out.  4.2 indicates the subscriber only gets a "hint" about support
> on local policy.  The document should be explicit about allowing theadjustment
> of intervals in SIP and SIP Events that allow adjustment only in onedirection.
> for being generated constrained to a schedule. Can you clarify whichproperties
> the subscription expires or the subscriber sends a SUBSCRIBE requestrefreshing

---

From: Adam Roach <[email-masked]>
Date: Mon, 12 Jul 2010 21:27:07 -0500

[as participant and RFC3265 expert]

> [KK] It's an extension to 3265. Implementations of 3265 not interested in rate control don't need to implement it. If people think it's an essential part of event-notifications, we could make it as…

To be clear, these kinds of extensions haven't historically been 
considered "updates" to 3265 -- at least, in terms of the RFC "updates" 
terminology. Probably the closest parallel is RFC 4662 (another 
cross-package extension), which was not considered to be an update to 3265.

So I think it's appropriate to consider this an extension (which we have 
not traditionally considered an "update"), rather than a formal update.

/a

---

From: Robert Sparks <[email-masked]>
Date: Tue, 13 Jul 2010 16:23:11 -0500

I don't think it's as clear-cut as that.

4662 used the extension points 3265 expected to be used. Someone that had written a network monitor, for example, just using
3265 for reference could have produced code that made sense out of a stream of messages emitted by implementations of 4662.

That same code would probably not do the right thing with a stream of messages from this spec - at the very least, it wouldn't know
to be looking for Event headers in 200 responses - that's what makes this new, and potentially a change to the base specification.

What does 3265bis say about Event headers in responses to NOTIFYs at the moment?

RjS

On Jul 12, 2010, at 9:27 PM, Adam Roach wrote:

> To be clear, these kinds of extensions haven't historically been considered "updates" to 3265 -- at least, in terms of the RFC "updates" terminology. Probably the closest parallel is RFC 4662 (another cross-package extension), which was not considered to be an update to 3265.
> 
> So I think it's appropriate to consider this an extension (which we have not traditionally considered an "update"), rather than a formal update.
> 
> /a

---

From: Robert Sparks <[email-masked]>
Date: Tue, 13 Jul 2010 16:33:27 -0500

inline:

> [KK] It's an extension to 3265. Implementations of 3265 not interested in rate control don't need to implement it. If people think it's an essential part of event-notifications, we could make it as…

We have a separate thread going for this one.

> ...and similar text covering max-interval and average-interval mechanisms.

So, which SUBSCRIBE? I think you mean the most recent SUBSCRIBE request received on this dialog (and not just the initial SUBSCRIBE)?

> "RFC 3265 [RFC3265] recommends the integrity protection of the Event header field of SUBSCRIBE requests. Implementations of this extension SHOULD also provide integrity protection for the Event hea…

I would still call out the attacks that are possible when it isn't integrity protected.

> [KK] OK, so no changes needed, right?

No, not OK. I think you misunderstood my comment.

You should either add text justifying the claim, or change the text. I propose above to change the text
to simply say they can be applied together and not make an unsupported claim about the savings being as
good as the sum of applying them together.

---

From: Adam Roach <[email-masked]>
Date: Tue, 13 Jul 2010 17:18:49 -0500

On 7/13/10 16:23, Jul 13, Robert Sparks wrote:
> 4662 used the extension points 3265 expected to be used.

Not any more than anything else. The extension points that 3265 defines 
are new event packages. 4662 uses feature tags to negotiate usage -- a 
basic SIP extension mechanism.

Event-rate-control uses new header field parameters -- another basic SIP 
extension mechanism.

>   Someone that had written a network monitor, for example, just using
> That same code would probably not do the right thing with a stream of messages from this spec

I can't imagine why not. It will look like a stream of state information 
sent in NOTIFY messages.

I also don't have a lot of sympathy for the "network monitor" use case 
as a motivator unless we're going to explicitly deprecate TLS and S/MIME.

> - at the very least, it wouldn't know to be looking for Event headers in 200 responses

No, and it won't know to care about them either. Which is exactly the 
right thing to do reaction.

The event header fields in responses are there as a syntactic concession 
-- we needed somewhere to hang the parameters. The actual event name 
itself can't change. It can be safely ignored by network monitors, and 
they'll do the right thing.

> What does 3265bis say about Event headers in responses to NOTIFYs at the moment?

Nothing yet. I have a note to add text addressing this case (as well as 
the suppressed NOTIFY situation that arises from subnot-etags).

/a

---

From: Robert Sparks <[email-masked]>
Date: Tue, 13 Jul 2010 17:22:52 -0500

A couple more observations inline (and I'm trimming away things I'm not replying to here):

> Please find my answers in-line with [KK]:

<snip>

> ...and similar text covering max-interval and average-interval mechanisms.

These changes (and the associated changes in 5.1, 5.2, 6.1, and 6.2) are too granular and introduce the possibility of edge cases I don't think we should introduce.

It would be much simpler to say:
 
If the subscriber did not include at least one of the "min-interval, "max-interval", or "average-interval" header field parameters in the most recent SUBSCRIBE request in a given dialog, it MUST NOT include an Event header field with any of those parameters in a 200 OK to a NOTIFY in that dialog.

>      indicates ... complete state information' is difficult to parse. Could it

The new sentence you propose is even harder for me to read.

Here's some suggested text:

The "max-interval" parameter indicates to the notifier the maximum amount of time that should be allowed to elapse between NOTIFY requests containing complete state information.

RjS

---

From: <[email-masked]>
Date: Wed, 14 Jul 2010 05:50:24 +0200

Hi,

Both suggestions sound good to me. Once the I-D submission tool reopens, we can incorporate these changes in -05.

Thanks,
Krisztian

-----Original Message-----
From: ext Robert Sparks [mailto:[email-masked]] 
Sent: 2010. július 13. 15:23
To: Kiss Krisztian (Nokia-CD/MtView)
Cc: [email-masked]
Subject: Re: [sipcore] AD review: draft-ietf-sipcore-event-rate-control-03

<snip>

 

RjS

---

From: <[email-masked]>
Date: Wed, 14 Jul 2010 05:49:51 +0200

Hi,

Inline:

-----Original Message-----
From: ext Robert Sparks [mailto:[email-masked]] 
Sent: 2010. július 13. 14:33
To: Kiss Krisztian (Nokia-CD/MtView)
Cc: [email-masked]
Subject: Re: [sipcore] AD review: draft-ietf-sipcore-event-rate-control-03

inline:

[KK2] Yes, I mean the most recent SUBSCRIBE. 

[KK2] OK, will add text in -05 version.

[KK2] I see what you mean now. I will remove the "compound savings are as good as the sum of applying each one alone" part of the sentence.

Cheers,
Krisztian

---

From: Robert Sparks <[email-masked]>
Date: Mon, 19 Jul 2010 14:24:24 -0500

This reply clarified my discomfort - thanks.

Your point of syntactic concession was essential - it made sense to add parameters to the Event header in requests,
so as a matter of convenience, the draft is reusing the Event header and the new parameters  for the special case 
where you are wanting to convey information in a response. The group could well have chosen a new header with 
the same contents for inclusion in responses (I don't think folks explicitly considered this?), but this thing that looked
like the Event header was around, so it was easier to use that. This is only an issue in that  if we ever  wanted to more 
generally take advantage of the Event header in responses, whatever we did would be constrained by this document 
and the semantics for an Event header showing up in a 200 to a NOTIFY that it defines.

As it stands, this document needs to do a few things it doesn't yet:

1) Explicitly call out that the use of the Event header field  in responses other than 200 OKs to NOTIFYs is (still) undefined.
  
2) Explicitly note than any of the other parameters currently defined for the Event header do have meaning if copied from
     the NOTIFY into it's 200 OK (so that we don't have people being surprised when they return a 200 OK with an
     expires= with some shorter value and it doesn't shorten their subscription).

3) State that the event-type can't be changed between the NOTIFY and it's 200 OK (yes, that seems obvious, but..,)

4) So that someone stumbling across an Event header field in a 200 OK to a NOTIFY can look up what it means, 
     this document should update the IANA registry at <http://www.iana.org/assignments/sip-parameters> as follows:

     OLD:
        Event                o        [RFC3265]
     NEW:
        Event                o        [RFC3265][RFC-ietf-sipcore-event-rate-control]

(btw - I assume it is intended to be ok to use the short-form ("o" ) in responses?)

Personally, because of thought's like what I have in 2) above,  I feel there's a good chance we're making another 
ACK-200/ACK-non200 mistake that we could be avoiding.

RjS

On Jul 13, 2010, at 5:18 PM, Adam Roach wrote:

> Not any more than anything else. The extension points that 3265 defines are new event packages. 4662 uses feature tags to negotiate usage -- a basic SIP extension mechanism.
> 
> Event-rate-control uses new header field parameters -- another basic SIP extension mechanism.
> 
> I can't imagine why not. It will look like a stream of state information sent in NOTIFY messages.
> 
> I also don't have a lot of sympathy for the "network monitor" use case as a motivator unless we're going to explicitly deprecate TLS and S/MIME.
> 
> 
> No, and it won't know to care about them either. Which is exactly the right thing to do reaction.
> 
> The event header fields in responses are there as a syntactic concession -- we needed somewhere to hang the parameters. The actual event name itself can't change. It can be safely ignored by network monitors, and they'll do the right thing.
> 
> Nothing yet. I have a note to add text addressing this case (as well as the suppressed NOTIFY situation that arises from subnot-etags).
> 
> /a

---

From: Robert Sparks <[email-masked]>
Date: Mon, 19 Jul 2010 14:36:00 -0500

sigh - critical typo correction below:

On Jul 19, 2010, at 2:24 PM, Robert Sparks wrote:

> 2) Explicitly note than any of the other parameters currently defined for the Event header do
->NOT<-
> have meaning if copied from

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 19 Jul 2010 15:39:55 -0400

> 
> I submitted the -04 version today addressing your comments: http://
> www.ietf.org/id/draft-ietf-sipcore-event-rate-control-04.txt 

Thank you for including me in the acknowledgements.

I find that some, but not all, of my comments have been addressed.  I am 
repeating the ones which still cause confusion.

First let me say that I think this is a very useful mechanism.  My 
concerns are primarily in the way the mechanism is described.

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

[JPG] this is still an issue.  Sections 4, 5, and 6 are titled "...-rate 
behavior", but section 7 is titled ...-interval.

[JPG] If you just change the title of section 7 to 
Usage of "maximum rate", "minimum rate" and "average rate" in a 
combination
it would be MUCH clearer.

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

[JPG] The Introduction STILL SAYS this. But that is not what that 
mechanism does. 
 
[JPG] If the subscriber's desired "average" is "one notification every 5 
seconds", and the  notifier has a notification ready to send every second, 
it is going to send the notification out once a second.  Under the 
described algorithm, the notifier will NOT delay, nor buffer, 
notifications to approach the desired/specified "average"

[JPG] In fact, the mechanism described in section 6 is an ADAPTIVE variant 
of the minimum-rate (maximum-interval) mechanism.

[JPG] Personally, I would prefer to see the name of the mechanism changed 
to "adaptive-minimum-rate" instead of "average-rate".  But even if you 
don't do that, you need to change the text so that you are no longer 
misrepresenting the algorithm.

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

[JPG] This text about this use case  ALSO says "In order to decrease the 
processing and network load"

[JPG]  The text still says this.  But the mechanism and formula you 
describe in section 6 WILL NOT "increase the interval between 
notifications if the target has sent out several notifications recently." 
It only DECREASES the interval between notifications. 

[JPG] It is true that it will DECREASE the interval  LESS if there have 
been several recent notifications.  But that is quite different from 
INCREASING the interval.

[JPG] This text about this use case ALSO says "In order to decrease the 
processing and network load".  The algorithm in section 6 will NOT 
"decrease processing and network load.  It will INCREASE processing and 
network load.

[JPG] Here is my suggested rewrite of the use case for 3.3, based on the 
use case in 3.2, so it corresponds to the algorithm in section 6 (added 
text in ALL CAPS).
  "A tracking application is monitoring the movement of a target.

   In order to decrease the processing and network load, the tracking
   application has made a subscription with a set of location filters
   that specify trigger criteria, for
   example, to send an update only when the target has moved at least n
   meters.  However, the application is also interested in receiving the
   current state periodically even if the state of the target has not
   changed enough to satisfy any of the trigger criteria, e.g., has not
   moved at least n meters within the period. 
 
   HOWEVER, IF THERE HAVE BEEN FEW RECENT UPDATES, THE SUBSCRIBER 
   WOULD LIKE NOMINAL UPDATES MORE FREQUENTLY THAN WHEN THERE HAVE BEEN
   MANY RECENT UPDATES.

   In order to control the actual state, the location application sets 
   aN ADAPTIVE minimum rate (A "TIME-OUT" parameter), i.e. a maximum time
   interval between two notifications, WHICH ADAPTS, BASED ON THE RECENT 
   HISTORY OF UPDATES. 

   WHEN THERE HAVE BEEN A LOT OF RECENT UPDATES, THE
   ALGORITHM INCREASES THE "TIME-OUT" INTERVAL, SO THE COMBINATION OF 
   "REAL" (TRIGGERED BY UPDATED INFORMATION) AND "NOMINAL" (TRIGGERED BY 
   THE TIME-OUT) UPDATES CONVERGE TO THE  SPECIFIED AVERAGE RATE. 
 
   BUT WHEN THERE ARE FREQUENT "REAL" UPDATES, THE ALGORITHM DOES NOT 
   DELAY OR BUFFER THESE NOTIFICATIONS.  IN THIS CASE, THE RATE OF UPDATES 

   WILL NOT CONVERGE TO THE SPECIFIED AVERAGE RATE.

[JPG] and from the original 3.3
   This type of rate control allows the notifier to dynamically increase
   the Notification frequency. (REMOVED "or decrease")

   The tracking application can also modify the "average-interval"
   parameter during the lifetime of the subscription.

[JPG] If you make these changes to the use-case, then the use case will be 
consistent with most of the text in section 6.

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

[JPG] This comment will be resolved if you change the text in the Use 
Case.

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

[JPG] You addressed this, with the text 
      "The value of the
      "period" parameter MUST be greater than the value of the "average-
      interval" parameter."
However, since only the "average-interval" parameter is under the control 
of the subscriber, it would make more sense to put it in the 
"average-interval" definition, and say
      "The value of the "average-interval" parameter MUST be less than the 
value of the
      "period" parameter."
and take the corresponding  text out of the "period" specification.

I will also be sending another email with some new comments/questions, and 
another one with a bunch of nits.

Thanks.

And again, I really do think this is a useful mechanism, we just need to 
make the text consistent.

Janet

---

From: Adam Roach <[email-masked]>
Date: Tue, 20 Jul 2010 11:06:56 -0500

[as participant]

After thinking over Robert's arguments, I believe he is correct -- the 
change to include "Event" in NOTIFY responses does require this to be an 
update to 3265. We also need to tighten up the semantics around what it 
means when an "Event" header field appears in a response, and I think 
Robert's suggestions are both correct and complete.

/a

On 7/19/10 14:36, Jul 19, Robert Sparks wrote:
>>      this document should update the IANA registry at<http://www.iana.org/assignments/sip-parameters>  as follows:
>>
>>      OLD:
>>         Event                o        [RFC3265]
>>      NEW:

---

From: Janet P Gunn <[email-masked]>
Date: Fri, 23 Jul 2010 17:39:59 -0400

Here are my additional comments

The “average rate” mechanism you describe, is really an adaptive/dynamic 
version of the “minimum rate”  mechanism.  They both  cause notifications 
to be sent, even when there is nothing new to report.   The difference is 
HOW OFTEN these nominal notifications are sent.  With the minimum rate 
algorithm, all it looks at is “how long since the last notification was 
sent”.  The adaptive/dynamic mechanism looks at the rate of notifications 
over a specified period in determining when to send the next nominal 
notification. 

But neither the minimum rate, nor the so called average rate, mechanism 
will cause a notification to be buffered or delayed because they are 
coming too fast.

The “maximum rate” mechanism  causes new notifications to be buffered or 
delayed, based on just the time since the last notification was sent.  But 
there may be cases where the subscriber wants the delay or buffering to be 
based on the rate of notifications over a given period.

This is the use case given in 3.3, but not supported by section 6
“wants to make a subscription that dynamically increases the interval 
between notifications if the target has sent out several notifications 
recently.”

It seems to me that it would not be hard to create a new algorithm (an 
adaptive/dynamic version of the maximum rate algorithm), analogous to the 
algorithm in section 6, which “dynamically calculates the minimum time 
allowed between two notifications”, and then delays or buffers the 
notification until that time.

Sec 3-4 requirements

Req 3 needs to be modified so it reflects what the mechanism actually does
Perhaps “The subscriber must be able to  set an objective cadence, which 
adjust the maximum time between successive notifications based on a moving 
average”

Req 7 says
“The notifier must be allowed to use a policy in which the
           minimum time period between two notifications is adjusted
           from the value given by the subscriber.”
Surely this should be
“The notifier must be allowed to use a policy in which the
           minimum or maximum time period between two notifications is 
adjusted
           from the value given by the subscriber.”

Req 8 says
“mechanisms must discuss corner cases…” and “mechanisms must include 
discussion of…”
Mechanisms can’t “discuss” anything.
Suggest “mechanisms must address corner cases…” and  “mechanisms must 
address …”

“Sec 3.5   The maximum rate mechanism for Resource List Server”
If this is, indeed, restricted to the “maximum rate mechanism”, it should 
be moved to section 4. 

Sec 4.2
What does this mean?
“Such notifications reset the timer for the next
   notification, even though they do not need to abide by it.”

Sec 4.3

How can  setting a minimum interval  “insist (sic) both
   very short and very long intervals between notifications.”

It is clear that setting a minimum interval with a large value will lead 
to “very long intervals between notifications.”

But setting a minimum interval with a small  value will  not necessarily 
lead to “very short intervals between notifications.”

Section 4.4.1
Since each subscriber may have a different value for “minimum-interval”, 
does the notifier need a separate buffer for each subscriber?

Section 7
“max-interval and average-interval:  as both the parameters are
      designed as minimum rate mechanisms, this combination makes sense
      only in some corner cases.

      A subscriber SHOULD choose a "max-interval" value higher than the
      "average-interval" value, otherwise the notifier MUST NOT consider
      the "max-interval" value.”

I don’t think it is  a ”corner case” at all.  Suppose I have a  behavior 
that results in intervals where there are very frequent “real” updates 
(say once a second) alternating with intervals where there are longer 
intervals between “real” updates (say on the order of minutes). 

Suppose I want an average (dynamic minimum) rate of one update per 5 
seconds.  Depending on the length of the period, at the end of the 
“frequent update” interval, this could result in a very large value of the 
“timeout”, resulting in  a minute or more before the next 
timeout-generated  update.  I don’t want to wait THAT long.  In fact, I 
want an update at least once every 10 seconds.

So I set my “average-interval” to 5 sec, and my “maximum interval” to 10 
sec.

In the period immediately after  the end of an “active” interval, I will 
get time-out generated updates every 10 seconds (because the timeout 
generated by the “average” mechanism is greater than 10 seconds).  But 
once we are well into the “inactive” interval, the timeout  generated by 
the “average” mechanism will converge to 5 seconds.  This seems to me to 
be at least as useful as the use cases for combining max and min, or min 
and average.

Set 8.2
What about “period”?

NITS

I am not sure what you are trying to say here (sec 3.1):
“Application of the mechanism defined by RFC 5839 [RFC5839]
   can also eliminate for the presence client to receive a (full-state)
   notification carrying the latest resource state after the
   subscription refresh.”
Perhaps
“Application of the mechanism defined by RFC 5839 [RFC5839]
   can also eliminate the need for the presence client to receive a 
(full-state)
   notification, carrying the latest resource state, after the
   subscription refresh.”
Or
“Application of the mechanism defined by RFC 5839 [RFC5839]
   can also eliminate the transmission of  a (full-state)
   notification carrying the latest resource state to  the presence client 
 after the
   subscription refresh.” 

 Sec 3.2
Replace “criterias” with “criteria” (criteria is already the plural).

“i.e. has not moved at least n meters within the period.” 
Should be 
“e.g. has not moved at least n meters within the period.”

Sec 3.4
Req 4
Change 
“It must be possible to apply all together, or in any
           combination, the "min-interval", "max-interval" and "average-
           interval" mechanisms in a specific subscription.”
To 
“It must be possible to apply the "min-interval", "max-interval" and 
"average-
           interval" mechanisms  all together, or in any  combination, in 
a specific subscription.”

Req 5
Change 
“It must be possible to use of the different rate control mechanisms…”
To
“It must be possible to use any of the different rate control mechanisms…”

Req 6
Change “It must be possible to use the different rate control mechanisms…”
To
It must be possible to use any of the different rate control mechanisms…”

Sec 3.5
“We can model the notifier
   as consisting of three components: the event state resource(s), the
   Resource List Server (RLS) (or any other notifier), a notification
   buffer, and finally the subscriber, or watcher of the event state, as
   shown in Figure 1.”

That is FOUR, not three.

Section 7 (at least two places)

Change 
“to a value equivalent or higher than …”
to
“to a value equal to or higher than…”

Thanks,

Janet

[email-masked] wrote on 07/19/2010 03:39:55 PM:

> [image removed] 
> Re: [sipcore] AD review: draft-ietf-sipcore-event-rate-control-04
> Janet P Gunn 
> to: krisztian.kiss
> 07/19/2010 03:40 PM
> Sent by: [email-masked]
>
> > 
> I find that some, but not all, of my comments have been addressed. 
> I am repeating the ones which still cause confusion. 
> 
> >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. 
> 
> [JPG] this is still an issue.  Sections 4, 5, and 6 are titled "...-
> rate behavior", but section 7 is titled ...-interval. 
> 
combination 
> [JPG] If the subscriber's desired "average" is "one notification 
> every 5 seconds", and the  notifier has a notification ready to send
> every second, it is going to send the notification out once a 
> second.  Under the described algorithm, the notifier will NOT delay,
> nor buffer, notifications to approach the desired/specified "average" 
> 
> [JPG] In fact, the mechanism described in section 6 is an ADAPTIVE 
> variant of the minimum-rate (maximum-interval) mechanism. 
> 
> [JPG] Personally, I would prefer to see the name of the mechanism 
> changed to "adaptive-minimum-rate" instead of "average-rate".  But 
> even if you don't do that, you need to change the text so that you 
> are no longer misrepresenting the algorithm. 
> 
> 
> >“dynamically increases the interval between notifications if the 
> target has sent out several notifications >recently.”  This is an 
> INCREASE in the interval. 
> 
> [JPG] This text about this use case  ALSO says "In order to decrease
> the processing and network load" 
> 
> notifications if the target has sent out several notifications 
> recently."  It only DECREASES the interval between notifications. 
> 
> [JPG] It is true that it will DECREASE the interval  LESS if there 
> have been several recent notifications.  But that is quite different
> from INCREASING the interval. 
> 
> [JPG] This text about this use case ALSO says "In order to decrease 
> the processing and network load".  The algorithm in section 6 will 
> NOT "decrease processing and network load.  It will INCREASE 
> processing and network load. 
> 
> [JPG] Here is my suggested rewrite of the use case for 3.3, based on
> the use case in 3.2, so it corresponds to the algorithm in section 6
> (added text in ALL CAPS). 

> [JPG] If you make these changes to the use-case, then the use case 
> will be consistent with most of the text in section 6. 
> 
> >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). 
> 
Case. 
> 
> >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”. 
> 

>       interval" parameter." 
> However, since only the "average-interval" parameter is under the 
> control of the subscriber, it would make more sense to put it in the
>       "The value of the "average-interval" parameter MUST be less 
> than the value of the 
>       "period" parameter." 
> I will also be sending another email with some new comments/
> questions, and another one with a bunch of nits. 
> 
> Thanks. 
> 
> And again, I really do think this is a useful mechanism, we just 
> need to make the text consistent. 
> 
> Janet _______________________________________________
> sipcore mailing list
> [email-masked]

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 26 Jul 2010 12:42:49 -0400

Just want to address one technical issue that seems to have been missed..

Who/what sets the value of "period" for the adaptive/average mechanism?
What is the range and granularity of the values for "period"?
Is it set separately for every subscription?
Can the subscriber change it?
Or does the notifier have a single value of "period" that it uses for all 
subscriptions, forever?

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.