Subject: Re: [core] Fwd: New Version Notification for draft-ietf-core-observe-01

From: Daniele Alessandrelli <[email-masked]>
Date: Tue, 1 Mar 2011 19:13:01 -0500

Hello,

I have read the draft and I think that the following statement in "4.4
Caching" is incorrect:
"The observation mechanism ensures that the cache has a fresh response
for most of the duration of the observation lifetime."

The freshness is determined by the Max-Age Option which can be much
smaller then the average time interval between notifications.
Therefore, if I am not missing something, the cache can have *no*
fresh response for most of the duration of the observation lifetime.

Regards

Daniele

On Mon, Feb 7, 2011 at 9:18 PM, Klaus Hartke <[email-masked]> wrote:
> A new version of draft-ietf-core-observe is now available:
>
> http://tools.ietf.org/id/draft-ietf-core-observe-01.txt
>
> All 15 tickets have been closed; see the change log in Appendix B
> for details. Almost all tickets were editorial: only one technical
> change was made to enable reordering detection (see Section 4.3).
>
> Feedback welcome.
>
> Klaus
>
>
> -------- Original Message --------
> Subject: New Version Notification for draft-ietf-core-observe-01
> Date: Mon,  7 Feb 2011 11:55:44 -0800 (PST)
> From: IETF I-D Submission Tool <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
>
>
> A new version of I-D, draft-ietf-core-observe-01.txt has been
> successfully submitted by Klaus Hartke and posted to the IETF
> repository.
>
> Filename:        draft-ietf-core-observe
> Revision:        01
> Title:           Observing Resources in CoAP
> Creation_date:   2011-02-07
> WG ID:           core
> Number_of_pages: 19
>
> Abstract:
> CoAP is a RESTful application protocol for constrained nodes and
> networks.  The state of a resource on a CoAP server can change over
> time.  This specification provides a simple extension for CoAP that
> gives clients the ability to observe such changes.
>
>
>
> The IETF Secretariat.
>
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Klaus Hartke <[email-masked]>
Date: Thu, 3 Mar 2011 16:58:49 +0100

> fresh response for most of the duration of the observation lifetime.

Good point. But the observation mechanism would be pretty useless if
it couldn't be used to keep a cache up to date. This should be fixed.

Klaus

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Fri, 4 Mar 2011 09:33:44 +0100

In Sec. 5.10.5 of coap-04 is written:

   The option value is an integer number of seconds between 0 and 2^32-1
   inclusive (about 136.1 years).  A default value of 60 seconds is
   assumed in the absence of the option in a response.

Max-Age is large enought in my opinion.

When a CoAP server is serving a subscription, it should send a new
notification when the previous notified value has expired.

When the server is including the Max-Age option, it can be set to an
arbitrary value and so I see no problem in it.

The problem, in my opinion, is in the current definition of default to
60 seconds.

When the Max-Age is not set, its default should be much higher (136.1
years?). Otherwise servers supporting subscription MUST support also
Max-Age and take care always to setting it to a value high enought to
reduce overhead and produce a new notification before the previous
expires.

Example: Permanent subscriptions with occasional changes, the Max-Age
mechanism seems an added complexity.
Sample use case: light bulb subscribed to the light switch.

Probably if Max-Age is not set, it should be assumed that the notified
value does not expire.

Defining that a Max-Age=0 means that the value does not expire, and
setting the default to 0 makes much more sense to me.

Best,
Angelo

---

From: Daniele Alessandrelli <[email-masked]>
Date: Fri, 4 Mar 2011 12:19:33 -0500

Yes, I think that using the observation mechanism to keep a proxy
cache up to date is pretty useless, but it is still useful for client
interested in resource changes, which, in my opinion, is the main
purpose of the observation mechanism.

---

From: "Dijk, Esko" <[email-masked]>
Date: Fri, 4 Mar 2011 18:35:44 +0100

Dear Daniele, Klaus,

although the current mechanism may not be suitable for keeping a proxy cache up to date, this may be fixed as Klaus indicated.

Klaus do you have a specific fix in mind? E.g. one option is for the cache (inside a CoAP intermediary) is to optionally keep a response always as 'fresh' as long as there is no update notification from the server (containing the Subject) to prove otherwise. Then even if the original Max-Age of the cached resource has expired, the CoAP intermediary may still serve the cached response to clients but with Max-Age set to zero, making it in turn non-cacheable.

This could provide an acceptable solution I think in the context of different use cases: unpredictable vs quasi-periodic resource state updates, frequent vs infrequent state updates, etc.

best regards,
Esko Dijk

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniele Alessandrelli
Sent: Friday 4 March 2011 18:20
To: Klaus Hartke
Cc: [email-masked]
Subject: Re: [core] Fwd: New Version Notification fordraft-ietf-core-observe-01

Esko Dijk

Philips Corporate Technologies, Research
High Tech Campus 34, Eindhoven, The Netherlands
[email-masked]

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: Daniele Alessandrelli <[email-masked]>
Date: Fri, 4 Mar 2011 13:09:03 -0500

Dear Dijk,

your solution is certainly a good start point, but I still see some problems.

What if the server sends notification using non-confirmable messages
and they are lost? Or if the server goes down? The proxy will still
consider the value fresh and a client will retrieve an old value
thinking that it is up-to-date.

In my opinion, if a client is using the observation mechanism, it is
aware of the these risks, while, if it using a GET request, it expects
a fresh value (or no value if the response is lost). One possible
solution is to let the client know the proxy policy about the
freshness of observed resources. What do you think?

Best regards,

Daniele

---

From: "Dijk, Esko" <[email-masked]>
Date: Mon, 7 Mar 2011 08:26:29 +0100

Dear Daniele,

I agree with the point that a client should not be 'mislead' that it receives a fresh value while in fact it does not. For this reason I had in mind to use the Max-Age Option with value 0 seconds as an indicator to mean something like "Max-Age expired, not really fresh anymore but response still being served due to absence of more recent updates".  Clients that do want fresh values could then include a Max-Age Option in their request to the intermediary along with the Proxy-Uri Option, to override the default intermediary behaviour.

But I now see a problem: a Max-Age of 0 seconds also means "server wishes to prevent resource being cached" so this value can't be safely re-used for the purpose described above. 

By the way the (cache efficiency) problem we discuss appears only in use cases where
	average(Max-Age values) << average(time interval between notifications) 
In the case of a sensor node, an implementer may choose to use higher Max-Age anyway, to avoid inefficiencies in the total system.

best regards,
Esko

-----Original Message-----
From: Daniele Alessandrelli [mailto:[email-masked]] 
Sent: Friday 4 March 2011 19:09
To: Dijk, Esko
Cc: Klaus Hartke; [email-masked]
Subject: Re: [core] Fwd: New Version Notification fordraft-ietf-core-observe-01

Dear Dijk,

Best regards,

Daniele

---

From: Likepeng <[email-masked]>
Date: Mon, 07 Mar 2011 08:07:24 +0000

I am not clear about one thing, who decide the time interval between the notifications? I assume that it is the proxy, or the server.

> By the way the (cache efficiency) problem we discuss appears only in use cases where	average(Max-Age values) << average(time interval between notifications)
I am wondering how the situation happens. If proxy finds out that the Max_Age is going to expire, the proxy should send notifications as soon as possible, then there will be no issue with that.

Kind Regards
Kepeng
-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Dijk, Esko
发送时间: 2011年3月7日 15:26
收件人: Daniele Alessandrelli
抄送: [email-masked]; Klaus Hartke
主题: Re: [core] Fwd: New Version Notification fordraft-ietf-core-observe-01

Dear Daniele,

best regards,
Esko

-----Original Message-----
From: Daniele Alessandrelli [mailto:[email-masked]] 
Sent: Friday 4 March 2011 19:09
To: Dijk, Esko
Cc: Klaus Hartke; [email-masked]
Subject: Re: [core] Fwd: New Version Notification fordraft-ietf-core-observe-01

Dear Dijk,

Best regards,

Daniele

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Mon, 7 Mar 2011 09:44:12 +0100

> I am not clear about one thing, who decide the time interval between the notifications? I assume that it is the proxy, or the server.

In my current understanding of observe mechanism the CoAP server
decides when a new representation of the resource resource is notified
to the client.

This is exactly the reason because I believe that if server correctly
implements the observe mechanism, the cache should have always a valid
value in it.

My opinion is that by default resource values do not expire.

When caching is applied to a resource value which has Max-Age not set,
the validity of that representation can either be:
a) the maximum possible for the cache;
b) upper bounded to a specified high value.

Given that servers should know which resource representations can
change, they have to set Max-Age to the highest value they can
guarantee for that resource.

When an observation is in progress on a resource and the last notified
value is going to expire, the server should actively update the cache
by sending a new notification.

If the server do not do the update or the notification is lost (NON
message), the cache will drop the expired representation and request a
new resource representation to it.

Best,
Angelo

---

From: Matthieu VIAL <[email-masked]>
Date: Mon, 7 Mar 2011 10:09:19 +0100

We could also resurrect the Max-Age option in a request to let a client 
control the maximum time between 2 notifications even if there is no 
change of state.

Matthieu

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Mon, 7 Mar 2011 10:16:17 +0100

> control the maximum time between 2 notifications even if there is no

+1 I like also this use of Max-Age.

So related to option b of my previous message a cache notifies its
Max-Age internal upper bound in this way.

Angelo

---

From: "Dijk, Esko" <[email-masked]>
Date: Mon, 7 Mar 2011 16:03:31 +0100

Dear Angelo and Matthieu,

> by sending a new notification.

This is a good way of keeping the cached resource fresh, though it extends the definition of Notification (as in observe-01) because this kind of 'expiration driven notification' is not necessarily a result of any state change of the resource. If we allow this use of Notifications, perhaps Section 4.1 could mention this as a possible strategy for a server implementation (MAY?).

> control the maximum time between 2 notifications even if there is no

This sounds like a useful option to have, though it raises some questions:
- it should be possible for the server to ignore the requested Max-Age?  (e.g. to avoid extra book-keeping per subscription which was discussed previously on the list)
- if ignored by the server, should the Observer be notified/made aware of this, or not?
- potentially confusing in naming because the meaning of the Max-Age Option in the server's response to the GET is entirely different?

My present conclusion on this topic is that, if we keep the current freshness model as is, the achieved cache performance necessarily depends on the value(s) of the Max-Age Option that the server decides to use in its responses. If e.g. the server by default uses 'infinite' Max-Age (i.e. Angelo's proposal for a default Max-Age) then caching is efficient. If the server decides to respond with Max-Age = 0 sec always, the cache won't cache anything in the current model.

best regards,
Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Angelo P. Castellani
Sent: Monday 7 March 2011 10:16
To: Matthieu VIAL
Cc: [email-masked]; [email-masked]; Klaus Hartke
Subject: Re: [core] Fwd: New Version Notificationfordraft-ietf-core-observe-01

Angelo

---

From: Daniele Alessandrelli <[email-masked]>
Date: Fri, 11 Mar 2011 01:54:51 -0600

Maybe it could be simpler to define two types of notification: change
notifications and periodic notifications. Change notifications will
work as currently specified in observe-01,
periodic notifications will work as follows:
- the client sends a periodic notification request (specifying a period value)
- the server sends a notification at the beginning of each period interval.

Change notifications will be used by clients interested in resource changes.
Periodic notifications will be used by proxies to keep their cache
up-to-date. They are also useful for applications (clients) requiring
a periodic monitoring of a resource (like a discrete-time control
system).

We can reuse the max-age option to specify the period, or we can
create a new option to avoid confusion.

---

From: Likepeng <[email-masked]>
Date: Fri, 11 Mar 2011 08:11:04 +0000

I don't think it is useful to define periodic notifications. It will add the burden to both proxy and sensor.

To keep the cache to be up-to-date, we can already use Max-Age to specify the freshness of the cache. 

I don’t think it is a useful feature to be added.

Kind Regards
Kepeng

---

From: Zach Shelby <[email-masked]>
Date: Fri, 11 Mar 2011 14:01:38 +0200

Daniele,

> - the server sends a notification at the beginning of each period interval.

Does this really need to be part of the observe mechanism itself? In the last interim meeting we agreed to try to reduce the state needed for observations. 

While first starting to design observe, we went through many discussions about all the cool things we might want to do with observation. Periods, thresholds and averaging just to mention a few. At that time we decided to leave such possible features to the server. This is the reason it is up to a server to determine what change means. Change could mean a period has elapsed, a threshold has been passed, a value has changed by some amount etc. A server could be pre-configured with such parameters a priori, or some REST interface could be provided for setting them. Regardless, I feel this is an application specific issue and often time requires knowledge about the representations to be observed. 

Regarding Esko's suggestion of allowing a server to send a new notification when it knows a representation is going to expire at a server, I find that to be an interesting idea. Doesn't seem like we came to a conclusion on that yet? 

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
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: "Dijk, Esko" <[email-masked]>
Date: Fri, 11 Mar 2011 15:24:06 +0100

Dear Zach, Daniele,

> [Zach] is the reason it is up to a server to determine what change means. Change could mean a period has elapsed, a threshold has been passed, a value has changed by some amount etc.

I agree, it leaves the strategy mostly to the server implementation. (That was also my conclusion for now on the cache efficiency issue: mostly determined by the server implementation.) Then the definition of "notification" in Section 2 could be clarified more, it now states "...supplies the client with a representation of the new resource state" implying that the resource changed (which may not be the case, if I'm correct?).

> [Zach] Regarding Esko's suggestion of allowing a server to send a new notification when it knows a representation is going to expire at a server, I find that to be an interesting idea. Doesn't seem like we came to a conclusion on that yet?

The idea came from Angelo/Matthieu, and if we follow the above that the server determines what a change is, the server is free to send (or not send) a new notification when it thinks a representation is going to expire in a cache kept by an Observer. 

> [Daniele] periodic notifications will work as follows:

I see two options, given the above:

1) don't define periodic notifications in core-observe. A server implementation may define its own way of requesting periodic notifications as Zach indicated. 

2) making it optional. Perhaps our goal of "reduce the server state" can also be satisfied by making this mechanism optional? E.g. a client requests periodic notifications using a 'periodic-notify Option' which a constrained server may ignore. The same option will be used in response(s) back to the client but only if the server understood the option and/or is willing to give periodic notifications. (If the option is ignored, the request falls back to initiating a regular observe relationship). 

best regards,
Esko Dijk

-----Original Message-----
From: Zach Shelby [mailto:[email-masked]] 
Sent: Friday 11 March 2011 13:02
To: Daniele Alessandrelli
Cc: Dijk, Esko; [email-masked]; [email-masked]; Klaus Hartke
Subject: Re: [core] Fwd: New Version Notificationfordraft-ietf-core-observe-01

Daniele,

Zach

---

From: Likepeng <[email-masked]>
Date: Mon, 14 Mar 2011 01:33:49 +0000

> 1) don't define periodic notifications in core-observe. A server implementation may define its own way of requesting periodic notifications as Zach indicated.

I prefer to this option.

Kind Regards
Kepeng
-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Dijk, Esko
发送时间: 2011年3月11日 22:24
收件人: Zach Shelby; Daniele Alessandrelli
抄送: Klaus Hartke; [email-masked]
主题: Re: [core] Fwd: New Version Notificationfordraft-ietf-core-observe-01

Dear Zach, Daniele,

best regards,
Esko Dijk

-----Original Message-----
From: Zach Shelby [mailto:[email-masked]] 
Sent: Friday 11 March 2011 13:02
To: Daniele Alessandrelli
Cc: Dijk, Esko; [email-masked]; [email-masked]; Klaus Hartke
Subject: Re: [core] Fwd: New Version Notificationfordraft-ietf-core-observe-01

Daniele,

Zach