Subject: [core] Observe-misc: concepts and terminology

From: "Kovatsch Matthias" <[email-masked]>
Date: Sun, 3 Jun 2012 07:26:12 +0000

Dear List
Apologies for being "last minute," but there have been some unforeseen occurrences…
Klaus and I worked on the concepts and terminology for Observe. Here is a quick summary that might help for the discussion. Klaus is working on a draft version "observe-misc" and will publish more details there.

Note that this summary was not approved by Klaus, yet.

The summary is also available here:
https://docs.google.com/document/d/1FiYu5g7346YXj1gUrlxXD547rGr7mVVWVX-mBQbHas0<https://docs.google.com/document/d/1FiYu5g7346YXj1gUrlxXD547rGr7mVVWVX-mBQbHas0/edit>

Ciao
Matthias
Concepts
Concept Definition      Encoding
Relationship Request            Observe option in request
Relationship Acceptance When a response has the Observe option set, it becomes a notification.
Notifications have slightly different semantics than responses, in particular for the meaning of Max-Age.
Notifications can still be stored in caches, but all previous representations for the request URI become stale when a new new notification arrives.     Observe option in response
→ notification
Keep-Alive      At least one of the notifications sent within a 24 hour time frame MUST be confirmable.

Implementation note: A server may send a redundant CON notification at a certain time of day (subject to congestion control) rather than keeping track of the last confirmable notification it sent for each client and resource.

Implementation note: A server may send a redundant CON notification at any time to free an observer slot that might be blocked by a potentially dead client.    Protocol constant
Relationship Refresh    A client requests an Observe relationship although it already received an Observe Acceptance.   Observe option in request
Earliest Notification   The server knows that the resource cannot change its state within a certain time span (e.g., because of a sampling rate).

(This is not Max-Age!)  Min-Age option?
Latest Notification     The server says when it will send a new notification at latest, even when the resource state did not change, to refresh the representation and observe relationship at the client.
Clients optimistically assume the resource state did not change before Latest Notification expires, but MAY perform a Relationship Refresh.
When Latest Notification is reached, a CON notification is sent by the server.  Pledge option!

non-negative integer that is added to the Cache Control value

Default: use Max-Age value (does not work in some cases)
Cache Control (Observe) A value for caches to calculate Max-Age when creating a response from a stored notification.    Max-Age option in notification!
Polling Control A polling policy for clients to not poll again before the value timed out.
Similar to Latest Notification with Observe.    Pledge option!
Age     The age of the resource representation in the cache     Date Option?
Payload?
Freshness       A freshness estimation during which a cached representation can be used. On expiry, the information becomes stale and caches MUST NOT return it.

For Observe, the information can be assumed fresh until a new notification arrives. The freshness estimation and notification intervals might differ considerably, though. Thus, Latest Notification is a different concept.    Max-Age Option in response
Authoritative information       The information comes from the authoritative source, i.e. the origin server     Response code?
Authoritative response bit?
Non-authoritative information   The information comes from a non-authoritative source, e.g., proxy cache.
(An intermediary cannot not have a cache, but the cache may have a very aggressive cache eviction policy.)      Response code?
Non-authoritative response bit?
Refresh The client tells intermediaries along the path that it needs authoritative information and not a response from a cache. “Cache-control: no-cache” Option?

Problems
Problem Effect  Solution Mechanism
Message latency and loss        Max-Age might become zero

Client might assume server problem

Latest Notification might expire        Eventual consistency

Latest Notification backoff
Message duplication             MID / (same as Message reordering)
Message reordering              Sequence number/timestamp in each notification
Client loses state      Server wastes resources RST by client
Keep-Alive
Client temporarily goes away (sleeps)   "       Quality of implementation: Sleepy clients should not initiate observe relationships.
Client permanently goes away    "       Keep-Alive
Server loses state      Latest Notification expires     Relationship Refresh
Server permanently goes away    Latest Notification expires

Relationship Refresh will ultimately fail       Client gives up
(Reasonable time for a retry?)

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Sun, 3 Jun 2012 07:29:55 +0000

Okay, no HTML allowedŠ

Please use the link:
https://docs.google.com/document/d/1zFbW6DqsozLE81sdwZy_IrNy4bkFd01TqWb98Rq
rems/edit

---

From: Antonio Jara <[email-masked]>
Date: Sun, 3 Jun 2012 11:22:40 +0200

Dear Matthias,

The link to google doc continues without working.

Best regards,
Antonio J. Jara

On Sun, Jun 3, 2012 at 9:29 AM, Kovatsch  Matthias <[email-masked]> wrote:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Sun, 3 Jun 2012 10:17:22 +0000

I am sorry, there was a mix-up with the hash value URIs...

This is the correct link to the preliminary summary:
https://docs.google.com/document/d/1FiYu5g7346YXj1gUrlxXD547rGr7mVVWVX-mBQbHas0/edit

Ciao
Matthias

> -----Ursprüngliche Nachricht-----
> Von: Antonio Jara [mailto:[email-masked]]
> Gesendet: Sonntag, 3. Juni 2012 11:23
> An: Kovatsch Matthias
> Cc: [email-masked] WG; Klaus Hartke
> Betreff: Re: [core] Observe-misc: concepts and terminology
> 
> Dear Matthias,
>

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Sun, 3 Jun 2012 12:57:16 +0000

Okay, I removed the summary again, as the Observe action item was not intended to be due tomorrow.
We need more time to agree on the concepts and Klaus wants to avoid misinterpretation and unnecessary discussion.

Sorry again for the confusion!
Matthias

> Von: [email-masked] [mailto:[email-masked]] Im Auftrag von
> Kovatsch Matthias
> Gesendet: Sonntag, 3. Juni 2012 12:17
> An: Antonio Jara
> Cc: Klaus Hartke; [email-masked] WG