Subject: Re: [core] pubsub and sleepy node proxy

From: "Rahman, Akbar" <[email-masked]>
Date: Thu, 3 Sep 2015 04:45:45 +0000

Hi Peter,

I am still reading the pubsub draft, but did want to give support for your sleepy node draft (draft-zotti-core-sleepy-nodes-03).  The sleepy node proxy concept that you describe will be useful in many scenarios.  One related comment that I did have on your draft is that it seems a bit fixated on the 6LoWPAN scenario.  But as we have discussed many times during IETF meetings and on various mailing lists, the sleepy node scenario is useful beyond 6LoWPAN deployments (e.g. https://tools.ietf.org/html/draft-arkko-core-sleepy-sensors-01 ).    So I think it would be useful if you clarified that in your draft.

Best Regards,

Akbar

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of peter van der Stok
Sent: Monday, August 31, 2015 3:06 AM
To: Michael Koster <[email-masked]>; Core <[email-masked]>
Subject: [core] pubsub and sleepy node proxy

Hi Michael,

Looking at the pubsub draft and at our sleepy node proxy draft, I come to the conclusion that there are good arguments to maintain both.

Following the reasoning of Matthieu Vial, there are already a good arguments for the sleepy node (SN) proxy (aka mirror server) to exist next to the RD.
Namely:
Where an end-point can delegate its links to the RD for discovery, an end-point can delegate the links AND the associated resource values to the SN-proxy.
The SN-proxy resources have the same lifetime as SN resources.
The SN-proxy resource values are directly linked to the resources of a given SN.

In contrast the pubsub handles anonymous values. The origin can be added but that means adding attributes to the topics.
The pubsub handles the more abstract topics, where the SN-proxy is concerned with the resources.
The lifetime of the values in the pubsub server is not directly linked to the lifetime of the originating resources.

For me these are the arguments that motivate the existence of the pubsub draft next to the sleepy node draft.

Looking forward to your reaction.

Greetings
Teresa and Peter

_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: peter van der Stok <[email-masked]>
Date: Fri, 04 Sep 2015 15:49:56 +0200

Hi Akbar,

thanks for your support.
I once read the draft you mentioned, but forgot about it.

I will return with some suggestions later next week,

Peter

Rahman, Akbar schreef op 2015-09-03 06:45:
> Hi Peter,
> 
> 
> I am still reading the pubsub draft, but did want to give support for
> your sleepy node draft (draft-zotti-core-sleepy-nodes-03).  The sleepy
> node proxy concept that you describe will be useful in many scenarios.
>  One related comment that I did have on your draft is that it seems a
> bit fixated on the 6LoWPAN scenario.  But as we have discussed many
> times during IETF meetings and on various mailing lists, the sleepy
> node scenario is useful beyond 6LoWPAN deployments (e.g.
> https://tools.ietf.org/html/draft-arkko-core-sleepy-sensors-01 ).
> So I think it would be useful if you clarified that in your draft.
> 
> 
> Best Regards,
> 
> 
> Akbar
> 
> Looking at the pubsub draft and at our sleepy node proxy draft, I come
> to the conclusion that there are good arguments to maintain both.
> 
> Following the reasoning of Matthieu Vial, there are already a good
> arguments for the sleepy node (SN) proxy (aka mirror server) to exist
> next to the RD.
> Namely:
> Where an end-point can delegate its links to the RD for discovery, an
> end-point can delegate the links AND the associated resource values to
> the SN-proxy.
> In contrast the pubsub handles anonymous values. The origin can be
> added but that means adding attributes to the topics.
> The lifetime of the values in the pubsub server is not directly linked
> to the lifetime of the originating resources.
> 
> For me these are the arguments that motivate the existence of the
> pubsub draft next to the sleepy node draft.
>

---

From: peter van der Stok <[email-masked]>
Date: Wed, 09 Sep 2015 12:18:56 +0200

Hi Akbar,

After reading the arkko-core-sleepy draft I do have some concrete 
questions for you:

Do you want the following additions to the proxy:
- a http endpoint
- storage of historical values
- numbering of messages by sleepy node to estimate the reliability and 
to order them
- Use of NON messages from sleepy to proxy

In the arkko draft there is considerable motivation of design choices. 
Do you want more design motivation in the our zotti-core-sleepy draft?

Is there anything specific I did not pick up?

Thanks for your reaction,

Peter

---

From: "Rahman, Akbar" <[email-masked]>
Date: Thu, 17 Sep 2015 16:36:50 +0000

Hi Peter,

I'm sorry for the delayed response.  Somehow I missed this in my Inbox and only noticed it when I was going over the reflector mailing list records.  My specific suggestions are:

- Yes, it will be good to give more design motivation in your draft.

- Eliminate the tight dependence to 6LoWPAN technology as it is a CoAP application protocol and can be run on any underlying IP network.  I'm not sure if your main motivation for the 6LoWPAN link was due to your L2 security assumptions in Section 9.  But it seems like an artificially restrictive dependence.

- The link to the PubSub server (section 7) looks tenuous and not that convincing to me.

- Editorial - The arrows between the Proxy and Sleepy Node are all 1 directional in Figure 1.  But I understood from the text that, for example, WRITE, should be a bi-directional between Proxy and Sleepy Node (i.e. a WRITE from a Configuring node to the Proxy node should ultimately result in a WRITE to the sleepy node from the Proxy).  Did I understand correctly?

Thanks for the good work.

Akbar

-----Original Message-----
From: peter van der Stok [mailto:[email-masked]]
Sent: Wednesday, September 09, 2015 6:19 AM
To: Rahman, Akbar <[email-masked]>
Cc: [email-masked]; Michael Koster <[email-masked]>; Core <[email-masked]>
Subject: RE: [core] pubsub and sleepy node proxy

Hi Akbar,

After reading the arkko-core-sleepy draft I do have some concrete questions for you:

Do you want the following additions to the proxy:
- a http endpoint
- storage of historical values
- numbering of messages by sleepy node to estimate the reliability and to order them
- Use of NON messages from sleepy to proxy

Peter

---

From: peter van der Stok <[email-masked]>
Date: Tue, 22 Sep 2015 11:59:42 +0200

Hi Rahman,

thanks for the concrete suggestions, see below

Rahman, Akbar schreef op 2015-09-17 18:36:
> Hi Peter,
> 
> I'm sorry for the delayed response.  Somehow I missed this in my Inbox
> and only noticed it when I was going over the reflector mailing list
> records.  My specific suggestions are:
> 
<pvds>
will think about this
</pvds>
> 
> - Eliminate the tight dependence to 6LoWPAN technology as it is a CoAP
> application protocol and can be run on any underlying IP network.  I'm
> not sure if your main motivation for the 6LoWPAN link was due to your
> L2 security assumptions in Section 9.  But it seems like an
> artificially restrictive dependence.
<pvds>
will look at it; has to do with the history of this work.
</pvds>
> - The link to the PubSub server (section 7) looks tenuous and not that
<pvds>
Fully agree, a more appropriate one has been done.
</pvds>
> 
> - Editorial - The arrows between the Proxy and Sleepy Node are all 1
> directional in Figure 1.  But I understood from the text that, for
> example, WRITE, should be a bi-directional between Proxy and Sleepy
> Node (i.e. a WRITE from a Configuring node to the Proxy node should
> ultimately result in a WRITE to the sleepy node from the Proxy).  Did
> I understand correctly?
<pvds>
Ehh, they are inter-actions. I suggest to remove the arrows
</pvds>
> Thanks for the good work.

thanks for the feedback,

Peter
> Cc: [email-masked]; Michael Koster
> <[email-masked]>; Core <[email-masked]>