Subject: [core] Do we need a CORE charter item for CoAP support of Sleepy Nodes?

From: "Rahman, Akbar" <[email-masked]>
Date: Thu, 1 Aug 2013 12:02:30 -0400

Hi,

Carsten asked me to send this message out to the WG list as we did not
have a chance to discuss the Sleepy Node topic in this IETF due to a
lack of time on the agenda. 

------------------------------------------------------------------------
------

We have several current I-Ds in CORE (and LWIG) that discusses the topic
of Sleepy Nodes.  Among those are:

draft-dijk-core-sleepy-reqs-00
<https://datatracker.ietf.org/doc/draft-dijk-core-sleepy-reqs/> 

draft-dijk-core-sleepy-solutions-01
<https://datatracker.ietf.org/doc/draft-dijk-core-sleepy-solutions/> 

draft-hong-lwig-sleepynode-problem-statement-00
<https://datatracker.ietf.org/doc/draft-hong-lwig-sleepynode-problem-sta
tement/> 

draft-rahman-core-sleepy-03
<https://datatracker.ietf.org/doc/draft-rahman-core-sleepy/> 

Hence the following question to the WG:

*         Should we have a CORE deliverable for CoAP support of Sleepy
Nodes?

Please write back with your thoughts!

Best Regards,

Akbar

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 2 Aug 2013 16:23:14 +0200

I do think we should have in CORE a deliverable for CoAP support of 
Sleepy Nodes,

we have seen a lot of ideas and mail discussion about this topic one 
year ago,
and the 4 individual submissions (if I am not wrong there are also a 
couple of the expired drafts on the topic)
on the same subject listed by Akbar is a clear sign of interest and 
energy to work on it

cheers
/Sal

-- 
Salvatore Loreto, PhD
www.sloreto.com

On 8/1/13 6:02 PM, Rahman, Akbar wrote:
> ------------------------------------------------------------------------------
>
> We have several current I-Ds in CORE (and LWIG) that discusses the 
> topic of Sleepy Nodes.  Among those are:
>
> <https://datatracker.ietf.org/doc/draft-hong-lwig-sleepynode-problem-statement/>
>
> ·Should we have a CORE deliverable for CoAP support of Sleepy Nodes?
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: "Pete St. Pierre" <[email-masked]>
Date: Fri, 2 Aug 2013 10:16:24 -0700

I agree. The CoAP base spec has extensions that really extend its utility (block, observe, groupcomm, etc.) and I think adding sleeping nodes is critical if we're going to address the most constrained environments.

...Pete

On Aug 2, 2013, at 7:23 AM, Salvatore Loreto <[email-masked]> wrote:

> I do think we should have in CORE a deliverable for CoAP support of Sleepy Nodes,
> 
> we have seen a lot of ideas and mail discussion about this topic one year ago,
> and the 4 individual submissions (if I am not wrong there are also a couple of the expired drafts on the topic)
> on the same subject listed by Akbar is a clear sign of interest and energy to work on it
> 
> cheers
> /Sal
> 
> -- 
> Salvatore Loreto, PhD
> www.sloreto.com
> 
> 
>> Carsten asked me to send this message out to the WG list as we did not have a chance to discuss the Sleepy Node topic in this IETF due to a lack of time on the agenda.
>>  
>> We have several current I-Ds in CORE (and LWIG) that discusses the topic of Sleepy Nodes.  Among those are:
>>  
>>  
>> ·         Should we have a CORE deliverable for CoAP support of Sleepy Nodes?
>>  
>>  

--
Pete St. Pierre
[email-masked]
(650) 506-2152

---

From: "Keoh, Sye Loong" <[email-masked]>
Date: Fri, 2 Aug 2013 19:03:13 +0000

Dear all,

I think sleepy node is an important topic, and most of the sensors and actuators need to conserve energy. Therefore, I think we need to tackle this issue. Yes, would agree to have a CoRE charter item for sleepy nodes.

cheers
Sye Loong
________________________________
From: [email-masked] [[email-masked]] on behalf of Rahman, Akbar [[email-masked]]
Sent: Thursday, August 01, 2013 6:02 PM
To: [email-masked]
Subject: [core] Do we need a CORE charter item for CoAP support of Sleepy Nodes?

Hi,

draft-dijk-core-sleepy-reqs-00<https://datatracker.ietf.org/doc/draft-dijk-core-sleepy-reqs/>

draft-dijk-core-sleepy-solutions-01<https://datatracker.ietf.org/doc/draft-dijk-core-sleepy-solutions/>

draft-hong-lwig-sleepynode-problem-statement-00<https://datatracker.ietf.org/doc/draft-hong-lwig-sleepynode-problem-statement/>

draft-rahman-core-sleepy-03<https://datatracker.ietf.org/doc/draft-rahman-core-sleepy/>

Best Regards,

Akbar

________________________________
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.

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Fri, 2 Aug 2013 20:23:19 +0000

Dear list

I still think radio duty cycling (virtually always-on with a duty cycly << 1%) is a preferable way to do it because it can be implemented in an independent lower layer without the need for any infrastructure.

However, there are very valid scenarios for sleepy nodes (the application decides when to sleep and wake up). For these we need infrastructure at the application layer, which should be defined in a standard way. Thus, we should work in this!

Ciao
Matthias

From: [email-masked] [mailto:[email-masked]] On Behalf Of Keoh, Sye Loong
Sent: Freitag, 2. August 2013 21:03
To: Rahman, Akbar; [email-masked]
Subject: Re: [core] Do we need a CORE charter item for CoAP support of Sleepy Nodes?

Dear all,

cheers
Sye Loong
________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]] on behalf of Rahman, Akbar [[email-masked]]
Sent: Thursday, August 01, 2013 6:02 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [core] Do we need a CORE charter item for CoAP support of Sleepy Nodes?
Hi,

*         Should we have a CORE deliverable for CoAP support of Sleepy Nodes?

Best Regards,

Akbar

---

From: Pierpaolo Giacomin <[email-masked]>
Date: Sun, 04 Aug 2013 23:26:39 +0300

> I do think we should have in CORE a deliverable for CoAP support of

+1

---

From: peter van der Stok <[email-masked]>
Date: Mon, 05 Aug 2013 08:35:20 +0200

In contrast to the earlier mails I am personally not convinced we should 
do (much) work on sleepy nodes.
In the simplest level 3 communication case, a sleepy node needs 
intialization of operational parameters, is switched on, and sends 
regularly data to an IP address.
More specifically, the IP address can be an MPL multicast address.
Anything more complex needs to be done with a proxy.
In my opinion SDOs like OMA, ZigBee, or BACnet, etc. have very different 
opinions on what such a proxy should do and how to communicate between 
the sleepy node an the proxy. They are best positioned to define the 
proxy in the context of their organization.

In the limit, at IETF, we just need to define a MIB for the 
initialization of the sleepy node.
If we want to do more, I think the draft by Matthieu Vial covers the 
case quite adequately.

Peter van der Stok

---

From: "Mani, Mehdi" <[email-masked]>
Date: Mon, 5 Aug 2013 13:05:26 +0000

+1
-Mehdi

From: [email-masked] [mailto:[email-masked]] On Behalf Of Keoh, Sye Loong
Sent: vendredi 2 août 2013 21:03
To: Rahman, Akbar; [email-masked]
Subject: Re: [core] Do we need a CORE charter item for CoAP support of Sleepy Nodes?

Dear all,

cheers
Sye Loong

Best Regards,

Akbar

---

From: Zach Shelby <[email-masked]>
Date: Mon, 5 Aug 2013 17:43:01 +0300

I agree with Peter, and am also skeptical about this work item as it has been discussed so far. 

This is really a problem that needs to be solved within a complete architecture, and we don't really have that architecture here. Other SDOs have or are solving this problem using CoRE mechanisms, for example OMA Lightweight M2M already includes simple sleep (or in general non-reachable CoAP endpoint support) using RD and queueing at a proxy. Not to mention other L2 mechanisms or application layer designs that already solve the problem. 

If we would like to document a setup to support such endpoints, then it should probably done by just documenting something done in a complete architecture for the sake of allowing re-use. We also have existing solutions like Mirror Server that can be used in some cases where that architecture is applicable. Inventing new solutions outside a full architecture and real deployments needs seems like research to me. 

Finally, we just have way too much work on our plate right now in CoRE to even think about taking more on. First, we need to ship Observe and Block to the IESG (and through the whole process), then we have three other work items we've just started on. I would think it is not time to discuss something new until we're pretty stable with those three (close to shipping them e.g.). Taking sleep work on now would just distract us from making progress. 

Zach

On Aug 5, 2013, at 9:35 AM, peter van der Stok <[email-masked]> wrote:

> In contrast to the earlier mails I am personally not convinced we should do (much) work on sleepy nodes.
> In the simplest level 3 communication case, a sleepy node needs intialization of operational parameters, is switched on, and sends regularly data to an IP address.
> In my opinion SDOs like OMA, ZigBee, or BACnet, etc. have very different opinions on what such a proxy should do and how to communicate between the sleepy node an the proxy. They are best positioned to define the proxy in the context of their organization.
> 
> In the limit, at IETF, we just need to define a MIB for the initialization of the sleepy node.
> If we want to do more, I think the draft by Matthieu Vial covers the case quite adequately.
> 
> Peter van der Stok
> 
> 
> 

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com @SensinodeIoT
Mobile: +358 40 7796297
Twitter: @zach_shelby
LinkedIn: http://fi.linkedin.com/in/zachshelby
6LoWPAN Book: http://6lowpan.net

---

From: Robert Cragie <[email-masked]>
Date: Mon, 05 Aug 2013 18:44:02 +0100

I agree too with what Zach and Peter say. Sleepy nodes have to be 
considered vertically through the stack so it goes beyond the reach of 
what is being done in CoRE. As mentioned in Berlin, there are two drafts 
in LWIG which look at the problem from an implementation standpoint 
across all layers as opposed to a protocol standpoint at a specific layer:

http://datatracker.ietf.org/doc/draft-hex-lwig-energy-efficient/
http://datatracker.ietf.org/doc/draft-hong-lwig-sleepynode-problem-statement/

Robert

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Tue, 6 Aug 2013 13:13:22 +0000

> considered vertically through the stack so it goes beyond the reach of what is
> being done in CoRE.

For a CoAP endpoint there are basically two ways to enable sleep:
1) Sleeping is managed transparently through the network stack and the application does not need to care ("radio duty cycling")
2) The application actively controls when to sleep, usually for longer periods ("sleepy nodes")

For the latter case, the application layer requires infrastructure support along the lines of draft-vial-core-mirror-server or draft-fossati-core-publish/-monitor-option (basically advanced cache control).

Zach has a valid point, though, that the WG currently has enough to do. However, this advanced cache control should be kept in mind...

Ciao
Matthias

---

From: Rick Bullotta <[email-masked]>
Date: Tue, 6 Aug 2013 13:42:52 +0000

Would it be more accurate for #2 to state that the application actively controls when to *wake*? Small but important semantic difference.

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Tue, 6 Aug 2013 14:47:40 +0000

> Would it be more accurate for #2 to state that the application actively controls
> when to *wake*? Small but important semantic difference.

Well, I meant the full cycle, when to sleep, when to wake, and for each how long.

> >> considered vertically through the stack so it goes beyond the reach
> >> of what is being done in CoRE.
> >
> > 1) Sleeping is managed transparently through the network stack and the
> > application does not need to care ("radio duty cycling")
> > For the latter case, the application layer requires infrastructure support along
> the lines of draft-vial-core-mirror-server or draft-fossati-core-publish/-monitor-
> option (basically advanced cache control).
> >
> > Zach has a valid point, though, that the WG currently has enough to do.
> However, this advanced cache control should be kept in mind...
> >
> > Ciao
> > Matthias
> >

---

From: "Rahman, Akbar" <[email-masked]>
Date: Tue, 6 Aug 2013 13:41:13 -0400

Hi Zach,

Thanks to you and all the WG for the good debate on this topic.  I
think, Zach, that you touched on the right compromise with your
following statement

	"If we would like to document a setup to support such endpoints,
then it should probably done by just documenting something done in a
complete architecture 	for the sake of allowing re-use. We also have
existing solutions like Mirror Server that can be used in some cases
where that architecture is applicable..."

I agree.  The missing link though is that need to identify a new WG
deliverable for CoAP support of Sleepy Node for this (hence my initial
Email). We have NOT yet adopted the Mirror Server (or any of the other
proposals) for Sleepy Node support.  We need to do this or otherwise we
will be delivering a set of CoAP standards to the market with an
important functionality/guidance that is missing (i.e. Sleepy Node
support).  I think we as a WG recognized this when we formulated the
initial charter as we explicitly refer to support of "sleepy nodes" in
the charter several times.

Best Regards,

Akbar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Zach Shelby
Sent: Monday, August 05, 2013 10:43 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [core] Do we need a CORE charter item for CoAP support
ofSleepy Nodes?

I agree with Peter, and am also skeptical about this work item as it has
been discussed so far. 

This is really a problem that needs to be solved within a complete
architecture, and we don't really have that architecture here. Other
SDOs have or are solving this problem using CoRE mechanisms, for example
OMA Lightweight M2M already includes simple sleep (or in general
non-reachable CoAP endpoint support) using RD and queueing at a proxy.
Not to mention other L2 mechanisms or application layer designs that
already solve the problem. 

If we would like to document a setup to support such endpoints, then it
should probably done by just documenting something done in a complete
architecture for the sake of allowing re-use. We also have existing
solutions like Mirror Server that can be used in some cases where that
architecture is applicable. Inventing new solutions outside a full
architecture and real deployments needs seems like research to me. 

Finally, we just have way too much work on our plate right now in CoRE
to even think about taking more on. First, we need to ship Observe and
Block to the IESG (and through the whole process), then we have three
other work items we've just started on. I would think it is not time to
discuss something new until we're pretty stable with those three (close
to shipping them e.g.). Taking sleep work on now would just distract us
from making progress. 

Zach

> In my opinion SDOs like OMA, ZigBee, or BACnet, etc. have very
different opinions on what such a proxy should do and how to communicate
between the sleepy node an the proxy. They are best positioned to define
the proxy in the context of their organization.
case quite adequately.
>> year ago, and the 4 individual submissions (if I am not wrong there 
>> are also a couple of the expired drafts on the topic) on the same 
>> subject listed by Akbar is a clear sign of interest and energy to 
>> work on it cheers /Sal
>> --
>> Salvatore Loreto, PhD
>> www.sloreto.com
>> Carsten asked me to send this message out to the WG list as we did 
>> not have a chance to discuss the Sleepy Node topic in this IETF due 
>> to a lack of time on the agenda.
>> ---------------------------------------------------------------------
>> --------- We have several current I-Ds in CORE (and LWIG) that 
>> discusses the topic of Sleepy Nodes. Among those are:
>> *Should we have a CORE deliverable for CoAP support of Sleepy Nodes?

---

From: Alessandro Bassi <[email-masked]>
Date: Fri, 2 Aug 2013 18:59:12 +0200

+1

--alex

Sent from my iPad

---

From: Zach Shelby <[email-masked]>
Date: Tue, 6 Aug 2013 23:40:39 +0300

On Aug 6, 2013, at 8:41 PM, "Rahman, Akbar" <[email-masked]> wrote:

> where that architecture is applicable…"

And in particular I meant we should document complete-architecture solutions used by other SDOs or in deployments as a way to re-use known mechanisms being used to solve real problems, rather than inventing neat solutions because we can. 

> the charter several times.

Sure, but let's look at this when we have time in the WG. The carrot is the faster we get current work off our plate, the faster we get to new work items. So let's get to WG draft reviews and tickets…. 

Zach

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 7 Aug 2013 08:02:07 +0200

On Aug 6, 2013, at 22:40, Zach Shelby <[email-masked]> wrote:

> let's get to WG draft reviews and tickets…. 

<donning WG chair hat>

Yes, please!

</>

Grüße, Carsten

---

From: "Dijk, Esko" <[email-masked]>
Date: Tue, 27 Aug 2013 08:49:28 +0000

> Sure, but let's look at this when we have time in the WG. The carrot is the faster we get current work off our plate, the faster we get to new work items. So let's get to WG draft reviews and tickets....

Agree there's quite some open work items currently. However that should not stop us from picking up a new topic, if the consensus is that this new topic is more important, or more urgently required, than the ones on the plate right now!  (But it seems this has been decided now not in favor of the 'sleepy' topic.)

For the coming time (if time permits) I'll have a first look at 'sleepy' requirements and the proposed solutions, to see how these compare.

Esko

---

From: "Rahman, Akbar" <[email-masked]>
Date: Wed, 28 Aug 2013 09:47:25 -0400

Hi Carsten,

I hope that you are having a nice summer.  As per the WG discussion
during Berlin IETF, I am sending this reminder (as per your suggestion)
for a personal chair review of the Group Communication draft:

http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/

My understanding was that we would start WGLC after we address any
comments that you may have.

Best Regards,

Akbar