Subject: [core] draft-ietf-core-observe-05 - use of max-age

From: Jeroen Hoebeke <[email-masked]>
Date: Mon, 26 Mar 2012 17:58:32 +0200

Dear working group,

In draft-ietf-core-coap-09, max-age is introduced to indicate the freshness of a response, useful for caching. In draft-ietf-core-observe-05, max-age is also used and the following is stated: It (the server) will send a notification whenever the resource changes, or at latest when the age of the last notification becomes greater than its Max-Age.

While implementing this functionality for the plugtest event, we found this to be a quite stringent requirement for a resource constrained device (in particular when the resource does not change frequently, e.g. a door sensor during night). Simply increasing max-age is not really a nice solution, since then you impact freshness. Also, alternative solutions for realizing notifications latest after X seconds have been proposed already (e.g. draft-shelby-core-interfaces-02 section 4.8 or draft-li-core-conditional-observe-01). It seems the behavior in draft-ietf-core-observe-05 has been particularly designed for e.g. a cache that always needs to have a fresh representation.

We would like to have some more freedom here. This could be done by shifting the responsibility to the observer by stating that "an observer should not re-register its interest before max-age expires". The server then has the freedom to send notifications only when the resource changes OR every time the age of the last notification becomes greater than max-age. The client then has the freedom to reregister immediately after max-age or to wait much longer (depending on the application). The meaning of max-age for caching purposes does not change.

Kind regards,
Jeroen

---

From: Jeroen Hoebeke <[email-masked]>
Date: Wed, 28 Mar 2012 14:46:40 +0200

Dear working group,

I gave the max-age issue a bit more thought and discussed this with Klaus.

I feel the issue described in my earlier e-mail, is mainly caused due to the fact that the max-age option is used for two purposes at the same time: 1) the freshness of a notification 2) the duration of the established observation relationship. This has a number of drawbacks:
- how to deal with notifications of non-cacheable resources (max-age =0). This is not described in the draft
- what when a client wants to only observe changes, max-age is short and the client does not want to reregister all the time to be sure about the duration of the relationship

Giving it some further thought, it feels most of the problems could be solved by incorporating the Pledge option (described in draft-bormann-coap-misc-13 section 4.3) into this draft
- max-age option: only indicates the freshness of the notification
- pledge option: only indicates the duration of the relationship.

With these two options one can cover all different cases, as I will describe below:

1) client establishes observation relationship, server sends back response with Obs and Max-age option
-> in absence of the Pledge option, the duration of the relationship is assumed to be minimally max-age
=> this is the behavior as currently described in the draft

2) client establishes observation relationship, server sends back response with Obs, Max-age and Pledge option
-> max-age is the freshness and can be used by a cache
-> pledge (> max-age) indicates the duration of the relationship, which can be much longer than max-age. Client should not reregister interest before pledge duration expires.

3)  client establishes observation relationship for non-cacheable resource, server sends back response with Obs, Max-age and Pledge option
-> max-age is 0, pledge option must be set
-> non cacheable, but pledge indicates the duration of the relationship

4) client establishes observation relationship and indicates a preferred duration of this relationship
-> client can send request including observe and pledge option
-> server decides about value of the pledge option in response

With this approach, all cases can be covered:
- relationship where a client will always have a fresh and consistent representation of the resource (max-age = pledge)
- long-lasting relationship where pledge > max-age
- observation relationship of non-cacheable resource
…

I would prefer to see the Pledge option become part of the draft, since it would allow more flexibility (without losing interoperability), would cleanly separate freshness from relationship duration and would solve some inconsistencies in the current draft such as observing non-cacheable resources.

Kind regards,
Jeroen

On 26 Mar 2012, at 17:58, Jeroen Hoebeke wrote:

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

********************************************************************
dr. ir. Jeroen Hoebeke
Department of Information Technology
Internet Based Communication Networks and Services (IBCN)
Ghent University - IBBT 
Gaston Crommenlaan 8 (Bus 201)
B-9050 Gent, Belgium

T:              +32 9 33 14954
T Secr:     +32 9 33 14900	
F:              +32 9 33 14899
E-mail:     [email-masked]
Web site: http://www.ibcn.intec.UGent.be	
                  http://www.ibbt.be
********************************************************************

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Wed, 28 Mar 2012 12:53:44 +0000

+1 to include Pledge in observing

Matthias

Jeroen Hoebeke <[email-masked]> wrote:
Dear working group,

Kind regards,
Jeroen

T:              +32 9 33 14954
T Secr:     +32 9 33 14900
F:              +32 9 33 14899

---

From: Klaus Hartke <[email-masked]>
Date: Wed, 28 Mar 2012 16:45:10 +0200

> I would prefer to see the Pledge option become part of the draft, since it would allow more flexibility (without losing interoperability), would cleanly separate freshness from relationship duratio…

+1.

However, Pledge creates a new problem: The purpose of -observe is to
let a client have a fresh representation of a resource at any given
time. When max-age ends and no notification arrives, the client does
not have a fresh representation. Due to the Pledge Option, the client
knows that it's still on the list of observers, so this could mean two
things:

1. the server sent a notification but the notification got lost;
2. the server did not send a notification because the resource state
did not change.

These are indistinguishable for the client.

The Max-OFE Option solved this problem by defaulting to 2., i.e.
Max-OFE = pledge to keep the client on the list of observers for a
certain time period + the client should assume that the resource did
not change if it does not have a fresh representation but knows that
it is on the list of observers.

Klaus

---

From: [email-masked]
Date: Wed, 28 Mar 2012 17:08:09 +0200

Hi Klaus

>When max-age ends and no notification arrives, the client does

I'm facing almost the same problem with the cache on the mirror proxy 
where Pledge = lifetime of the mirror proxy entry.

I'm not sure about what to do when Max-Age has expired but the resource is 
still reachable on the mirror.
For a mirror proxy I'm thinking about returning a "Gateway Timeout" code 
as a transient error.

Does it make sense for you?

Matthieu

---

From: Jeroen Hoebeke <[email-masked]>
Date: Wed, 28 Mar 2012 17:10:27 +0200

On 28 Mar 2012, at 16:45, Klaus Hartke wrote:

> time.

There is a difference between the following:
1) informing a client about every change of the state of a resource: this is what one would expect when just reading the abstract of the draft 
2) delivering a client an always fresh representation of a resource (even if the resource did not change): this is what the draft actually implements through the max-age option

Having both makes a lot of sense. Draft observe could fulfill both purposes (and would be a good place to do so). If draft observe is only about 1) and the abstract clarifies this, an extension to observe (introducing pledge) for case 2) seems an obvious step. Personally, I am in favor of having this in a single draft.

Kind regards,
Jeroen