Subject: [core] New Version Notification for draft-koster-core-coap-pubsub-01.txt

From: Michael Koster <[email-masked]>
Date: Mon, 9 Mar 2015 17:35:32 -0700

Hi all,

We have submitted a substantial update of the CoAP PubSub draft. This version is meant to address comments and issues, and simplify this draft relative to the previous drafts.

Notable changes include:

- The broker is defined as a server, other participants are clients; removed the different endpoint role definitions
- The broker function set is defined in a similar way as the RD function set is in the RD draft
- Topics are created on the broker, not through RD, and may be registered with a RD using the con parameter
- RD registration of PubSub clients is not required to interact with the broker
- removed references to objects, etc. and only requiring URI-formed topics

Open issues:
- Can we define a guaranteed delivery option where messages are delivered at least once, similar to MQTT QoS=1?
- Does this adequately address the sleepy node and mirror proxy use cases?

Best regards,

Michael

-----------------------------------------------------------------------------------------
A new version of I-D, draft-koster-core-coap-pubsub-01.txt
has been successfully submitted by Michael Koster and posted to the
IETF repository.

Name:		draft-koster-core-coap-pubsub
Revision:	01
Title:		Publish-Subscribe Broker for the Constrained Application Protocol (CoAP)
Document date:	2015-03-09
Group:		Individual Submission
Pages:		17
URL:            http://www.ietf.org/internet-drafts/draft-koster-core-coap-pubsub-01.txt
Status:         https://datatracker.ietf.org/doc/draft-koster-core-coap-pubsub/
Htmlized:       http://tools.ietf.org/html/draft-koster-core-coap-pubsub-01
Diff:           http://www.ietf.org/rfcdiff?url2=draft-koster-core-coap-pubsub-01

Abstract:
   The Constrained Application Protocol (CoAP), and related extensions
   are intended to support machine-to-machine communication in systems
   where one or more nodes are resource constrained, in particular for
   low power wireless sensor networks.  This document defines a publish-
   subscribe broker for CoAP that extends the capabilities of CoAP for
   supporting nodes with long breaks in connectivity and/or up-time.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 10 Mar 2015 07:40:30 +0100

> - Can we define a guaranteed delivery option where messages are
> delivered at least once, similar to MQTT QoS=1?

(Which of course raises the question: can MQTT QoS=1 provide
"guaranteed" delivery?)

I think that any event-based scheme needs to discuss what to do when
message rates go beyond capacity.  This is best handled as part of the
architecture and not as an afterthought, so everyone knows what to
discard and how to make sense of a message stream that includes discards.

The Observe model underlying the current version of pubsub is
overload-proof: You always get fresh data.

If a history has to be kept, this is best modelled in REST explicitly as
a time series.  SenML does some of this right in the media type.  I
think the fun question will be how does a broker interact with time
series.  Can the publisher get some "custody transfer" semantics so it
can free buffer space?  Can the broker somehow "integrate" data
(possibly enhanced by understanding the media type)?  How to indicate
overload losses?

Let's have a face-to-face discussion of the architectural issues at the
T2TRG meeting on Sunday (we can have the mailing list discussion leading
up to this right here on CoRE).  Then we maybe can focus the WG segment
on Thu/Fri on a discussion of which part of this (larger) problem to
slice off and in which bites.  I do believe the current pubsub draft
hits a sweet spot here, but what about the rest of the picture.

Grüße, Carsten

---

From: Michael Koster <[email-masked]>
Date: Thu, 12 Mar 2015 06:07:22 -0700

> (Which of course raises the question: can MQTT QoS=1 provide
That’s a good question. What constitutes a guarantee? In MQTT, QoS=1 means application level ACK on each link (publish in to and publish out of the broker).  So I would say that CoAP with Confirmable messages should be equivalent to QoS=1, assuming a CoAP ACK can be used as the equivalent of MQTT PUBACK. (Only MQTT QoS=2 has the broker relay operation built into the protocol handshake.) 

> discard and how to make sense of a message stream that includes discards.
I see your point. There will always be some over-run case and we need to architect in the behavior in those situations. It seems like client publish flow control would be reasonable. Currently, there is no real flow control, and delaying ACKs may just cause more messages to be sent.

> (possibly enhanced by understanding the media type)?  How to indicate
A sequence object mode is very interesting, and something I’ve considered for the general case of observe with the pmin parameter. If more than one reportable event happens during the pmin-defined quiet period between notifications, the samples may be stored and reported as a sequence object. The same could be used for elastic buffering in PubSub.

> hits a sweet spot here, but what about the rest of the picture.
Thanks, looking forward to further discussion.