Subject: [core] Event Cascade Loops

From: Robert Quattlebaum <[email-masked]>
Date: Fri, 22 Oct 2010 10:44:42 -0700

I just wanted to bring up a potential problem and a proposed solution.

If CoAP devices can issue requests to other CoAP devices as a direct response of it itself receiving a request (what I call a "cascade") it becomes possible for infinite loops to be created. This is obviously a bad thing.

My proposed solution would involve a new header option, which at the moment I will refer to as the "cascade-count" option. The cascade-count option is only added to an outbound request if that request was spawned by a previous inbound request. The rules are as follows:

	* If the inbound request does not have a cascade-count, the value of the cascade count in the outbound request is set to '128'.
	* If the inbound request has a cascade-count, then the that value minus one is set as the cascade-count of the outbound request. 
	* If the inbound request has a cascade-count of zero, then no outbound requests are allowed. 

Note that this is different than a "hop" count because we aren't tracking any particular set of data---we are tracking a cascade of events. The option itself would be elective, but if adopted should be REQUIRED to be supported and used by any node where an inbound request could automatically trigger automatic outbound requests.

This capability would be very important for Peter's "observation via callbacks" idea. Resources changed by external requests should trigger callbacks with a cascade-count. Without this option, or a similar mechanism, an infinite cascade loop would likely continue until some or all of the devices in the loop are power-cycled (or the configuration was changed to prevent the loop).

Thoughts?

__________________
Robert Quattlebaum
Jabber: [email-masked]
eMail:  [email-masked]
www:    http://www.deepdarc.com/

---

From: Peter Bigot <[email-masked]>
Date: Sun, 24 Oct 2010 04:05:17 -0500

Thought about this some, and have concluded it shouldn't be CoAP's problem
to solve.  Detecting and reacting to cascades is a policy decision that
doesn't belong in what's essentially a UDP transaction protocol.

Cascades exist only if the business logic associated with the resources
supported by a server enables them.  If I have a cloud of read-only
temperature sensors, there is no potential for a cascade.

If CoAP specifies some behavior where a cascade can be induced without
involving upper layers, we need to fix it.  I think the only place where
this might happen is in the definition of "proxy" (I don't think it does
happen there, but it's a possibility).

Finally, there should be nothing in CoAP that prevents you from implementing
exactly this capability in your API: define a critical option, ensure your
requests include it, and that the business logic implemented in your servers
propagates it.  If CoAP doesn't allow you to do this, it needs to be fixed.

This could be a suggestion in a "best practices" informational RFC, or be
adopted by some industry that requires it for interoperability.  My opinion
is it's not worth an RFC in its own right: it has too much policy hard-coded
(like the default value for a cascade count, or even whether there should be
a default value).  Having too many optional features that don't have clear
motivation for most applications will slow adoption of the base CoAP
standard.

Peter

On Fri, Oct 22, 2010 at 12:44 PM, Robert Quattlebaum <[email-masked]>wrote:

> If CoAP devices can issue requests to other CoAP devices as a direct
> response of it itself receiving a request (what I call a "cascade") it
> becomes possible for infinite loops to be created. This is obviously a bad
> thing.
>
> My proposed solution would involve a new header option, which at the moment
> I will refer to as the "cascade-count" option. The cascade-count option is
> only added to an outbound request if that request was spawned by a previous
> inbound request. The rules are as follows:
>
>        * If the inbound request does not have a cascade-count, the value of
> the cascade count in the outbound request is set to '128'.
>        * If the inbound request has a cascade-count, then the that value
> minus one is set as the cascade-count of the outbound request.
> Note that this is different than a "hop" count because we aren't tracking
> any particular set of data---we are tracking a cascade of events. The option
> itself would be elective, but if adopted should be REQUIRED to be supported
> and used by any node where an inbound request could automatically trigger
> automatic outbound requests.
>
> This capability would be very important for Peter's "observation via
> callbacks" idea. Resources changed by external requests should trigger
> callbacks with a cascade-count. Without this option, or a similar mechanism,
> an infinite cascade loop would likely continue until some or all of the
> devices in the loop are power-cycled (or the configuration was changed to
> prevent the loop).
>
> Thoughts?
>
> __________________
> Robert Quattlebaum
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>