Subject: Re: [core] My notes about draft-koster-core-coap-pubsub-05

From: Michael Koster <[email-masked]>
Date: Mon, 14 Nov 2016 15:05:05 +0900

Hi Hannes,

The main difference between CoAP Pubsub and LWM2M queue mode is as follows:

In LWM2M Queue mode, the device operates in server role and must expose itself through the firewall. It does this by taking advantage of the Resource Directory registration update (refresh) function, or an ongoing observe relationship with notifications. Both of these will be sent from the device behind the firewall to the service layer on the northbound side of the firewall. The service layer must then "promptly" issue any requests to the device while the reverse tunnel is open, following quickly behind the response to the RD refresh or notification, before the firewall tunnel closes. There is also a mechanism for the device to limit the amount of interaction the service layer is allowed to do before the tunnel closes again,or before the device goes back to sleep. 

One issue with LWM2M queue mode is that there is not a deterministic window of communication nor handshake that guarantees the service layer requests to the device will succeed. It depends a lot on well characterized behavior of the firewall timing and/or the device staying awake to receive requests. The queueing of requests to the device is defined in that the service layer will retain these requests until the device performs the registration refresh or notification.

In CoAP Pubsub the device works in client mode, in which the client mode device is responsible for initiating all communication with the broker. This is very convenient for sleepy devices and devices behind firewalls that are not generally reachable from the northbound side of the firewall. If the device is a sensor, it can simply publish whenever it wants, similar to notifications in LWM2M queueu mode. If the pubsub device is an actuator, it needs to subscribe to the broker for actuator updates. If the device is a sleepy actuator, it must issue periodic polls to the broker to retrive the state updates.

I can see these 2 modes being optimized for different use cases. 

Do you think we should add a section in the draft to describe this comparison, like other approaches? Would this help people understand CoAP pubsub?

The brokerless scenario is really about integrating the broker endpoint onto a peer node, so peer to peer pubsub may be a better description, though there may still be asymmetry that allows one of the devices to sleep while the other listens.

Best regards,

Michael

> On Aug 3, 2016, at 4:46 PM, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi all,
> 
> I read through draft-koster-core-coap-pubsub-05 and have a few questions.
> 
> The document makes sense to me. I do, however, wonder whether you could
> compare the described functionality with the LWM2M queue mode. There
> appear to be lots of similarities but the "caching" concept in LWM2M is
> better worked out.
> 
> I am not sure whether the brokerless scenario makes sense given the
> described usage environment with sleepy nodes.
> 
> Ciao
> Hannes
> 
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core