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

From: <[email-masked]>
Date: Thu, 30 Sep 2010 09:14:48 +0200

Hi Janet,

First of all, thanks very much for the detailed review (again) and sorry for the late reply. In the last couple of days I have been working on implementing all the proposed changes and comments for the next -05 revision.

I have no problem adopting your comments (some of your suggested rewrite with slightly different wording though) except the one below:

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

The notifier chooses the value of the “period” parameter. The “period” is not visible to the subscriber so I think the correct way to describe the relation between the two parameters is to say that:
The value of the “period” parameter must be greater than the value of the “average-interval” parameter.

Thanks,
Krisztian

From: ext Janet P Gunn [mailto:[email-masked]]
Sent: 2010. július 19. 12:40
To: Kiss Krisztian (Nokia-CIC/MtView)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sipcore] AD review: draft-ietf-sipcore-event-rate-control-04

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

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

[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: <[email-masked]>
Date: Thu, 30 Sep 2010 09:17:03 +0200

Hi,

Please find in-line with [KK]:

From: ext Janet P Gunn [mailto:[email-masked]]
Sent: 2010. július 26. 09:43
To: Janet P Gunn
Cc: Kiss Krisztian (Nokia-CIC/MtView); [email-masked]; [email-masked]
Subject: Re: [sipcore] AD review: draft-ietf-sipcore-event-rate-control-04

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?

[KK] As a continuation of my previous reply, the "period" is chosen by the notifier.

What is the range and granularity of the values for "period"?

[KK] I think that's an implementation decision.

Is it set separately for every subscription?

[KK]. It could be set separately per subscription (as it is also dependent on the "average-interval" and that can change per subscription) but it doesn't necessarily have to be...

Can the subscriber change it?

No, it's not visible to the subscriber.

Or does the notifier have a single value of "period" that it uses for all subscriptions, forever?

That's also an option, as long as "the value of the "period" parameter must be greater than the value of the "average-interval" parameter" is true.

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

---

From: <[email-masked]>
Date: Thu, 30 Sep 2010 09:26:52 +0200

Hi Janet,

One comment on one of your minor comments:

Janet wrote:
Section 8.2: What about “period”?

[KK] The “period” parameter does not appear as a header field parameter so no need to include it in section 8.2.

Regarding your other proposal to define the adaptive version of the maximum rate mechanism: I raised this question during my IETF78 presentation but the feedback was not to introduce any new functionality at this late stage.

Cheers,
Krisztian

From: ext Janet P Gunn [mailto:[email-masked]]
Sent: 2010. július 23. 14:40
To: Janet P Gunn
Cc: Kiss Krisztian (Nokia-CIC/MtView); [email-masked]; [email-masked]
Subject: Re: [sipcore] AD review: draft-ietf-sipcore-event-rate-control-04

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.
>
> 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 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]  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).
> [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).
>
> >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”.
>
> 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
> I will also be sending another email with some new comments/
> questions, and another one with a bunch of nits.
>
> Thanks.
>
> Janet _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore