Subject: [core] CoMI - long term relationship between network elements and management station

From: Michel Veillette <[email-masked]>
Date: Thu, 15 Dec 2016 17:31:15 +0000

Hi Peter

The current CoMI draft rely on the observe mechanism [RFC 7641]  to transfer YANG notifications.
A common use of these YANG notifications is the implementation of what was called in SNMP, traps.
Traps are typically sent to a management station (e.g. NMS) to notify this station of significant events.

This mechanism typically require a long term relationship between network elements (CoMI servers)
and a management station (CoMI client). However, RFC 7641 section 4.5. Transmission, required that
this relationship is terminated at the first unsuccessful transmission.

   "or if the last attempt to retransmit a confirmable
   notification times out, then the client is considered no longer
   interested and the server MUST remove the associated entry from the
   list of observers."

How this concept of long term relationship between network elements  and a management station
should be addresed?

Should the CoMI draft redefine how the list of observers is managed by the observe mechanism?
Should CoMI clients send notifications only with non-confirmable CoAP message?
Should CoMI servers (i.e. management stations) periodically re-register as an observer (e.g. every day)?
Should we adopt a different method to transfer notifications?

Regards,

Michel Veillette
System Architecture Director
Trilliant Inc.
Tel: 450-531-3109

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 15 Dec 2016 18:52:12 +0100

> On 15 Dec 2016, at 18:31, Michel Veillette <[email-masked]> wrote:
> 

COMI is not the only CoAP user that is running into the need for long-term observation.
I think we should solve this in a more general way.
(Note that there is a proposal about “delegated observe” right now; there also was some discussion about good ways to use Observe at the Ludwigsburg T2TRG meeting.)

> Should the CoMI draft redefine how the list of observers is managed by the observe mechanism?

The COMI draft could be a place to do this, but an independent draft sounds better.

> Should CoMI clients send notifications only with non-confirmable CoAP message?

Unreliability was a big problem with SNMP traps; we probably don’t want to repeat that problem.

> Should CoMI servers (i.e. management stations) periodically re-register as an observer (e.g. every day)?

Most likely, something like this will need to be done anyway (management will want to know that the device is still there).  But we should define the details in a way that is as useful as possible to management applications.

> Should we adopt a different method to transfer notifications?

For people used to HTTP, using a POST from the server to the client always seems the obvious solution — after all, that’s all that classic HTTP can do.  HTTP is growing new functionality in this space now (e.g., RFC8030 Webpush), and we should pay attention.

Grüße, Carsten

---

From: "Turner, Randy" <[email-masked]>
Date: Thu, 15 Dec 2016 18:22:01 +0000

SNMP traps and informs do not necessarily require a long-term “relationship” - their relationship is historically statically configured and maintained statelessly - there’s no “relationship” like an active TCP session that has to be kept alive.
Maybe we should decide on the definition of “relationship”

R.

> On Dec 15, 2016, at 12:52 PM, Carsten Bormann <[email-masked]> wrote:
> 
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Michel Veillette <[email-masked]>
Date: Thu, 15 Dec 2016 18:52:34 +0000

Hi Randy

In the case of the current CoMI solution, this relationship is implemented using
an observers list as defined by RFC 7641 and a DTLS session. If both are healthy,
notifications can be transferred.

Other solutions may involve other mechanisms.

Regards,
Michel

-----Original Message-----
From: Turner, Randy [mailto:[email-masked]] 
Sent: Thursday, December 15, 2016 1:22 PM
To: Carsten Bormann <[email-masked]>
Cc: Michel Veillette <[email-masked]>; core@ietf. org WG <[email-masked]>
Subject: Re: [core] CoMI - long term relationship between network elements and management station

R.

>> How this concept of long term relationship between network elements  
>> and a management station should be addresed?
> 
> (Note that there is a proposal about “delegated observe” right now; 
> there also was some discussion about good ways to use Observe at the 
> Ludwigsburg T2TRG meeting.)
>

---

From: "Turner, Randy" <[email-masked]>
Date: Thu, 15 Dec 2016 18:55:04 +0000

Yes, I understand - I just wanted to clarify that it may be difficult to create a relationship with CoAP that resembles SNMP - they may serve the same purpose, but their implementations may be quite different.

I agree with Carsten that a more general solution might be the way to go, with CoMI a first-cut at this general solution.

R.

> On Dec 15, 2016, at 1:52 PM, Michel Veillette <[email-masked]> wrote:
> 
> Hi Randy
>

---

From: peter van der Stok <[email-masked]>
Date: Fri, 16 Dec 2016 08:29:56 +0100

> The COMI draft could be a place to do this, but an independent draft

I am in favour of an independent draft.
These long term relationships might be very loose indeed like let's wait 
some time and see what happens, or very tight where every packet loss is 
a disaster.

> want to repeat that problem.

I expect that unnecessary repetitions caused by lost acks are not an 
issue.

> 
>> Should CoMI servers (i.e. management stations) periodically 
>> re-register as an observer (e.g. every day)?
> 
> Most likely, something like this will need to be done anyway
> (management will want to know that the device is still there).  But we
> should define the details in a way that is as useful as possible to
> management applications.
> 
As far as I know, all relations between computers are restricted in 
time. How often reminders (extensions) need to be sent should be an 
application parameter in many cases.

Cheerio,

Peter

---

From: peter van der Stok <[email-masked]>
Date: Fri, 16 Dec 2016 08:47:21 +0100

Hi Michel,

Interesting subject.
I remember the long discussions taking place with respect to the observe 
draft.
Given the wide set of interests, these discussions were not easy and 
sometimes ran in loops.

See my comments below.

>    interested and the server MUST remove the associated entry from the

I find this text perfectly reasonable and probably covers a wide range 
of network problems.
As far as I know deciding whether the processor is faced with a network 
problem or a failing communication partner is unsolvable; unless we 
start incorporating stable storage.

> How this concept of long term relationship between network elements

Good question.
> Should CoMI clients send notifications only with non-confirmable CoAP 

Seems undesirable to me; you really want to know when there is a 
cmmunication problem to take other analysis or recovery actions.

> re-register as an observer (e.g. every day)?

Sounds reasonable to me. Applications can decide how often and under 
which conditions.
> Should we adopt a different method to transfer notifications?

For the moment I am reluctant to choose this option.
By the way, we have a connected probem in the bootstrap where a 
processor waits for a response but the time to wait is undetermined (2 
seconds to hours)

> Michel Veillette

cheerio,

Peter

---

From: Alexander Pelov <[email-masked]>
Date: Fri, 16 Dec 2016 10:19:25 +0100

Dear all,

This indeed is a good question we need to address. Personally, I’d be in favor of having a more lean CoMI document and handle the more advanced functions in a separate document (ideally, through a YANG module). I don’t have strong feelings in either direction, though.

I wouldn’t block a call for adoption for a question like this, e.g. ideally it would be up to the group to decide.

Best,
Alexander

> Le 16 déc. 2016 à 08:47, peter van der Stok <[email-masked]> a écrit :
> 
> Hi Michel,
> 
> Interesting subject.
> I remember the long discussions taking place with respect to the observe draft.
> Given the wide set of interests, these discussions were not easy and sometimes ran in loops.
> 
> See my comments below.
> 
> I find this text perfectly reasonable and probably covers a wide range of network problems.
> As far as I know deciding whether the processor is faced with a network problem or a failing communication partner is unsolvable; unless we start incorporating stable storage.
> 
> Seems undesirable to me; you really want to know when there is a cmmunication problem to take other analysis or recovery actions.
> 
> Sounds reasonable to me. Applications can decide how often and under which conditions.
> By the way, we have a connected probem in the bootstrap where a processor waits for a response but the time to wait is undetermined (2 seconds to hours)
> 
>> Regards,
>> Michel Veillette
> 
> cheerio,
> 
> Peter
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/core <https://www.ietf.org/mailman/listinfo/core>

---

From: Michel Veillette <[email-masked]>
Date: Fri, 16 Dec 2016 16:17:18 +0000

Hi Peter

About
   " By the way, we have a connected probem in the bootstrap where a 
   processor waits for a response but the time to wait is undetermined (2 
   seconds to hours)"

What king of problems are you anticipating in this case?
On the CoAP side, I see no issues about waiting for a response multiple hours, see section 5.2.2.
   "Note also that, while the CoAP protocol itself
   does not make any specific demands here, there is an expectation
   that the response will come within a time frame that is reasonable
   from an application point of view. As there is no underlying
   transport protocol that could be instructed to run a keep-alive
   mechanism, the requester may want to set up a timeout that is
   unrelated to CoAP's retransmission timers in case the server is
   destroyed or otherwise unable to send the response."

Michel

-----Original Message-----
From: peter van der Stok [mailto:[email-masked]] 
Sent: Friday, December 16, 2016 2:47 AM
To: Michel Veillette <[email-masked]>
Cc: [email-masked]; Core <[email-masked]>
Subject: Re: CoMI - long term relationship between network elements and management station

Hi Michel,

Interesting subject.

See my comments below.

Michel Veillette schreef op 2016-12-15 18:31:
> This mechanism typically require a long term relationship between 
> network elements (CoMI servers) and a management station (CoMI 
> client). However, RFC 7641 section 4.5.
> Transmission, required that

Good question.

cheerio,

Peter

---

From: Michel Veillette <[email-masked]>
Date: Fri, 16 Dec 2016 16:56:28 +0000

Hi Peter

To resolve this issue (long term relationship between network elements and management station),
 my personal preference is to extend the current observe mechanism to make it more resilient
to transmission failures.

For example, a new set of attributes can be added to implement an application level retry
mechanism on top of the already existing CoAP retry mechanism.

SKIP_ON_TX_ERROR
   If true, the current notification is dropped on transmission failure. The subsequent attempt
   is  performed with the next notification.
   If false, the subsequent attempt is  performed with the same notification.

MIN_DELAY_BETWEEN_TX_ERROR
   Minimum delay in seconds before sending the next notification after a transmission failure.
   This value is double after each consecutive transmission failure.

MAX_DELAY_BETWEEN_TX_ERROR
   Maximum delay in seconds before sending the next notification after a transmission failure.

MAX_CONSECUTIVE_TX_ERROR
   Number of consecutive transmission failures after which the client is removed form the
   list of observers.

This resilience is required to address use cases like:

- Maintenance of the management system (NMS). It is not desirable to see all nodes sending
  a notification during a down time of the management system be automatically
  un-registered.
- When security critical notifications are transferred. The drop of a single of these notifications
  should not prevent all subsequent notifications to be at lest attempted.

Regards,
Michel

-----Original Message-----
From: peter van der Stok [mailto:[email-masked]] 
Sent: Friday, December 16, 2016 2:47 AM
To: Michel Veillette <[email-masked]>
Cc: [email-masked]; Core <[email-masked]>
Subject: Re: CoMI - long term relationship between network elements and management station

Hi Michel,

Interesting subject.

See my comments below.

Good question.

cheerio,

Peter

---

From: Klaus Hartke <[email-masked]>
Date: Fri, 16 Dec 2016 21:12:40 +0100

> to transmission failures.

Using CoAP default parameters [1], a server will transmit a
confirmable notification 5 times over a period of 62 to 93 seconds if
the client does not react. If that's not enough, the number of
retransmissions can be increased:

   "MAX_RETRANSMIT can be freely adjusted, but a value that is too small
   will reduce the probability that a Confirmable message is actually
   received, while a larger value than given here will require further
   adjustments in the time values (see Section 4.8.2)." [2]

So if you want, you can let the server try to reach the client for
several hours. However, the idea is that the server gives up after a
reasonable amount of time and it becomes the responsibility of the
client to try to reach the server. This way, the server (which is
often the more constrained node) is freed from wasting resources on
clients that are no longer there.

Related to the discussion, don't forget that CoAP is a state transfer
protocol, not a message queue. The only event that CoAP-Observe can
notify is the event that resource state changed. If you need to
monitor other kinds of events, you must first convert them to resource
state for Observe, e.g., by appending them to a log file.

Klaus

[1] https://tools.ietf.org/html/rfc7252#section-4.8
[2] https://tools.ietf.org/html/rfc7252#section-4.8.1

---

From: Michel Veillette <[email-masked]>
Date: Fri, 16 Dec 2016 21:02:53 +0000

Hi Klaus

Effectively, the CoAP retransmission parameters (ACK_TIMEOUT, ACK_RANDOM_FACTOR, and MAX_RETRANSMIT) can be changed but this will affect all CoAP messages transmitted by the CoAP server, not just the notifications. Changing these timings globally is not acceptable.

Furthermore, the goal is not to increase the reliability of a single notification by spreading retries on a longer period or by performing more retries. Typically, notifications lose their usefulness if they are delayed too much. The goal is to keep the client in the observable list even in the case of transmission failures and this for a reasonable period.

The following scenario represents the current behavior mandated by RFC 7641:
  Notification  1 --->  (Transmission successful)
  Notification  2 --->
  Notification  3 ---X  (Transmission failure, client removed from the list of observers)

I'm proposing to also support a more resilient solution which support the following scenario:
  Notification  1 ---> 
  Notification  2 ---X
  Notification  3 --->
  Notification  4 --->
  Notification  5 ---X
  Notification  6 --->
  Notification  7 ---X
  Notification  8 ---X
  Notification  9 ---X    (x consecutive transmission failures, client removed from the list of observers)

Regards,
Michel

-----Original Message-----
From: Klaus Hartke [mailto:[email-masked]] 
Sent: Friday, December 16, 2016 3:13 PM
To: Michel Veillette <[email-masked]>
Cc: [email-masked]; Core <[email-masked]>
Subject: Re: [core] CoMI - long term relationship between network elements and management station

Michel Veillette wrote:
> To resolve this issue (long term relationship between network elements 
> and management station),  my personal preference is to extend the 
> current observe mechanism to make it more resilient to transmission failures.

Using CoAP default parameters [1], a server will transmit a confirmable notification 5 times over a period of 62 to 93 seconds if the client does not react. If that's not enough, the number of retransmissions can be increased:

So if you want, you can let the server try to reach the client for several hours. However, the idea is that the server gives up after a reasonable amount of time and it becomes the responsibility of the client to try to reach the server. This way, the server (which is often the more constrained node) is freed from wasting resources on clients that are no longer there.

Related to the discussion, don't forget that CoAP is a state transfer protocol, not a message queue. The only event that CoAP-Observe can notify is the event that resource state changed. If you need to monitor other kinds of events, you must first convert them to resource state for Observe, e.g., by appending them to a log file.

Klaus

---

From: Klaus Hartke <[email-masked]>
Date: Fri, 16 Dec 2016 22:31:50 +0100

> Effectively, the CoAP retransmission parameters (ACK_TIMEOUT, ACK_RANDOM_FACTOR, and MAX_RETRANSMIT) can be changed but this will affect all CoAP messages transmitted by the CoAP server, not just t…

Then change it only for notifications?

>   Notification  3 ---X  (Transmission failure, client removed from the list of observers)

(Assuming the transmission failure is the result of 5 transmission
attempts. So it looks more like this:)

   Notification  1 --->
   Notification  2 --->
   Notification  3 ---X (attempt 0)
   Notification  3 ---X (attempt 1)
   Notification  3 ---X (attempt 2)
   Notification  3 ---X (attempt 3)
   Notification  3 ---X (attempt 4) (client removed from the list of observers)

>   Notification  9 ---X    (x consecutive transmission failures, client removed from the list of observers)

This is what you get when you increase MAX_RETRANSMIT, except that the
server will also retransmit the latest notification between two state
changes:

  Notification  1 --->
  Notification  2 ---X
  Notification  3 --->
  Notification  4 --->
  Notification  5 ---X
  Notification  6 --->
  Notification  7 ---X (attempt 0)
  Notification  7 ---X (attempt 1)
  Notification  7 ---X (attempt 2)
  Notification  8 ---X (attempt 3)
  Notification  9 ---X (attempt 4) (client removed from the list of observers)

If you don't like that, don't do it?

Klaus

---

From: Michel Veillette <[email-masked]>
Date: Fri, 16 Dec 2016 21:59:52 +0000

About "Then change it only for notifications?"

The CoAP implementations I'm currently using don’t allow the use of multiple set of re-transmission parameters, those are global.
Are you aware of any CoAP implementations capable of supporting this approach?

About the last scenario, is it really allowed by RFC7252 to change the content of a CoAP message during the retransmission process (Between attempt 2 and 3 in your example)? In the specification, it is clear that an implementation can answer to a duplicate request using an updated content (section 4.5) but for the retries, the spec always refer to a re-transmission.

  Notification  1 --->
  Notification  2 ---X
  Notification  3 --->
  Notification  4 --->
  Notification  5 ---X
  Notification  6 --->

Regards,
Michel

-----Original Message-----
From: Klaus Hartke [mailto:[email-masked]] 
Sent: Friday, December 16, 2016 4:32 PM
To: Michel Veillette <[email-masked]>
Cc: Core <[email-masked]>
Subject: Re: [core] CoMI - long term relationship between network elements and management station

>   Notification  3 ---X  (Transmission failure, client removed from the 

(Assuming the transmission failure is the result of 5 transmission attempts. So it looks more like this:)

   Notification  1 --->
   Notification  2 --->

>   Notification  9 ---X    (x consecutive transmission failures, client removed from the list of observers)

This is what you get when you increase MAX_RETRANSMIT, except that the server will also retransmit the latest notification between two state
changes:

  Notification  1 --->
  Notification  2 ---X
  Notification  3 --->
  Notification  4 --->
  Notification  5 ---X
  Notification  6 --->

Klaus

---

From: Klaus Hartke <[email-masked]>
Date: Fri, 16 Dec 2016 23:40:21 +0100

> Are you aware of any CoAP implementations capable of supporting this approach?

A CoAP implementation maintains a timeout and a retransmission counter
for each active confirmable message. It shouldn't be too difficult to
pass the initial values as parameters (approximately around the line
of code that determines if the message is confirmable or
non-confirmable) instead of using the default values. I've just made
this change to my (unpublished) implementation and it took me about 20
seconds.

> About the last scenario, is it really allowed by RFC7252 to change the content of a CoAP message during the retransmission process (Between attempt 2 and 3 in your example)? In the specification, i…

That's what Section 4.5.2 of RFC 7641 [1] is about. The transmission
of the older notification is aborted and a new transmission is started
with the timeout and the retransmission counter of the aborted
transmission.

Klaus

[1] https://tools.ietf.org/html/rfc7641#section-4.5.2

---

From: Michel Veillette <[email-masked]>
Date: Mon, 19 Dec 2016 16:00:27 +0000

Hi Klaus and thank for your answers.

The proposed approach archive effectively the necessary resilience of the observe mechanism. The only drawback is the requirement to retry for a long period a specific notification, which might be an issue when this notification is not timestamp. (CoMI unlike RESCONF don't mandate the use of event-time). As a workaround, I suppose that a null notification can be automatically generated after x retries if a newer notification is not available.

For example:

   Notification  1 --->
   ....
   Notification  2 --->
   ....
   Notification  3 ---X    (attempt 0)
   Notification  3 ---X    (attempt 1)
   Notification  3 ---X    (attempt 2)
   Notification  null ---X (attempt 3, notification 3 is too old to be reported)
   Notification  null ---> (attempt 4)
   ....
   Notification  4 ---X   (attempt 0)
   Notification  4 ---X   (attempt 1)
   Notification  5 --->   (attempt 2)
   ....
   Notification  6 --->
   ....

Is it an acceptable solution?
Any other solution to propose?

Regards,
Michel;;

-----Original Message-----
From: Klaus Hartke [mailto:[email-masked]] 
Sent: Friday, December 16, 2016 5:40 PM
To: Michel Veillette <[email-masked]>
Cc: Core <[email-masked]>
Subject: Re: [core] CoMI - long term relationship between network elements and management station

> Are you aware of any CoAP implementations capable of supporting this approach?

A CoAP implementation maintains a timeout and a retransmission counter for each active confirmable message. It shouldn't be too difficult to pass the initial values as parameters (approximately around the line of code that determines if the message is confirmable or
non-confirmable) instead of using the default values. I've just made this change to my (unpublished) implementation and it took me about 20 seconds.

> About the last scenario, is it really allowed by RFC7252 to change the content of a CoAP message during the retransmission process (Between attempt 2 and 3 in your example)? In the specification, i…

That's what Section 4.5.2 of RFC 7641 [1] is about. The transmission of the older notification is aborted and a new transmission is started with the timeout and the retransmission counter of the aborted transmission.

Klaus

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 19 Dec 2016 18:29:40 +0100

Michel Veillette wrote:
> The proposed approach archive effectively the necessary resilience of the observe mechanism. The only drawback is the requirement to retry for a long period a specific notification, which might be an issue when this notification is not timestamp.

A notification contains only the first block of the resource
representation. A client has to retrieve any further blocks using
normal GET requests. If I understand Section 2.6 of RFC 7959 [1]
correctly, it should be possible that a server sends, for example, a
notification with a block size of 256 bytes for a recent state change
and a notification with a block size of 16 bytes (the minimum block
size) if the state change happened longer ago.

Would that solve your problem?

Klaus

[1] https://tools.ietf.org/html/rfc7959#section-2.6

---

From: Michel Veillette <[email-masked]>
Date: Mon, 19 Dec 2016 17:44:22 +0000

Hi Klaus

If this short block size is interpreted as a differed notification, I assume this can work. Personally, I prefer the creation of a notification in the CoMI event stream after a specific number of retries called let say "Communication loss". This notification has a double purpose, to kill the current notification which is now obsolete and to notify the client of missing notification(s).

Thanks again for you help.

Michel

-----Original Message-----
From: Klaus Hartke [mailto:[email-masked]] 
Sent: Monday, December 19, 2016 12:30 PM
To: Michel Veillette <[email-masked]>
Cc: Core <[email-masked]>
Subject: Re: [core] CoMI - long term relationship between network elements and management station

> The proposed approach archive effectively the necessary resilience of the observe mechanism. The only drawback is the requirement to retry for a long period a specific notification, which might be…

A notification contains only the first block of the resource representation. A client has to retrieve any further blocks using normal GET requests. If I understand Section 2.6 of RFC 7959 [1] correctly, it should be possible that a server sends, for example, a notification with a block size of 256 bytes for a recent state change and a notification with a block size of 16 bytes (the minimum block
size) if the state change happened longer ago.

Klaus

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 19 Dec 2016 19:12:26 +0100

> If this short block size is interpreted as a differed notification, I assume this can work. Personally, I prefer the creation of a notification in the CoMI event stream after a specific number of r…

It is a non-goal of Observe to inform a client of every resource state
change that happens or to inform a client of missed resource state
changes. Observe really just tries to keep the client updated about
the latest and only the latest resource state at the server. A
notification cannot really be obsolete, because if a state change
happened, the client should know about it -- unless there is a new
state change. Because Observe focuses only on the latest resource
state, if a server knows that the resource state will change soon (for
any reasonable definition of "soon"), it does not have to try too hard
to update the client about the soon-obsolete resource state.

So I think you should be able to achieve your goals by adjusting

(a) the number of retransmission attempts,
(b) the time between retransmission attempts,
(c) the block size of notifications, and
(d) the definition of "soon".

Hope this helps,
Klaus

---

From: "Turner, Randy" <[email-masked]>
Date: Mon, 19 Dec 2016 18:33:05 +0000

Hi Klaus, I thought the whole purpose of observe was to keep interested clients updated as to the state of a resource - every time the state changes, I get notified — this seems to be in conflict with the first
sentence of your email below — I understand about not informing clients of potential missed state in the past, but from time t(n), I thought the whole point was to get notified of each state change t(n++) - which as I said
conflicts with the first part of your first sentence below.

Randy

> On Dec 19, 2016, at 1:12 PM, Klaus Hartke <[email-masked]> wrote:
> 
> Michel Veillette wrote:

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 19 Dec 2016 20:36:10 +0100

> conflicts with the first part of your first sentence below.

In a perfect world of zero latency and infinite bandwidth it would be
possible for every client to observe every state change that a
resource at a server goes through. However, in a world of low-power,
lossy networks and nodes with various levels of constraintness, it is
not unlikely that a resource state occasionally (or often!) changes
faster than all clients can reliably be notified. You can deal with
this problem in two ways: either you slow down the rate of state
changes, or you do not notify every client of every state change [1].
Observe opts for the latter and chooses a notification strategy that
tries to keep observers updated only about the *latest* resource
state. This solves a lot of problems (no storage needed to buffer a
queue of notifications; slow observers don't slow down the whole
system) and works for many - but not all - applications.

Klaus

[1] http://ferd.ca/queues-don-t-fix-overload.html

---

From: peter van der Stok <[email-masked]>
Date: Tue, 20 Dec 2016 09:23:29 +0100

you do not notify every client of every state change [1].
> system) and works for many - but not all - applications.
I completely agree with the above strategy.
It is well-known that in overload situations LIFO is the best way to 
satisfy deadlines.
And who needs yesterday's paper....?

When, for example, you want to maintain financial records, you don't 
want to use observe.

Peter