Subject: [core] Tr : New Version Notification for draft-vial-core-mirror-proxy-00.txt

From: [email-masked]
Date: Fri, 2 Mar 2012 14:09:40 +0100

Hello all,

Here is another draft dealing with sleepy devices.

I will be glad to read your comments and suggestions to improve the 
document.

Best regards,
Matthieu Vial

----- Réacheminé par Matthieu Vial/FR/Non/Schneider le 02/03/2012 14:01 
-----

[email-masked] 
02/03/2012 13:58

A
Matthieu Vial/FR/Non/Schneider@Europe
cc

Objet
New Version Notification for draft-vial-core-mirror-proxy-00.txt

A new version of I-D, draft-vial-core-mirror-proxy-00.txt has been 
successfully submitted by Matthieu Vial and posted to the IETF repository.

Filename:                 draft-vial-core-mirror-proxy
Revision:                 00
Title:                            CoRE Mirror Proxy
Creation date:            2012-03-02
WG ID:                            Individual Submission
Number of pages: 14

Abstract:
   This document introduces the concept of Mirror Proxy that enables
   sleeping devices to participate in a REST architecture despite the
   fact that they are not web servers.  Most constrained devices may
   sleep during long periods preventing them from acting as traditional
   web servers.  However as client-only endpoints they can rely on a
   Mirror Proxy to cache and serve the content they provide.

The IETF Secretariat

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
______________________________________________________________________

---

From: Jari Arkko <[email-masked]>
Date: Fri, 02 Mar 2012 16:16:50 +0200

Matthieu,

I have read your draft. I like it, and would very much like to see something like this as a part of the outputs from this working group. Your draft is kind of a well-designed REST version of what we did in admittedly rather ad hoc manner in draft-arkko-core-sleepy-sensors.

I also like it that your interface is pretty much identical to the RD interface, making this easier to implement. Question: if I want to register myself in a RM *and* an RD (which might potentially be in the same server), is there a way for me to send just one set of messages, or do I have to register twice?

A couple of comments on your open questions:

>     We need a way to identify a SEP registered in multiple proxies as a
>     single entity.  Otherwise clients may have a wrong view of the
>     available services during resource discovery.  The duplicate
>     resources are indeed seen as new devices.

I would suggest that there could be a "origin" identity carried in the registration (e.g., dev:mac:....) and that origin identity can be communicated through the RD to anyone who sees the resources. This allows whoever is interested in the content to at least detect the duplicate resources as such.

>
>     We need a simple mechanism to define allowed methods on mirrored
>     resources that is independant of the resource profile.  A second
>     Interface Description attribute with the CRUD letters might work.

I have no comment on this yet.

>     We may add a CoAP option that would permit a MP to indicate in a
>     response that a client has updated another writable resource in the
>     cache for the requesting SEP.  This would gives better response time
>     than polling.

Hmm. I think this needs further thought. Is there a way to ask "give me a list of my resources that have changed since yesterday"?

>
>     When a SEP registers with multiple MP and each MP reuses the same
>     SEP's name to register with the RD, the resource directory entry
>     might be overwritten.  We need to figure out what piece of
>     information is the handler for a resource directory entry in a RD
>     database.

We have some ideas on this front... stay tuned.

>
>       6.1. Extensions
>
>
>
>     Implicit registration could be useful for highly constrained SEP that
>     don't have enough energy to maintain soft state in a MP.  Like the
>     proposition in [I-D.arkko-core-sleepy-sensors  <http://tools.ietf.org/html/draft-vial-core-mirror-proxy-00#ref-I-D.arkko-core-sleepy-sensors>], we could use a
>     multicast address to infer a resource type.  Alternatively we could
>     allow explicit registration from a third-party endpoint.
>

For what it is worth, we took our implementation to the extreme limit. It is necessary to be able to create simple and power efficient devices, but there may be a reasonable limit that we do not have to cross. I think a constrained device can support a registration phase. The only problem that I have with registration phases is the issue that we experienced with coap-observe: we cannot assume that only one entity is interested in our results, we don't know when the addressing plan of the site changes,  and we don't want to stay on all the time in case someone re-registers (as a server) or poll continuously if there's a new register that we must register to (as a client). If those problems can be overcome for a RM function, then I'm fine with programming a discovery and registration mechanism into my devices.

Jari

---

From: [email-masked]
Date: Fri, 2 Mar 2012 17:54:53 +0100

Jari,

Thanks for your interest in the draft. See my comments below.

>I also like it that your interface is pretty much identical to the RD 
interface, making this easier to implement. Question: if I want to 
register myself in a RM *and* an RD (which might potentially be in the 
same server), is there a way for me to send just one set of messages, or 
do I have to register twice?

For me a sleeping endpoint is not supposed to register with a RD. The 
mirror proxy can do it on its behalf if RD discovery is administratively 
configured in the network. When the RD and the MP are located on the same 
web server we can imagine internal optimizations to populate the RD 
database. Also by default the RD extracts the source address of the 
registration packet to get the address of the web server. A SEP is not a 
web server so it would have to explicitly specify the address of the MP in 
the registration request. It's just added complexity for a SEP and it's 
also less energy efficient.

>I would suggest that there could be a "origin" identity carried in the 
registration (e.g., dev:mac:....) and that origin identity can be 
communicated through the RD to anyone who sees the resources. This allows 
whoever is interested in the content to at least detect the duplicate 
resources as such.

The question is how to attach this identity to the web links returned 
during resource discovery.

>I think a constrained device can support a registration phase.

Depending on the energy harvesting technology, some devices might not be 
able to send periodic requests to maintain soft state or to start a 
complex registration procedure (link-format is quite verbose). A switch 
may collect energy from the movement of the rocker for example. In that 
case the SEP can only communicate when the switch is activated.

Matthieu

---

From: Jari Arkko <[email-masked]>
Date: Fri, 02 Mar 2012 20:27:37 +0200

Matthieu:

> For me a sleeping endpoint is not supposed to register with a RD.

OK. That makes sense. So when the MP is register itself with an RD, it does so to register the mirrored resources, not the original client.

>   The

Yes. In any case, what is important for me is that I don't have to use multiple message rounds just to do both directory and mirroring; I just do one thing and the mirror takes care of directories for me.

> during resource discovery.

As a separate attribute? (But I haven't looked at the details...)

> case the SEP can only communicate when the switch is activated.

Yes. I think registration phase is probably OK, periodic soft state maintenance.... might not be. But it depends on the timings, too. And those timings have real-world trade-offs on how well you can not just save power but also deal with changes and problems. The issue is that once something changes, you do not want wait for a month for all of your devices to  re-register, if the soft state maintenance timers were set to a month to save power.

Jari

---

From: Zach Shelby <[email-masked]>
Date: Fri, 2 Mar 2012 21:28:56 +0200

> As a separate attribute? (But I haven't looked at the details...)

Actually I have already considered including in the RD draft an id= attribute that allows you to associate a unique identifier (e.g. dev-urn) with an end-point. Would be happy to include that in the RD registration interface if people find that useful. 

Zach 

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: [email-masked]
Date: Mon, 5 Mar 2012 15:32:12 +0100

>Actually I have already considered including in the RD draft an id= 
attribute that allows you to associate a unique identifier (e.g. dev-urn) 
with an end-point. Would be happy to include that in the RD registration 
interface if people find that useful. 

I'm worried about the length of the payload if the identifier is repeated 
for each link.

<coap://[aaaa::ff:fe00:0001]/mp/0/dev/>;rt="profile:dev";if="core#p";id="
urn:dev:mac:0024befffe804ff1",

Matthieu

---

From: Zach Shelby <[email-masked]>
Date: Mon, 5 Mar 2012 17:27:02 +0200

> urn:dev:mac:0024befffe804ff1",

I agree, which is why I wasn't suggesting putting it in the link. Instead, id= would be associated to the end-point and passed to the RD only during the initial registration. So:

POST /rd?h=powernode-005&id=urn:dev:mac:0024befffe804ff1

Now I think you might be referring to the links that an RD returns as a result of a lookup. I agree, it would be inefficient to repeat that for each resource link. I think there should be a way to return a link to the end-point itself, where such end-point specific information can be returned (e.g. id=). This could be done by providing an additional REST interface for looking up end-points rather than resources.

Zach

---

From: [email-masked]
Date: Mon, 5 Mar 2012 18:05:22 +0100

>Now I think you might be referring to the links that an RD returns as a 
result of a lookup. I agree, it would be inefficient to repeat that for 
each resource link. 

Exactly.

>I think there should be a way to return a link to the end-point itself, 
where such end-point specific information can be returned (e.g. id=). This 
could be done by providing an additional REST interface for looking up 
end-points rather than resources.

When a sleeping endpoint registers with 2 mirror proxies, we've got 2 
endpoints in the RD database for the same id attribute. Also the proxy 
shares its endpoint with the registered sleeping nodes.
If I'm following your idea the right way, the new interface might return 
something like below (don't pay too much attention to the attribute 
format, could be something else)

GET /rd/new_interface
</rd/1>;ep="coap://[aaaa::ff:fe00:0001]/";h="proxy1";id="urn:dev:mac:0024befffe804f01",
</rd/2>;ep="coap://[aaaa::ff:fe00:0001]/";h="proxy1";ins="sleepy";id="urn:dev:mac:0024befffe804f03",
</rd/3>;ep="coap://[aaaa::ff:fe00:0002]/";h="proxy2";id="urn:dev:mac:0024befffe804f02",
</rd/4>;ep="coap://[aaaa::ff:fe00:0002]/";h="proxy2";ins="sleepy";id="urn:dev:mac:0024befffe804f03",

I still don't know how to relate the previous result with a resource 
lookup like:

GET /rd/rt=Temperature
<coap://[aaaa::ff:fe00:0001]/temp>;rt="Temperature";if="sensor"
<coap://[aaaa::ff:fe00:0001]/mp/0/temp>;rt="Temperature";if="sensor"
<coap://[aaaa::ff:fe00:0002]/temp>;rt="Temperature";if="sensor"
<coap://[aaaa::ff:fe00:0002]/mp/0/temp>;rt="Temperature";if="sensor"

Lines 2 and 4 are actually the same sensor mirrored on 2 proxies.

We might extend the Context parameter in the registration interface to 
accept a root path. We would have then:

GET /rd/new_interface
</rd/1>;ep="coap://[aaaa::ff:fe00:0001]/";h="proxy1";id="urn:dev:mac:0024befffe804f01",
</rd/2>;ep="coap://[aaaa::ff:fe00:0001]/mp/0";h="proxy1";ins="sleepy";id="urn:dev:mac:0024befffe804f03",
</rd/3>;ep="coap://[aaaa::ff:fe00:0002]/";h="proxy2";id="urn:dev:mac:0024befffe804f02",
</rd/4>;ep="coap://[aaaa::ff:fe00:0002]/mp/0";h="proxy2";ins="sleepy";id="urn:dev:mac:0024befffe804f03",

But it's still quite complex for a client to deduplicate the links.

Adding the identifier to each link is not efficient but should work with 
both RD and /.w-k/core.

Matthieu

---

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

Thanks Matthieu,

interesting that you mention the response suppression option ("Suppr-Rsp"), which was discussed before on the CoRE list.
Would you be interested to contribute to a short I-D about such CoAP option? It may be useful for multiple purposes.

Although now in coap-09 there is additional text on CoAP response suppression (for the multicast case), where each CoAP server decides whether to respond or not, an explicit signaling from the client may be useful for certain use cases or to improve on some interoperability/upgradability aspects of larger CoAP systems.

A response suppression option could use a bitmask to signal the clients preferences, e.g.:

bit 0: Suppress all 2.xx success responses
bit 1: Suppress all 4.xx client errors
bit 2: Suppress all 5.xx server errors
bit 3: Suppress all query responses with a size zero result set (if bit NOT set, don't suppress empty result sets!)
bit 4: (Suppress payload in response ?)

Any combination of the previous items is thus possible. All bits clears means follow CoAP protocol defaults and the server's defaults.

Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday 2 March 2012 14:10
To: core WG
Subject: [core] Tr : New Version Notification for draft-vial-core-mirror-proxy-00.txt

Hello all,

Best regards,
Matthieu Vial

[email-masked]
02/03/2012 13:58

A

Objet

Abstract:

The IETF Secretariat

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

________________________________
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: "Dijk, Esko" <[email-masked]>
Date: Thu, 22 Mar 2012 10:53:52 +0000

> Hmm. I think this needs further thought. Is there a way to ask "give me a list of my resources that have changed since yesterday"?

Agree! This could be the way to go if we do not want to define another CoAP Option. It could be "give me a list of my resources that have changed since last time I checked". That seems far more scalable than a SEP polling all its resources for changes. If there's no change the SEP can quickly go to sleep again.

One way for the SEP to query the MP for this could be like this (just an ad-hoc query syntax here...):
        GET /mp/0?change

MP responds with:
        2.05 Content
        Content-Type: application/link-format
        </mp/0/dev/n>,</mp/0/some/writable/path>

where the default rel="hosts" relation is used, though it might be another (rel="updated" ??)
The SEP has to parse these link-format descriptions, but in general link-format parsing was already part of the specified SEP behavior in this draft.

Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jari Arkko
Sent: Friday 2 March 2012 15:17
To: [email-masked]
Cc: core WG
Subject: Re: [core] Tr : New Version Notification for draft-vial-core-mirror-proxy-00.txt

Matthieu,

Jari