Subject: [core] Sleepy node support with the CoAP pub/sub broker

From: Ari Keränen <[email-masked]>
Date: Tue, 24 Mar 2015 16:22:18 -0500

Hi all,

One of the goals of the pub/sub broker draft [1] is to provide support 
for "sleepy nodes". In particular, the pub/sub broker provides similar 
functionality as the Mirror Server(/Proxy).

The question is does this functionality match what your scenarios and 
use cases for sleepy nodes have as requirements?

Is there something missing? Should something be tweaked and/or clarified?

Cheers,
Ari

[1] https://tools.ietf.org/html/draft-koster-core-coap-pubsub-01

---

From: peter van der Stok <[email-masked]>
Date: Tue, 24 Mar 2015 22:45:19 +0100

Hi Ari,

Indeed we think that the pubsub broker draft is a good start but does 
not cover all aspects of the sleepy nodes.
It is not clear to us what the purpose of the pubsub broker draft is:
- is it a solution for sleepy nodes, then it does not cover all 
functionality we analysed.
- is it a pubsub addition to coap, that can be applied to sleepy nodes, 
then a sleepy node draft that also refers to pubsub broker draft seems 
appropriate.

Peter

Ari Keränen schreef op 2015-03-24 22:22:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Ari Keränen <[email-masked]>
Date: Tue, 24 Mar 2015 16:53:34 -0500

Hi Peter,

The draft is a pub/sub addition to CoAP that tries to cover as much of 
the sleepy node cases as reasonable.

Which functionality in particular can not be satisfied by the current 
pub/sub broker draft?

And regardless of whether the pub/sub broker draft satisfies the sleepy 
node use cases, I think additional informational document exploring the 
problem space more thoroughly is useful.

Cheers,
Ari

---

From: peter van der Stok <[email-masked]>
Date: Tue, 24 Mar 2015 23:09:47 +0100

Ari,

what I did not see:
- how to send values from broker to sleepy node,
- how is sleepy node configured,
- how can sleepy node be configured to send data directly to groups or 
single nodes.

Peter

Ari Keränen schreef op 2015-03-24 22:53:
> And regardless of whether the pub/sub broker draft satisfies the
> sleepy node use cases, I think additional informational document
> exploring the problem space more thoroughly is useful.
> 
> 
> Cheers,
> Ari
>

---

From: Ari Keränen <[email-masked]>
Date: Wed, 25 Mar 2015 01:28:10 -0500

Good questions, Peter. Some ideas / questions inline.

> - how to send values from broker to sleepy node,

The sleepy nodes, when waking up, would do a get to the broker to get 
the value(s) published to them. This is very briefly discussed in 
section 6, but definitely should be elaborated more.

> - how is sleepy node configured,

What kind of configuration you had in mind?

> - how can sleepy node be configured to send data directly to groups or

The sleepy node, or any other node, would not necessarily know who are 
the receivers of the data. The node would just publish its data to a 
topic and it would be delivered by the broker to all subscribers.

Does this make sense?

Cheers,
Ari

---

From: peter van der Stok <[email-masked]>
Date: Wed, 25 Mar 2015 14:55:48 +0100

HI Ari,

> topic and it would be delivered by the broker to all subscribers.

With directly, I mean without passing through the broker. The broker may 
set up all information to assure that destinations know which messages 
to receive.
For example, using multicast addresses pre-figured or dynamically 
created may do the trick.
I am sure other solutions can be provided.

Peter

---

From: Michael Koster <[email-masked]>
Date: Wed, 25 Mar 2015 11:18:01 -0500

Brokerless PubSub was brought up in the T2TRG. It would probably be RD or another function set on the broker, e.g. Link-batch, to negotiate the path connections. It could also use specialized bindings for e.g. multicast push.  I’m sure there are more ideas. 

Let’s discuss this before the MG if possible.

Cheers,

Michael

On Mar 25, 2015, at 8:55 AM, peter van der Stok <[email-masked]> wrote:

> With directly, I mean without passing through the broker. The broker may set up all information to assure that destinations know which messages to receive.
> For example, using multicast addresses pre-figured or dynamically created may do the trick.

---

From: Floris Van den Abeele <[email-masked]>
Date: Fri, 27 Mar 2015 10:37:29 +0100

In regards to the CREATE interface, does the broker return the created
path via Location-Path options in its 2.01 response? The current text
seems unclear in this regard (I assume that it does?).

In regards to the 'sleepy node operation', the mirror server id has a
useful feature named the 'modification check' where a SEP can request
the mirror server to return a list of its mirrored resources (i.e.
topics) that were changed by other clients since it has last performed a
modification check. This allows the SEP to only request those resources
that were actually changed (by others!) instead of always having to
retrieve all resources. Now, I don't know if this use-case in considered
important for the PubSub id, i.e. if clients are expected to have only 1
topic it might not prove interesting (but I'm guessing clients will
usually have more than one topic).

Also, it turns out that tracking changes to mirrored resources (or
topics) by parties other than the SEP is not that trivial. As this
implies a sense of ownership, which might not always be reliably
provided by the client's UDP endpoint (e.g. for mobile sleepy clients)
which was the assumption in the mirror ID. I'm guessing the same holds
true for the DELETE interface in the PubSub draft. But I seem that this
is addressed partly in section 7, i.e. by relying on DTLS. In the past
we have returned an authorization token to the client that it includes
in every action to work around this problem in an ad-hoc manner.

BR,
Floris