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

From: Jari Arkko <[email-masked]>
Date: Mon, 05 Mar 2012 00:05:58 +0200

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Thomas Fossati <[email-masked]>
Date: Mon, 5 Mar 2012 06:28:37 +0100

Hi Jari,

> 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…

you mean using the Publish option ?  If so, the random client uses the same URI that is associated to the sleepy resource (whose existence is pretty safe to be assumed in a REST environment) and asks the proxy acting as the delegated origin to serve it via Proxy-URI.  So, communication is pretty straightforward; discovery could be more tricky because I fear it necessarily goes through an RD -- i.e. discovery via /.well-known/core may not work (I have expanded a bit on this in the following.)

> 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…

And we neither :-)

We are just trying to explore the problem space by using a bunch of different strategies.  We play with one rule (use the proxy as a mediator), and one constraint (stay in CoAP).

I think that the second is especially important, because it allows us to see how much we can achieve using just the protocol semantics (and its self-extension facility, options).

That's where we can hit interesting flaws and strengths of CoAP.

E.g., differently from HTTP, we have an explicit Proxy-URI object (which BTW is a wonderful thing): let's try to see how much can be said with it, for example doing origin delegation without having to create multiple different 'same resource' identifiers through mirroring.

Another important thing we are going to hit this way is how discovery based on /.well-known/core is meant to go through proxies.  AFAIK both core and link-format I-Ds are rather succinct on this matter, and even if it seems reasonable to assume that the /.well-known/core resource is both query-able through, and cacheable by, a proxy, perhaps the facts are not very much so.  We seem too much often to assume that the "well-known" interface relies on the resource authority being defined by the source address of the UDP packet carrying the response.  If so, querying the well-known interface (especially multicast) through a Proxy-URI has little hope to be fully functional.  We are sort of abusing an implicit L3 locator as the identifier of the resource authority, which makes "well-known" discovery generally incompatible with proxy mediated communication, unless each target URI in a link is given as a URI and not as a relative-ref (a thing that would be nice to discuss somewhere in the spec, perhaps the DNA I-D by Peter, Kerry and Anders is the right place ?)

To cut a long story short, I don't really know if we are better off establishing a new component like the MP proposed by Matthieu, or extend the base spec with one or more options that give the proxy new ad hoc capabilities.  The important IMHO is to keep on pushing our two (complementary) approaches as much as possible until, as you've said, we reach a better understanding of the matter that can inform a wise choice.

Thomas.

PS: It may also turn out that REQ3 of draft-shelby-core-coap-req is not an application layer issue! ;-)

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Mon, 5 Mar 2012 09:09:33 +0100

> PS: It may also turn out that REQ3 of draft-shelby-core-coap-req is not an application layer issue! ;-)

Indeed sensor networks support sleeping using radio duty cycling at
lower layers, this turns out in having the sleeping functionality
without any loss of communication at the upper layers.

Best,
Angelo

---

From: Jari Arkko <[email-masked]>
Date: Mon, 05 Mar 2012 11:16:50 +0200

Angelo,

> without any loss of communication at the upper layers.

We discussed this a couple of IETFs back. Since then I've been doing some talking to our researchers who measure and improve power usage in radios.

First, duty cycling is already pretty widely used for radio technology. All cellular systems, for instance, turn off the radio except in during the time they listen for possible incoming paging signals, system information necessary to stay in contact at all, or when they have been granted a time slot to send.

Secondly and more importantly, per their measurements, even after all the above techniques, periodic listening for possibly incoming messages is the biggest consumer of energy in applications where we'd like to have a long battery life, such as in sensors. That power usage dwarfs everything else, so it has to come down, somehow, to make an improvement.

So if we want to achieve significantly longer battery lifetimes (and I claim we need those) we need to change some things. Obviously a lot of the link layers can be tuned better, implementing simply longer paging frequencies, for instance. My hypothesis is that we'll have to go longer than what typical application protocol timeouts are today, so the change would be something that is visible to applications. We could change some of the timeouts, but it is not clear that network buffers and all underlying mechanisms deployed today support those without changes. And in general, I think it is better to fit the communication model to the problem at hand than vice versa. As a result, I personally believe that we need to build applications that natively communicate in ways that make sleep modes easy. Such as publish-subscribe instead of direct request-response from anyone who needs the information. But like I said, this is a hypothesis and I'd love to be proven wrong.

Jari

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Mon, 5 Mar 2012 10:26:39 +0100

I agree with you that this can save a lot more of energy, if the hosts
can provide service during theirs "office hours" :)

However if the nodes will behave in such a way, for sure this will be
visible to the clients and lots of infrastructure (proxies) will be
required to get anything usable by the users.

With regular sensor networks duty cycling, a ~3 years lifetime is
feasible with regular batteries (depending upon actual usage and
network traffic). Are you targeting a use case with tighter
requirements?

Best,
Angelo

On Mon, Mar 5, 2012 at 10:16, Jari Arkko <[email-masked]> wrote:
> We discussed this a couple of IETFs back. Since then I've been doing some
> talking to our researchers who measure and improve power usage in radios.
>
> First, duty cycling is already pretty widely used for radio technology. All
> cellular systems, for instance, turn off the radio except in during the time
> they listen for possible incoming paging signals, system information
> necessary to stay in contact at all, or when they have been granted a time
> slot to send.
>
> Secondly and more importantly, per their measurements, even after all the
> above techniques, periodic listening for possibly incoming messages is the
> biggest consumer of energy in applications where we'd like to have a long
> battery life, such as in sensors. That power usage dwarfs everything else,
> so it has to come down, somehow, to make an improvement.
>
> So if we want to achieve significantly longer battery lifetimes (and I claim
> we need those) we need to change some things. Obviously a lot of the link
> layers can be tuned better, implementing simply longer paging frequencies,
> for instance. My hypothesis is that we'll have to go longer than what
> typical application protocol timeouts are today, so the change would be
> something that is visible to applications. We could change some of the
> timeouts, but it is not clear that network buffers and all underlying
> mechanisms deployed today support those without changes. And in general, I
> think it is better to fit the communication model to the problem at hand
> than vice versa. As a result, I personally believe that we need to build
> applications that natively communicate in ways that make sleep modes easy.
> Such as publish-subscribe instead of direct request-response from anyone who
> needs the information. But like I said, this is a hypothesis and I'd love to
> be proven wrong.
>
> Jari
>
>

---

From: Zhen Cao <[email-masked]>
Date: Wed, 7 Mar 2012 18:02:12 +0800

> network traffic). Are you targeting a use case with tighter

Are you sure about the battery lifetime? I am using two AA battery
with 700mAH each. And the power consumption of the RF module is 23mA,
21uA, 1uA for active, idle and sleep.  So normally for me it is
several month at most.

Best regards,
Zhen

-- 
Best regards,
Zhen

---

From: Thomas Fossati <[email-masked]>
Date: Sat, 10 Mar 2012 09:29:53 +0100

Hello all,

a small note to inform that we've just uploaded the -01 version of the Publish/Monitor I-D:

  http://tools.ietf.org/html/draft-fossati-core-publish-monitor-options

It includes access control rules on the published resource via a "CRUD" mask, an interface for explicit drop of the delegation, and some initial ramblings on discovery.

We plan to bring to Paris a proxy implementing the Publish logics.  If anyone is interested to implement the client bits (which should be quite easy) and wants to do some testing, please drop us a line.

Thomas.

---

From: "Dijk, Esko" <[email-masked]>
Date: Tue, 13 Mar 2012 13:21:46 +0000

Typical industry requirements for battery-powered wireless sensors are in the order of 7-10 years, from what I know.
So certainly tighter requirements.

Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Zhen Cao
Sent: Wednesday 7 March 2012 11:02
To: Angelo P. Castellani
Cc: core WG
Subject: Re: [core] sleepy to sleepy communication I-Ds

Best regards,
Zhen

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.