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

[<[e-mail]>]

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:[e-mail]]
Sent: 2010. július 19. 12:40
To: Kiss Krisztian (Nokia-CIC/MtView)
Cc: [e-mail]; [e-mail]; [e-mail]
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