Subject: Re: [core] Binding attributes in draft-ietf-core-interfaces

From: Michael Koster <[email-masked]>
Date: Mon, 21 Mar 2016 11:26:55 -0700

Hi,

I propose adding three new optional notification attributes, two of which which define a notification band, and adding the following clarifying notes:

nbll - the lower limit value of the notification band. 
nbul - the upper limit value of the notification band
init - the value to initialize the reporting state machine, i.e. the initial value of the filter before the first sample is evaluated

A sample is considered to be within the notification band if it is greater than or equal to nbll and less than or equal to nbul, and less than or equal to the maximum range value, and greater than or equal to the minimum range value. In other words, the notification band may wrap around the range of the value and thus be used as a high/low alarm band when nbll > nbul. In this case, the band nbul > sample value > nbll is considered the non-reporting band.

In the reporting band, Pmin and Pmax are respected, as are reporting state changes into and out of the reporting band.

Step (st) is respected within the reporting band and must center it's reporting values around the last reported sample. i.e. we can't just quantize the band.

To further clarify, the existing lt, gt, and step can be used together, and the evaluation is using a sample driven FSM. Therefore a sample transition across a limit (lt, gt) and also exceeding step, would create a single report.

Likewise, nbul, nbul, and step may also be used together, and the same FSM rule applies. I will diagram the FSM for the draft when I have time (can't commit to today...)

NB The new notification band behavior is different from the existing lt/gt band behavior and is an alternate notification filter for some different use cases. It isn't expected to have lt, gt used along with nbll, nbul in the same binding, but there may be multiple bindings on a resource with diferent behaviors as the implementation allows.

For example, assuming a 0-100 scale:

nbll=80; nbul=20; pmax=10

This would generate a report every 10 seconds when the sample value is >= 80 or <= 20, and no report when the sample value is between 20 and 80. 

nbll=1; st=1; pmin=10; pmax=600

This will cause, when the sample value is between 1 and 100, reporting of every change of 1 unit or more, no more frequently than once every 10 seconds and at least once every 600 seconds as long as the sample is between 1 and 100 inclusive. Reporting is disabled when the sample value is less than 1.

Best regards,

Michael

> On Feb 14, 2016, at 8:14 PM, Christian Groves <[email-masked]> wrote:
> 
> Hello Michael,
> 
> As part of a use case I've proposed an updates to the binding attributes which I think will handle both simple and complex cases with the same synyax.
> 
> Regards, Christian
> 
> On 14/02/2016 2:19 PM, Michael Koster wrote:
>> The intention is to produce one notification when a limit value, gt or lt, is crossed, not to continuously send notifications (at the sample rate? at pmin? ) when a value is in a particular state.
> [CNG] OK this wasn't clear. I was taking crossed to to mean notifications occurred once the value was crossed. So cs leads to multiple notifications but gt and lt only result in one notification?
>> Pmax is intended to send repeat notifications for eventual consistency. Maybe there should also be a cmax to set a notification repeat intereval when the state is in a "critical" band.
> [CNG] This could be useful.
>> 
>> Also your text below is "all value changes" ; what do you mean by all changes? do you mean all samples, or do you mean an additional change in value after a limit has been crossed?
> [CNG] I meant all samples that met the attribute/s criteria.
> e.g. pmin=x, pmax=y, gt=26 I would get a notification when 26 is crossed. Then if the sample was 26 at pmax the next notification would be 26. If the sample changed to 27 at the expiry of pmin the notification would include 27 and so on.
> The addition of cs=5 would modify the behaviour.
> 
>> 
>> Perhaps it would be good if you would explain your use case in more detail with some concrete examples of when values change and when you do and do not expect notifications. If we want to add special alarm functionality, I think we may want to define some special attributes for that case, like amin, amax, agt, alt.
> [CNG] I don't think special "alarm" functionality is needed. I think it just needs to be possible for a user to set the bindings and know what notifications will be expected.
> 
> Probably the simplest approach is to have a single attribute that indicates when a value is met or crossed (in either direction). This would allow the user to be explicit when it wants a notification. The downside is that multiple bindings would be needed, leading possibly to a large table.
> 
> An alternate approach could be to separate the value range specification from the notification rate specification. A strawman:
> 
> A binding would consist of a band, notification and timing attributes:
> 
> Band - Sets a value region that triggers a notification. When a sample is equal to or within this region notification is governed by the NotificationRate parameter. Band consists of two parameters: start and end (which are included in the notification range). Either start or end could be omitted essentially meaning through to the end or start of the number range, e.g. (,20) would mean 0 through to 20. (20,) would mean 20 and over. If both start and end are omitted then the notifications are unbounded and the initial sample value is taken as the start value.
> 
> NotificationRate - Would consist of one of the following:
> once - This would indicate that a notification is set only once on entering the band.
> cs:value - This would indicate that a notification is set on entering the band and then when the sample changes value according to band:start + (N * cs:value). If value is omitted then the samples are notified whenever sampling indicates a change (subject to pmin timing).
> 
> Timing - Two parameters:
> Pmin: Minimum time between notifications. A notification is generated only if the sample value has changed and meets a particular binding criteria (band/notificationRate).
> 
> Pmax: Maximum time between notifications. A notification is generated irrespective whether the sample value has changed or not.
> 
> If multiple bindings relate to the same value band then the pmin and pmax values used for notifications related to those values should be the smallest values.
> 
> Band, NotificationRate, Pmin and Pmax are at most once per binding.
> 
> Use case
> --------
> Monitoring temperature in some plant process. Temp degC.
> 
> The following 3 bindings are made between two resources:
> a) Notify once when process reaches 20c:
> band(20,),notificationRate(once), pmin=60, pmax=300
> b) Notify every 1c change in the range 40c to 49c:
> band(40,49),notificationRate(cs:1), pmin=60, pmax=240
> c) Notify immediately when meeting or exceeding 50c according to sample rate:
> band (50,),notificationRate(cs),pmin=1, pmax=180.
> 
> A notification is received once the process meets/exceeds 20c. Whilst the temperature exceeds 20c notifications are sent according to pmin=60 and pmax=x.
> The temperature stays between 20 and 39 for some time with notifications being generated by pmax=x.
> The temperature then jumps to 41 and a notification is generated. The notification is delayed for 30s because of the pmin=60 threshold. The temperature continues to rise and after another pmin its 45c so a notification is generated. The temperature then stablises at 45. A notification of 45c is then generated at pmax=240. 10 seconds later the temperature jumps to 60. A notification is immediately generated as pmin for that band is pmin=1. Then temperature again jumps to 70 and a notification is immediately generated subject to pmin=1.
> 
> The simplest use case would be:
> band(,),notificationRate(once), pmin=x, pmax=y
> Which indicates a notification with the current sample ise generated on setting the binding and then a notification will be generated according to pmax.
> 
> Thoughts?
> 
> 
> 
> 
>> 
>> Best regards,
>> 
>> Michael
>> 
>>> On Feb 13, 2016, at 6:57 PM, Michael Koster <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>>>>> The next sample is 26, which generates a notification due to the gt=26 attribute, The new most recent value is now 26.
>>>>>> 
>>>>>> The next sample is 30, which does not generate a notification since the last reported value was 26 and no new reporting condition is met.
>>>> [CNG] Wouldn't 30 be notified because it meets the gt=26 attribute criteria?
>>>> 
>>>>   I assumed that gt didn't result in a single notification but notification of all value changes over 26. I think it has to be clear whether the attributes are ORed or ANDed together to produce a notification.
>>>> 
>>> 
>> 
>

---

From: Christian Groves <[email-masked]>
Date: Tue, 22 Mar 2016 14:36:12 +1100

Hello Michael,

Please see my responses below.

Regards, Christian

> nbul - the upper limit value of the notification band
[CNG] I guess these are equivalent to the band parameter I proposed below?
> init - the value to initialize the reporting state machine, i.e. the initial value of the filter before the first sample is evaluated
[CNG] I didn't see init mentioned below. Can it be used with gt, lt, st 
also?
> A sample is considered to be within the notification band if it is greater than or equal to nbll and less than or equal to nbul, and less than or equal to the maximum range value, and greater than…
[CNG] From the examples below I take it that nbll and nbul may appear by 
themselves basically meaning that the band is open ended toward the 
relevant end of the supported values?
> In the reporting band, Pmin and Pmax are respected, as are reporting state changes into and out of the reporting band.
[CNG] Is the reporting of state changes out of the band due to the Pmax 
only or a property of the nbll, nbul notification? e.g. does the 
notification occur before Pmax or at Pmax?

> Step (st) is respected within the reporting band and must center it's reporting values around the last reported sample. i.e. we can't just quantize the band.
[CNG] Do you mean that to be reported the next value must exceed 
"previous value +/- step"? How would this relate to the set init value?
> Likewise, nbul, nbul, and step may also be used together, and the same FSM rule applies. I will diagram the FSM for the draft when I have time (can't commit to today...)
[CNG] Hopefully the FSM can shed some light.
> NB The new notification band behavior is different from the existing lt/gt band behavior and is an alternate notification filter for some different use cases. It isn't expected to have lt, gt used…
[CNG] "Isn't expected" should we make that a "shall not" in the draft?
> This will cause, when the sample value is between 1 and 100, reporting of every change of 1 unit or more, no more frequently than once every 10 seconds and at least once every 600 seconds as long a…
[CNG] Is that the case? In the above description you indicated that 
there would be notification into and out of the band. You would get a 
report when the value is 0.