Subject: [core] I-D Action: draft-ietf-core-observe-09.txt

From: [email-masked]
Date: Mon, 15 Jul 2013 12:19:13 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Constrained RESTful Environments Working Group of the IETF.

	Title           : Observing Resources in CoAP
	Author(s)       : Klaus Hartke
	Filename        : draft-ietf-core-observe-09.txt
	Pages           : 29
	Date            : 2013-07-15

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 document specifies a simple protocol extension for CoAP
   that enables CoAP clients to "observe" resources, i.e., to retrieve
   a representation of a resource and keep this representation updated
   by the server over a period of time.  The protocol follows a best-
   effort approach for sending new representations to clients, and
   provides eventual consistency between the state observed by each
   client and the actual resource state at the server.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-core-observe

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-core-observe-09

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-core-observe-09

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 16 Jul 2013 15:50:02 +0300

> http://www.ietf.org/rfcdiff?url2=draft-ietf-core-observe-09

Following the discussion we had in February, the major change of this
revision is that a GET request no longer can have side-effects on
other requests, and that every GET requests adds a new entry to the
list of observers. Please take a look at the draft and let me know
what you think.

observe-09 concludes the big round of changes that started with the
WGLC for observe-05 in March, 2012, except for the following two
remaining issues:

* How can a client detect that it is no longer in the list of
observers when it has successfully registered?

* How can a client cancel an observation more eagerly than by
rejecting the next confirmable notification?

There have been a few proposals over the time that are related to
these issues. These include

- the original Lifetime Option [1],
- the Pledge Option [2][3],
- the Patience Option [4],
- the Next-Notification-At-Latest Option [5],
- the new Liveliness check with Pings [6],

and

- the Condition Option with type Cancellation [7],
- the new Cancellation Message [8].

All of them have some advantages and disadvantages, and I currently do
not favor any proposal over another. Note that not all proposals have
been updated to observe-09 yet.

We should soon find consensus on which one we want to use. I propose
we do that based on running code.

If you like a proposal (or come up another one),

1. please implement both the client-side and the server-side,
2. publish the code somewhere or send me a copy by mail,
3. post a short summary of your implementation experience to the mailing list.

It would be great to have at least some feedback before the IETF
meeting in Berlin, so we can have a good discussion at the CoRE
meeting on Monday.

I plan to bring an implementation of observe-09 to Berlin. If anyone
is interested in some informal interop testing, drop me a line.

Best regards,
Klaus

[1] http://tools.ietf.org/html/draft-ietf-core-observe-01#section-3
[2] http://tools.ietf.org/html/draft-bormann-coap-misc-25#appendix-B.4.3
[3] http://tools.ietf.org/html/draft-li-core-conditional-observe-04#section-6.2
[4] http://tools.ietf.org/html/draft-li-core-coap-patience-option-02#section-2.2.3
[5] http://tools.ietf.org/html/draft-bormann-coap-misc-25#section-2
[6] http://tools.ietf.org/html/draft-hartke-core-coap-liveliness-00#section-2
[7] http://tools.ietf.org/html/draft-li-core-conditional-observe-04#section-6.1
[8] http://tools.ietf.org/html/draft-hartke-core-coap-liveliness-00#section-3

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Wed, 17 Jul 2013 07:59:40 +0000

> * How can a client detect that it is no longer in the list of observers when it

> has successfully registered?

When the client really wants to figure out if the server is still there and if it is still on the list of observers, it cannot without communicating with the server. Thus I like the Liveliness check with Pings, which keeps the additional communication to a minimum (as no representation is transmitted). By default, however, the observer should be optimistic and wait for a specific time before acting. This should be at least Max-Age, but at this point I think a combination of Pledge and Stubbornness(tm) by sharing the same time span would be useful. In critical cases (e.g., an intrusion detection application checking window sensors), a Ping might be issued earlier, though.

As notifications partake in caching, which can be used without Observing, we cannot re-use the Max-Age option for the Pledge/Stubbornness indication.

> * How can a client cancel an observation more eagerly than by rejecting the

> next confirmable notification?

I would say we use the mechanism we had before: a GET request without Observe option. Because of the Token multiplexing, there will be no accidental cancellation, as the client should not use a Token that he is already using.

(The draft says that there is no side-effect whatsoever between different GET requests, but what if the client sends a new GET request with a Token already in use? It will collide with the Observe relationship entry at the server, which will probably be overwritten. So why not use this?)

Something that should be clarified is the impact of NSTART on -observe. If an active observe relationship is considered an outstanding interaction, clients could only observe one resource. This is really bad and we would need some kind of batch mechanism in the draft. With the first notification having arrived, however, the client has heard from the server and I would not considers this an _outstanding_ interaction anymore. But then we still have a problem at the server: if a single client observes multiple resources, their notifications are influencing each other. If one resource is currently transmitting a Confirmable notification, others cannot and must wait for this transmission to be acknowledged. Or do the congestion control rules not apply here because it says "Clients" in coap-18?

Ciao

Matthias

P.S.: I was thinking about an alternative to Liveliness check with Pings: An observe validation that uses an Observe value in the request.

Pro: An observer can also check whether it has the latest representation without additional ETag options

Con: Not as generic as Liveliness check with Pings (so, is it worth to have this observe-specific additional code...?)

       CLIENT  SERVER

         |      |

         +----->|     Header: GET

         | GET  |      Token: 0x0c

         |      |   Uri-Path: obs

         |      |    Observe: (empty)

         |      |

         |<-----+     Header: 2.05

         | 2.05 |      Token: 0x0c

         |      |    Observe: 23

         |      |    Max-Age: 300

         |      |    Payload: [x bytes]

         |      |

           ...

         |      |

         |<-----+     Header: 2.05

         | 2.05 |      Token: 0x0c

         |      |    Observe: 24

         |      |    Max-Age: 300

         |      |    Payload: [x bytes]

         |      |

           ...

           ...

         |      |

         +----->|     Header: GET

         | GET  |      Token: 0x0c

         |      |   Uri-Path: obs

         |      |    Observe: 24 (note that the request has a value for Observe)

         |      |

         |<-----+     Header: 2.03

         | 2.03 |      Token: 0x0b

         |      |    Max-Age: 120

         |      |    Observe: 24

Or in case Notifications were lost:

         |<-----+     Header: 2.05

         | 2.05 |      Token: 0x0b

         |      |    Max-Age: 300

         |      |    Observe: 27

         |      |    Payload: [x bytes]

The validation check at the server would also need to deal with wrap-arounds lke the reordering process. I am also not sure how to deal with the Observe sequence number of zero, which is basically an empty Observe option.