Re: [core] sleepy to sleepy communication I-Ds

I've read these drafts, too. I think it is very good that we have new proposals to support sleeping nodes better. It is needed! Thanks for writing the proposals.

It is interesting to compare the spec to draft-vial-core-mirror-proxy. You seem to take an approach where communications in the sensor network are in the focus, whereas draft-vial defined a proxy that could be used by any regular client.

I liked the resource model in draft-vial better, because it seems so straightforward from a REST point of view. POST to get an ID from the proxy, PUT to update. In particular, it is easy for me to understand how the URIs get constructed and where traffic is routed. A random client somewhere else on the Internet knows how to go to mirror.example.net/17/temp. I don't necessarily understand how the same thing happens in draft-giacomin, can you expand on that?

On the other hand, I didn't like the writable resource monitoring model in draft-vial so much. It would be a drag to have to poll everything when you wake up. I'd rather see a model where I can wake up and ask what has changed. Maybe that can be changed in draft-vial.

In any case, whatever we do, some additional information (like the sleepy option) in requests and responses might actually make sense as a generic mechanism. I suspect it should be something that works for both HTTP and COAP, if that can made to happen. I'm not expert enough to understand exactly how. However, accurate clock sync may be difficult if you attempt to achieve a very high ratio of sleep vs. awake. Even there it might be useful to think in terms of waking up and letting the proxy know you're now ready to act, than attempting to have the proxy fire a message at a calculated awake time. Draft-vial already works in this mode, as the sensors will wake up and inform/query the proxy on their own timing.

In conclusion it seems that we have a architectural choice ahead of us. We could have sleepy nodes delegate their web existence to other nodes (like draft-vial does), enabling both other devices in the same network and devices elsewhere in the Internet to interact with mostly the other node. Or we could build support to COAP and proxies for mediation between sleeping nodes (like draft-giacomin and draft-fossati does). At the high level, the effects are similar but there are significant differences in details. I confess that I like the former model better, because it separates the support for sleepy nodes from whatever is needed by nodes interacting with them. But we probably don't understand the design space well enough yet to make a real decision. At least I certainly don't.

Jari

On 29.02.2012 23:46, Thomas Fossati wrote:
> Hello all,
>
> today we have submitted a couple of I-Ds proposing three new CoAP Options that try dealing with the requirement REQ3 of draft-shelby-core-coap-req-04
>
>      The ability to deal with sleeping nodes.  Devices may be
>      powered off at any point in time but periodically "wake up"
>      for brief periods of time.
>
> leveraging on different techniques, i.e. store-and-forward, explicit origin delegation, REST interface to carbon-copy an observed resource.
>
>
> Their URIs and respective abstracts are given in the following for convenience:
>
> (1) "Sleepy Option for CoAP" (see http://tools.ietf.org/html/draft-giacomin-core-sleepy-option-00)
>
> This draft defines a new CoAP elective option, Sleepy, targeted specifically at proxies and used to signal a proxy the will to initiate an asynchronous request/response exchange.  The Sleepy option is partitioned in 2/3 subfields indicating: the remaining time before sleep, the expected sleep interval, and (optionally) the on-duty interval.
>
>
> (2) "Publish and Monitor Options for CoAP" (see http://tools.ietf.org/html/draft-fossati-core-publish-monitor-options-00)
>
> This draft defines two additional Options for the Constrained Application Protocol (CoAP) especially targeted at sleepy sensors: Publish and Monitor.
>
> The Publish Option enables opportunistic updates of a given resource state, by temporarily delegating the authority of the Publish'ed resource to a Proxy node.  The whole process is driven by the (sleepy) origin -- which may actually never need to listen.
>
> The Monitor Option complements the typical Observe pattern, enabling the tracking of a resource hosted by a node sleeping most of the time, by taking care of establishing and maintaining an Observe relationship with the (sleepy) origin on behalf of the (sleepy) client.
>
>
> We look forward for receiving comments and suggestions to the proposed solutions.
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>