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

[Janet P Gunn <[e-mail]>]

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