Subject: [Netconf] clarification for dampening in yang-push-04

From: "Sterne, Jason (Nokia - CA)" <[email-masked]>
Date: Thu, 17 Nov 2016 08:50:42 +0000

Hello yang-push dezign(tm) team,

In yang-push-04 there is some text that implies per-object dampening. It should probably be cleaned up to match the concept that dampening is not per-object.

>From section 3.3:

   "Once an update for a given object is sent, no other updates for this particular object are sent until the end of the dampening period."

Should perhaps be changed to:

   "Once an update for any object in a particular subscription is sent, no other updates for any objects in this particular subscription are sent until the end of the dampening period."

Regards,
Jason

---

From: t.petch <[email-masked]>
Date: Thu, 17 Nov 2016 12:31:11 +0000

Every time I hear of this, I wonder if we are two countries seperated by
a common language.

'dampen' to me means to make slightly wet, as in the rain currently
falling outside on my garden.

'damp' has amongst its meanings to calm down.  I note that BGP has Route
Flap Damping, it never dampens the Internet (and was produced by
Americans:-).

So does yang-push really make wet or does it calm down?

Tom Petch

----- Original Message -----
From: "Sterne, Jason (Nokia - CA)" <[email-masked]>
To: "Netconf" <[email-masked]>
Sent: Thursday, November 17, 2016 8:50 AM

In yang-push-04 there is some text that implies per-object dampening. It
should probably be cleaned up to match the concept that dampening is not
per-object.

>From section 3.3:

   "Once an update for a given object is sent, no other updates for this
particular object are sent until the end of the dampening period."

   "Once an update for any object in a particular subscription is sent,
no other updates for any objects in this particular subscription are
sent until the end of the dampening period."

Regards,
Jason

---

From: <[email-masked]>
Date: Thu, 17 Nov 2016 08:29:39 -0500

Hello Jason,

It is indeed conceivable to have a dampening that is per-subscription, not
per-object.  However, the fact that this specifies per-object dampening is
intentional.   

If you have a subscription with a significant number of objects that are in
scope, chances are than some change will occur all the time.  If any time an
object changes the dampening period gets triggered for the entire
subscription, the subscription will in effect revert to a periodic
subscription (with the period now being the dampening period) but without
the benefit of an anchor time.  Hence, per-subscription dampening would be
feasible only for subscriptions that have very few objects in scope (i.e.
"micro-subscriptions"). 

--- Alex  

From: Netconf [mailto:[email-masked]] On Behalf Of Sterne, Jason
(Nokia - CA)
Sent: Thursday, November 17, 2016 3:51 AM
To: Netconf <[email-masked]>
Subject: [Netconf] clarification for dampening in yang-push-04

   "Once an update for any object in a particular subscription is sent, no
other updates for any objects in this particular subscription are sent until
the end of the dampening period."

Regards,

Jason

---

From: Andy Bierman <[email-masked]>
Date: Thu, 17 Nov 2016 06:16:44 -0800

Hi,

On Thu, Nov 17, 2016 at 5:29 AM, <[email-masked]> wrote:

> If you have a subscription with a significant number of objects that are
> in scope, chances are than some change will occur all the time.  If any
> time an object changes the dampening period gets triggered for the entire
> “micro-subscriptions”).

This does not seem very operationally useful, not to mention quite
expensive to implement.
The server would need to keep a timer for every instance of every object in
the subscription.
 Let's say /A and /B are related somehow (e.g., YANG constraints).

damp=3

T0:  create /A

T1: push create /A

T2: modify /A and create /B

T3: push create /B

T4: push modify /A

The client will not be notified of 'modify /A' until sometime after 'create
/B' is pushed.
The client may  never get in sync with the server state.

It seems more useful for the server to wait until T4 to push both:

T0:  create /A

T1: push create /A

T2: modify /A and create /B

T3: do nothing

T4: push modify /A and create /B

Andy

>
> --- Alex
>
>
>
> *From:* Netconf [mailto:[email-masked]] *On Behalf Of *Sterne,
> Jason (Nokia - CA)
> *Sent:* Thursday, November 17, 2016 3:51 AM
> *To:* Netconf <[email-masked]>
> *Subject:* [Netconf] clarification for dampening in yang-push-04
>
>
>
>    “Once an update for a given object is sent, no other updates for this
> particular object are sent until the end of the dampening period.”
>
>
>
>    “Once an update for any object in a particular subscription is sent, no
> other updates for any objects in this particular subscription are sent
> until the end of the dampening period.”
>
>
>
> Regards,
>
> Jason
>
>
>
>
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>
>

---

From: <[email-masked]>
Date: Thu, 17 Nov 2016 09:40:29 -0500

True, this would require to keep timers per object.  

As mentioned, we could define a dampening period per subscription.  Easier to maintain, for sure.  However, if there are enough objects in scope, this basically reverts to an unanchored periodic subscription. (Perhaps with another implicit qualifier: “periodic – with changes only since last period”.)   Maybe this is what then should be introduced instead – a periodic subscription with an “include only changes since last period” flag, as opposed to a complete snapshot.  

One of the motivations behind on-change subscriptions was to allow a client to become aware of specific changes as soon as they occur, not after some additional delay.  Now, if a client is indeed interested in changes of particular objects, and wants to be notified immediately when they first change, clients will then need to maintain a separate subscription for each such object.  So, the burden of monitoring individual objects is not avoided, but simply shifted.  For this reason, I do think having a subscription that does allow to monitor changes on a per-object basis is useful.  It is a separate feature, i.e. optional to support.  

--- Alex 

From: Andy Bierman [mailto:[email-masked]] 
Sent: Thursday, November 17, 2016 9:17 AM
To: [email-masked]
Cc: Sterne, Jason (Nokia - CA) <[email-masked]>; Netconf <[email-masked]>
Subject: Re: [Netconf] clarification for dampening in yang-push-04

Hi,

On Thu, Nov 17, 2016 at 5:29 AM, <[email-masked] <mailto:[email-masked]> > wrote:

Hello Jason,

It is indeed conceivable to have a dampening that is per-subscription, not per-object.  However, the fact that this specifies per-object dampening is intentional.   

If you have a subscription with a significant number of objects that are in scope, chances are than some change will occur all the time.  If any time an object changes the dampening period gets triggered for the entire subscription, the subscription will in effect revert to a periodic subscription (with the period now being the dampening period) but without the benefit of an anchor time.  Hence, per-subscription dampening would be feasible only for subscriptions that have very few objects in scope (i.e. “micro-subscriptions”).

This does not seem very operationally useful, not to mention quite expensive to implement.

The server would need to keep a timer for every instance of every object in the subscription.

damp=3

T0:  create /A

T1: push create /A

T3: push create /B

T4: push modify /A

The client will not be notified of 'modify /A' until sometime after 'create /B' is pushed.

T0:  create /A

T1: push create /A

T3: do nothing

 

Andy

 

--- Alex  

From: Netconf [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Sterne, Jason (Nokia - CA)
Sent: Thursday, November 17, 2016 3:51 AM
To: Netconf <[email-masked] <mailto:[email-masked]> >
Subject: [Netconf] clarification for dampening in yang-push-04

>From section 3.3:

   “Once an update for a given object is sent, no other updates for this particular object are sent until the end of the dampening period.”

   “Once an update for any object in a particular subscription is sent, no other updates for any objects in this particular subscription are sent until the end of the dampening period.”

Regards,

Jason

_______________________________________________
Netconf mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/netconf

---

From: Andy Bierman <[email-masked]>
Date: Thu, 17 Nov 2016 08:53:41 -0800

On Thu, Nov 17, 2016 at 6:40 AM, <[email-masked]> wrote:

> As mentioned, we could define a dampening period per subscription.  Easier
> to maintain, for sure.  However, if there are enough objects in scope, this
> basically reverts to an unanchored periodic subscription. (Perhaps with
> another implicit qualifier: “periodic – with changes only since last
> period”.)   Maybe this is what then should be introduced instead – a
> periodic subscription with an “include only changes since last period”
> flag, as opposed to a complete snapshot.
>
>
>

A periodic push would send an update every N seconds, even if nothing
changed.
An on-change would send at most 1 update every N seconds. (not the same)

> One of the motivations behind on-change subscriptions was to allow a
> client to become aware of specific changes as soon as they occur, not after
> some additional delay.  Now, if a client is indeed interested in changes of
> particular objects, and wants to be notified immediately when they first
> change, clients will then need to maintain a separate subscription for each
> such object.  So, the burden of monitoring individual objects is not
> avoided, but simply shifted.  For this reason, I do think having a
> subscription that does allow to monitor changes on a per-object basis is
> useful.  It is a separate feature, i.e. optional to support.
>

This seems useless to me because the client is never sure it is getting an
accurate view
of all instances in the subscription.  It also means the client could get
flooded with updates.
I prefer Jason's interpretation (and text corrections)

Andy

>
>
>
>
>
>
> *From:* Andy Bierman [mailto:[email-masked]]
> *Sent:* Thursday, November 17, 2016 9:17 AM
> *To:* [email-masked]
> *Cc:* Sterne, Jason (Nokia - CA) <[email-masked]>; Netconf <
> [email-masked]>
> *Subject:* Re: [Netconf] clarification for dampening in yang-push-04
>
>
>
> Hi,
>
>
>
>
>

---

From: <[email-masked]>
Date: Thu, 17 Nov 2016 14:12:35 -0500

Hi

Inline, <ALEX>

--- Alex

From: Andy Bierman [mailto:[email-masked]] 
Sent: Thursday, November 17, 2016 11:54 AM
To: [email-masked]
Cc: Sterne, Jason (Nokia - CA) <[email-masked]>; Netconf <[email-masked]>
Subject: Re: [Netconf] clarification for dampening in yang-push-04

On Thu, Nov 17, 2016 at 6:40 AM, <[email-masked] <mailto:[email-masked]> > wrote:

 

A periodic push would send an update every N seconds, even if nothing changed.

<ALEX> Yup,  clearly they are different.  Really this points to the fact that there are two different flavors/options.  I have no issues supporting the “at most 1 update” per Jason’s text suggestion.  I do maintain there is value in the other flavor as well. The workaround is requiring clients to have many micro-subscriptions (simpler to implement, but not saving resources).   </ALEX>

 

This seems useless to me because the client is never sure it is getting an accurate view

of all instances in the subscription.  It also means the client could get flooded with updates.

<ALEX> The client should be sure as long as it does not receive OAM notifications to the contrary (and reliable connection is maintained).  I do not agree with your “useless” assertion. It is useful in cases where clients do not want to incur additional delays to be notified of changes of a particular object.  With a dampening period per subscription, even the first object change may incur a delay of up to the dampening period.  As mentioned, the workaround is that clients will need to maintain a separate subscription for each such object (or choosing really short dampening periods, which does not protect against oscillating updates). 

As mentioned I am fine with having the “at most 1 update per period” flavor.  We should leave room to also allow for an “immediate first update” option. 

</ALEX>

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 17 Nov 2016 12:15:35 -0800

Hi -

This native speaker of American English agrees that "damp" is the
correct choice, and that those advocating for "dampen" are all wet.

Randy

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 30 Nov 2016 22:48:22 +0000

Hi Tom,

We talked about damp vs dampen in our Dezign meeting today.  Dampen can means lessen (See Definition #2<https://www.google.com/search?safe=off&sa=X&q=define+dampen&forcedict=dampen>).

Based on:

*       Google search for "route damping" = 4,850 hits.

*       Google search for "route dampening" = 11,600 hits

It seems reasonable to stick with dampening.

And there was an Englishman on the call (well, actually a Scotsman.)

Eric

> -----Original Message-----

> From: Netconf [mailto:[email-masked]] On Behalf Of t.petch

> Sent: Thursday, November 17, 2016 7:31 AM

> To: Sterne, Jason (Nokia - CA) <[email-masked]>; Netconf

> <[email-masked]>

> Every time I hear of this, I wonder if we are two countries seperated by a

> common language.

> 'dampen' to me means to make slightly wet, as in the rain currently falling

> outside on my garden.

> 'damp' has amongst its meanings to calm down.  I note that BGP has Route Flap

> Damping, it never dampens the Internet (and was produced by Americans:-).

> In yang-push-04 there is some text that implies per-object dampening. It should

> probably be cleaned up to match the concept that dampening is not per-object.

>    "Once an update for any object in a particular subscription is sent, no other

> updates for any objects in this particular subscription are sent until the end of

> the dampening period."