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

From: Salvatore Loreto <[email-masked]>
Date: Fri, 4 Nov 2011 18:21:52 +0100

Hi,

I have read the document, it is really in a good shape
some comments:

-in Section 1.1. Background

I don't think the comparison with WebSocket is appropriate
as COAP, differently from HTTP, has already natively the two-way 
communication between
clients and servers; in CoAP each element can act as client/server
So I would remove the last sentence in the last paragraph of the section:

    or to enable general two-way communication between clients
        and servers [I-D.ietf-hybi-thewebsocketprotocol  <http://tools.ietf.org/html/draft-ietf-core-observe-03#ref-I-D.ietf-hybi-thewebsocketprotocol>].

-in Section 1.3 Design Philosophy

I don't agree on the similitude inserted in bracket of the first paragraph:

    (A server needs to keep track of the observers
        though, similar to how HTTP servers need to keep track of the TCP
        connections from their clients.)

  - more the last version of the draft introduces the Max-OFE,
I don't recall that the concept has been discussed in the mailing list 
before,
but most likely I have missed it.
It is not clear to me the advantage of introducing a Max-OFE value
versus to include directly the "optimistic freshness extension" time 
directly in the Max-Age:
instead of having Max-Age of 60seconds and a MAX-OFE of 10seconds
assigning directly to Max-Age a value of 70seconds

cheers
Salvatore

-- 
Salvatore Loreto
www.sloreto.com

On 10/31/11 12:37 PM, [email-masked] wrote:
> 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
>                            Zach Shelby
> 	Filename        : draft-ietf-core-observe-03.txt
> 	Pages           : 27
> 	Date            : 2011-10-31
>
>     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 gives clients the ability to observe such changes.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-core-observe-03.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-core-observe-03.txt
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 4 Nov 2011 18:58:16 +0100

> I have read the document, it is really in a good shape

After doing my review, I agree.

> as COAP, differently from HTTP, has already natively the two-way communication between
>    and servers [
> I-D.ietf-hybi-thewebsocketprotocol].

I agree that this text is not essential.

>    connections from their clients.)

I think this point is important, as people who think that HTTP is stateless always conveniently forget that e.g., for a long-poll, connection state has to be kept for a long time at the server.  An observation relationship is rather similar to this connection state, once you disregard the different layers.

So where do you see the limitations of that allegory?

> I don't recall that the concept has been discussed in the mailing list before,
> versus to include directly the "optimistic freshness extension" time directly in the Max-Age:

I thought that, too, for a while.
One reason why it is useful to have both max-age and max-ofe is that, with a single value, there is no indication when it would be a good time to start trying to get a new value -- at a time when the existing value can still be used.
See RFC5861 (the, somewhat more complex, HTTP version of this concept) for more background.

Grüße, Carsten

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 4 Nov 2011 20:28:44 +0100

Hi Carsten,

see in line

> So where do you see the limitations of that allegory?
now that you mentioned long-poll, the allegory starts to make some sense 
to me

as I said it is not clear from the context that the allegory is with 
HTTP long-poll mechanism;
while reading I understood the allegory was with the generic HTTP 
"persistent connections" independently
if they were or not at moment monopolized by long-polling requests

More in some sense the HTTP servers do not need to keep track of the 
connections used
by long-poll as they are monopolized by the long-poll requests

> See RFC5861 (the, somewhat more complex, HTTP version of this concept) for more background.
thanks for the pointer, I didn't have it on the top of my mind..

I see the usefulness of the indication of trying to get a new value 
while still using the existing value,
and even more the need to issue a new GET request to re-register (if the 
client does not receive a new
notification before Max-Age+Max-OFE ends)interest.

however the current observe draft should specify a little deeply the 
usage of it by caches ...
if a client receive a stale value from the cache (through the issue of a 
plain GET) it does not become aware
of the fact that the value is a stale one,
RFC5861 states that

    Note that "stale" implies that the response will have a non-zero Age
        header and a warning header, as per HTTP's requirements.

Ciao
Salvatore

-- 
Salvatore Loreto
www.sloreto.com

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 17 Nov 2011 18:03:23 +0800

Hi there,

I want point you to the Cache Refresh mechanism we have started to 
describe within
the draft-castellani-core-http-mapping
(ref: 
http://tools.ietf.org/html/draft-castellani-core-http-mapping-02#page-12 )
I am sure you have already read it... but just in case I copy the text here:

4.2.2.  Cache Refresh via Observe

    There are cases where using CoAP observe protocol
    [I-D.ietf-core-observe] to handle proxy cache refresh may be
    preferable to the validation mechanism based on ETag's defined in
    section 5.6.2 of [I-D.ietf-core-coap].  For example: sleeping nodes,
    possibly showing high variance in requests' distribution, would
    greatly benefit from a server driven cache update mechanism.  Other
    expected candidates would be the crowded or very low throughput
    networks, where minimization of the total number of exchanged
    messages is a major goal.

    This subsection aims at providing a practical evaluation method to
    decide whether the refresh of a cached resource R is more efficiently
    handled via ETag validation or by establishing an observation on R.

    Let T_R be the mean time between two client requests to resource R,
    F_R be the freshness lifetime of R, and M_R be the total number of
    messages exchanged by the cache towards resource R in order to
    validate its freshness.  Assumed a negligible initial cost for
    establishing the observation relationship (one only message), an
    observation on R lessens M_R (i.e. it's a better cache update choice
    then using ETag validation) iff T_R<  2*F_R, or equivalently, iff the
    mean arrival time of requests for resource R is greater than half the
    refresh rate of R.

    The above relation can easily be grasped by noticing that, in case
    the mean interarrival time between requests is less than the refresh
    rate of R, an observation does not generate any unnecessary
    validation message, and is therefore optimal.  Further, since the
    number of messages used by ETag's validation is twice the observation
    cost (request/response vs server push), the bound on T_R can be
    doubled.

    As a rule of thumb, volatile resources (i.e. those showing tiny
    freshness lifetime) with access rate in the order of half their
    refresh rate, are good candidates for implementing observer-based
    cache refresh.  Imagine a sensor providing one new value every
    second, and clients accessing it on average once every 1.5 seconds:
    in one single day of usage, 28800 messages may have been saved if HC
    establishes an observation on the sensor resource.

cheers

-- 
Salvatore Loreto
www.sloreto.com

On 11/5/11 3:28 AM, Salvatore Loreto wrote:
> now that you mentioned long-poll, the allegory starts to make some 
> sense to me
>
> and even more the need to issue a new GET request to re-register (if 
> the client does not receive a new
> if a client receive a stale value from the cache (through the issue of 
> a plain GET) it does not become aware

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 17 Nov 2011 19:15:40 +0800

Hi Carsten,

from your previous answer to my concerns I understood
you borrowed the idea from RFC5861
that allows to a cache the possibility to serving stale responses while 
it attempts to revalidate it

However in draft observe-03 the mechanism draft is quite different as
the Max-OFE semantic is defined as a promise by the server that  it 
intends to send another notification
within "Max-OFE" time period once Max-Age time period has expired so 
that if the client does not receive
a new notification before Max-Age plus Max-OFE ends,  it will assume 
that it was removed from the list
of observers (e.g., due to a loss of server state)  and may issue a new 
GET request to re-register its interest.

after the discussion during the first CoRe session today and some more 
thinking on the issue,
I have concerns that there could be something dangerous in Max-OFE, 
because if the server does not set the value properly
this mechanism could end up to generate quite a lot of useless traffic, 
especially for servers that have high variances in value changes.
More, we should not expect the server doing something similar to what 
described in the draft-castellani-core-http-mapping
Section 4.2.2. "Cache Refresh via Observe" to obtain a precise Max-OFE, 
as get it could be too time/resource expensive for
a constrained server.

IMO It would safer that is the observer to do some statical calculation 
to figure it out if it was or not removed from the list
of the observer (i.e. because it has not received an updated when it 
supposed to receive)

comments, opinions are really welcome

regards
Salvatore

-- 
Salvatore Loreto
www.sloreto.com

---

From: TianLinyi <[email-masked]>
Date: Thu, 17 Nov 2011 16:27:54 +0000

Hi, Carsten, Salvatore

I agree with Salvatore that a new GET for creating a new observation would be enough if the server didn't receive further notifications.

I didn't see much benefit for MAX-OFE in R03 (neither in RFC5861). Instead it bring complexity to sensors. In our implementation we believe MAX-AGE would be enough. Let's bring something really useful and simple in observe.

By the way, i even think Accept is not very useful in M2M environment. Is this too late to get rid of things? LOL.

Cheers,
Linyi

________________________________
发件人: [email-masked] [[email-masked]] 代表 Salvatore Loreto [[email-masked]]
发送时间: 2011年11月17日 19:15
到: [email-masked]
主题: [core] Max-OFE issue (was Re: I-D Action: draft-ietf-core-observe-03.txt)

Hi Carsten,

from your previous answer to my concerns I understood
you borrowed the idea from RFC5861
that allows to a cache the possibility to serving stale responses while it attempts to revalidate it

However in draft observe-03 the mechanism draft is quite different as
the Max-OFE semantic is defined as a promise by the server that  it intends to send another notification
within "Max-OFE" time period once Max-Age time period has expired so that if the client does not receive
a new notification before Max-Age plus Max-OFE ends,  it will assume that it was removed from the list
of observers (e.g., due to a loss of server state)  and may issue a new GET request to re-register its interest.

after the discussion during the first CoRe session today and some more thinking on the issue,
I have concerns that there could be something dangerous in Max-OFE, because if the server does not set the value properly
this mechanism could end up to generate quite a lot of useless traffic, especially for servers that have high variances in value changes.
More, we should not expect the server doing something similar to what described in the draft-castellani-core-http-mapping
Section 4.2.2. "Cache Refresh via Observe" to obtain a precise Max-OFE, as get it could be too time/resource expensive for
a constrained server.

IMO It would safer that is the observer to do some statical calculation to figure it out if it was or not removed from the list
of the observer (i.e. because it has not received an updated when it supposed to receive)

regards
Salvatore

--
Salvatore Loreto
www.sloreto.com<http://www.sloreto.com>

see in line

now that you mentioned long-poll, the allegory starts to make some sense to me

as I said it is not clear from the context that the allegory is with HTTP long-poll mechanism;
while reading I understood the allegory was with the generic HTTP "persistent connections" independently
if they were or not at moment monopolized by long-polling requests

More in some sense the HTTP servers do not need to keep track of the connections used
by long-poll as they are monopolized by the long-poll requests

I see the usefulness of the indication of trying to get a new value while still using the existing value,
and even more the need to issue a new GET request to re-register (if the client does not receive a new
notification before Max-Age+Max-OFE ends)interest.

however the current observe draft should specify a little deeply the usage of it by caches ...
if a client receive a stale value from the cache (through the issue of a plain GET) it does not become aware
of the fact that the value is a stale one,
RFC5861 states that

Ciao
Salvatore

--
Salvatore Loreto
www.sloreto.com<http://www.sloreto.com>

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 18 Nov 2011 01:10:15 +0800

> of the observer (i.e. because it has not received an updated when it supposed to receive) 

The problem is that the client has nothing to base this calculation on.
That is why it is a good idea for the server to say something, because it is the server that intends to act on the observation relationship.

We may have various ideas of what is the best way to group the information to be made available from the server, but it is pretty clear that a single max-age value does not cut it.  A second value is needed, and we need to discuss how to slice this.

Note that all this is elective, so if you want to keep things simple, you can always leave it off -- things will just be less efficient.  Constrained environments may need the efficiency of correctly working client/proxy caching, though.

Grüße, Carsten

PS.: Linyi -- yes, Accept is not needed in many cases, but again, this Option also is elective. The alternative (where the functionality is needed) is to encode the required media type in the URI, and that probably causes more complexity.  Should this be in the base spec?  It does not make a difference where it is written up.

---

From: TianLinyi <[email-masked]>
Date: Thu, 17 Nov 2011 23:40:07 +0000

>That is why it is a good idea for the server to say something, because it is the server that intends to act on the observation relationship.

The observer will decide whether it may be removed from the observation list according to the local policy (e.g. timeout). It is not only because of MAX-AGE neither MAX-OFE. 

There maybe use case that the application trys to get the data from the sensor while the Proxy found out that the sensor is in sleeping mode. In this case, the proxy may want to extend the cache expiry time using the cache control mechanism in RFC5861. But i don't see the need for the sensor to use this mechism. Therefore i don't see the need to have it in observe. 

Making it elective will not make this more valuable. Less optional things improve interoperbility. People are concerning about whether it is really useful. Bring everything from HTTP is not the way forward. I agree with you Accept could be useful in some cases that's why we implemented it. 

Note that RFC5861 is information and not a standard track. 

________________________________________
发件人: [email-masked] [[email-masked]] 代表 Carsten Bormann [[email-masked]]
发送时间: 2011年11月18日 1:10
到: Salvatore Loreto
Cc: [email-masked]
主题: Re: [core] Max-OFE issue (was Re: I-D Action:       draft-ietf-core-observe-03.txt)

Grüße, Carsten

---

From: "Rahman, Akbar" <[email-masked]>
Date: Thu, 17 Nov 2011 19:30:37 -0500

Hi Carsten,

In preparation for continuing our multicast discussion today in CORE, I would like to add three points for discussion:

- I did a quick word count, and there are 29 references to how "multicast" is supported/used in the base CoAP spec (http://tools.ietf.org/html/draft-ietf-core-coap-08)

- The base RPL spec clearly has a multicast mode of operation (http://tools.ietf.org/html/draft-ietf-roll-rpl-19#page-106)

- CoAP is supposed to run on non LowPAN networks where multicast is obviously supported

So, I understand the concern about actual deployments of multicast, but I do not logically see how we can shoot down the Group Communications draft on the basis of a premise that multicast is NOT supported in the various protocols.

Looking forward to your feedback!

Akbar