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

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

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



[e-mail] 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: [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 _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore