Subject: [core] sleepy nodes

From: peter van der Stok <[email-masked]>
Date: Tue, 15 Oct 2013 13:49:26 +0200

Dear all,

reading the draft on the need for sleepy nodes by Akbar, I become more 
convinced that the subject is not right for IETF.
Already defining a sleepy node is fraught with application oriented 
aspects.
Taking the advice of Zach, that you only want to define a proxy leaves 
also many possibilities open, like:

Does the sleepy node communicate only with the proxy?
Can the sleepy node send to other nodes than the proxy via multicast or 
unicast?
Does the sleepy node need maintenance?
Is the sleepy node initialized at the factory and it never listens to 
any messages afterwards?
Or is there an initialization capability, eventually supported by a 
battery recharge.

I can go on and on like this, (for example on timing constraints) and 
none of the questions will get satisfactory unanimous answers.
Therefore, I remain with my conclusion that sleepy nodes are interesting 
but too much conditioned by application constraints to define a proxy 
approach that is generally applicable.

If anything needs to be done I still think that the "mirror server" 
draft is the best choice because I recognize the boundary conditions.
But the latter is a very application biased opinion.

Peter

-- 
Peter van der Stok
mailto: [email-masked]
www: www.vanderstok.org
tel NL: +31(0)492474673     F: +33(0)966015248

---

From: "weigengyu" <[email-masked]>
Date: Wed, 16 Oct 2013 10:43:52 +0800

Hi, perter,

"Taking the advice of Zach, that you only want to define a proxy leaves
also many possibilities open, like: ...... "

Could you give further explanations about the proxy.
Is the proxy a resource constrained node?

Regards,

Gengyu

-----原始邮件----- 
From: peter van der Stok
Sent: Tuesday, October 15, 2013 7:49 PM
To: Core ; akbar rahman
Subject: [core] sleepy nodes

Dear all,

Peter

-- 
Peter van der Stok
mailto: [email-masked]
www: www.vanderstok.org
tel NL: +31(0)492474673     F: +33(0)966015248
_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: peter van der Stok <[email-masked]>
Date: Wed, 16 Oct 2013 14:46:03 +0200

Hi Gengyu,

Zach made a proposal what the proxy could look like.
For me the proxy probably is not "too much" resource constrained.
The Resource directory or the router may make an excellent host.
But I can also see manufacturers selling them in any form they like.

Greetings,

Peter

weigengyu schreef op 2013-10-16 04:43:
> -----原始邮件----- From: peter van der Stok

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 16 Oct 2013 14:12:09 +0000

Dear Peter,

not sure all you mentioned below are strictly application oriented aspects.

I still feel we lack in core some general mechanism to handle the case
(intermittent nodes it is really more general and better then sleeping one)  in an standard way…
it can be as simple as the one defined in OMA lightweight standard
(i.e. a RD registration parameter used to indicate a node in a queue mode)

but at least we need a standard mechanism that let the client recognise "the node is trying to reach
is not available…" and how it should behave if it really want to contact it

Salvatore

On Oct 15, 2013, at 2:49 PM, peter van der Stok <[email-masked]> wrote:

> 
> Dear all,
> 
> 
> reading the draft on the need for sleepy nodes by Akbar, I become more convinced that the subject is not right for IETF.
> Already defining a sleepy node is fraught with application oriented aspects.
> Taking the advice of Zach, that you only want to define a proxy leaves also many possibilities open, like:
> 
> Can the sleepy node send to other nodes than the proxy via multicast or unicast?
> Is the sleepy node initialized at the factory and it never listens to any messages afterwards?
> Or is there an initialization capability, eventually supported by a battery recharge.
> 
> 
> I can go on and on like this, (for example on timing constraints) and none of the questions will get satisfactory unanimous answers.
> Therefore, I remain with my conclusion that sleepy nodes are interesting but too much conditioned by application constraints to define a proxy approach that is generally applicable.
> 
> If anything needs to be done I still think that the "mirror server" draft is the best choice because I recognize the boundary conditions.

---

From: peter van der Stok <[email-masked]>
Date: Wed, 16 Oct 2013 17:24:33 +0200

Hi Salvatore,

with application oriented read also: manufacturer- or consortium of 
manufacturers oriented.

I see your point that it is useful to recognize during discovery that 
the device exists, has an IP address, but reacts funny.
On the other hand, one can decide to make the "intermittent node" 
invisible in the discovery process, and discover the proxies instead.
Next question, do we need to recognize that these are proxies?
I would argue that depends on the application and the way the proxy is 
constructed. It probably has to do with the validity of the returned 
values.
However, the "intermittent node" should not respond to any query, any 
time (be truly invisible) unless it is the proxy that queries it.

would that be reasonable?

Peter

Salvatore Loreto schreef op 2013-10-16 16:12:
> Therefore, I remain with my conclusion that sleepy nodes are 
> interesting but too much conditioned by application constraints to 
> define a proxy approach that is generally applicable.
>

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 16 Oct 2013 18:03:09 +0000

On Oct 16, 2013, at 6:24 PM, peter van der Stok <[email-masked]>
 wrote:

> Hi Salvatore,
> 
> with application oriented read also: manufacturer- or consortium of manufacturers oriented.
> 
> I see your point that it is useful to recognize during discovery that the device exists, has an IP address, but reacts funny.
> On the other hand, one can decide to make the "intermittent node" invisible in the discovery process, and discover the proxies instead.

> I would argue that depends on the application and the way the proxy is constructed. It probably has to do with the validity of the returned values.

exactly it should be at least possible to discriminate the fact that the resource you discovered is hosted by the proxy
but belong to some other node (i.e. the value you read on the node is not fresh etc.etc)

and also how you configure an intermittent node so that its resource can be hosted by a Proxy, etc. etc.

The way you are describing Proxy appears to me more as a Server hosting a resource that is updated by magic 

> However, the "intermittent node" should not respond to any query, any time (be truly invisible) unless it is the proxy that queries it.
> 

no an intermittent node is special only in the sense that is not reachable all the time (the reason can be different, it's sleeping, it is behind a NAT
etc) but for the rest it should be equal to the other sensors.

br
/Sal