Subject: [core] observe #66 (new): Identifying observations

From: "core issue tracker" <[email-masked]>
Date: Tue, 09 Nov 2010 16:37:27 -0000

#66: Identifying observations

 It should be clarified that an observation is identified by the URI of the
 observed resource and the the IP address + port of the observer.

 A token submitted by the observer must not be used by the server to
 identify an observation; observation requests from the same observer to
 the same resource must update/replace any ongoing observation, even if the
 token has changed.

-- 
----------------------------+-----------------------------------------------
 Reporter:  hartke@…        |       Owner:  hartke@…      
     Type:  defect          |      Status:  new           
 Priority:  minor           |   Milestone:                
Component:  observe         |     Version:                
 Severity:  -               |    Keywords:                
----------------------------+-----------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/66>
core <http://tools.ietf.org/core/>

---

From: [email-masked]
Date: Wed, 10 Nov 2010 11:07:10 +0100

Hi Klaus,

I understand that a token is not a valid identifier for an observation.
>From the text in coap-3 the lifetime of a token seems to be
request-response(s) but the lifetime of an observation can span over
multiple requests. However the size of URI + IP + port is 0(scheme?)+270
(authority)+270(path)+270(query)+16(IP)+2(port) = 828 bytes ! Storing 828
bytes seems unadapted to constrained devices. Guido Moritz suggested a new
identifier named EventID that could help to create a relation between an
obsvervation and the requests required to manage the lifetime of that
observation.

Moreover the current text in coap-observe-0 section 2.1 specify that the
token MAY be included. But as I understand coap-3 the token option is a
MUST for asynchronous responses. And in a way coap-observe is just multiple
asynchronous responses. Do you think the text should be changed ?

One last question. Imagine an observer creating an observation through a
proxy. For example a 6lowpan IPv6-only client wants notifications from an
IPv4 only server through a dual stack proxy. How the proxy can identify the
observer from the notification messages ? The proxy could store the context
of the observer during the lifetime of the observation just like the origin
server. Also many proxied requests may appear with the same tuple
(URI,address,port) from the server point of view. Maybe this use case
should be clarified.

Regards,
Matthieu

             "core issue                                                   
             tracker"                                                      
             <[email-masked].                                           A 
             org>                      [email-masked]                      
             Envoyé par :                                               cc 
             core-bounces@ietf         [email-masked]                       
             .org                                                    Objet 
                                       [core]  observe #66 (new):          
                                       Identifying observations            
             09/11/2010 17:37                                              

 Reporter:  hartke@?        |       Owner:  hartke@?

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

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
______________________________________________________________________

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 10 Nov 2010 18:42:29 +0800

On Nov 10, 2010, at 18:07, [email-masked] wrote:

> Storing 828 bytes seems unadapted to constrained devices.

Then don't do that.

You don't *have* to use ridiculously large URIs.

Gruesse, Carsten

---

From: Klaus Hartke <[email-masked]>
Date: Wed, 10 Nov 2010 16:08:21 +0100

[email-masked] wrote:
> I understand that a token is not a valid identifier for an observation. From the text in coap-3 the lifetime of a token seems to be request-response(s) but the lifetime of an observation can span over multiple requests.

Right. Illustrating example:

C: GET /light (token=0xab6f) (observation-lifetime=60s)
S: 200 (token=0xab6f) (observation-lifetime=60s) "<light>..."
S: 200 (token=0xab6f) (observation-lifetime=32s) "<light>..."
S: 200 (token=0xab6f) (observation-lifetime=11s) "<light>..."
C: GET /light (token=0x1b80) (observation-lifetime=60s)
S: 200 (token=0x1b80) (observation-lifetime=59s) "<light>..."
S: 200 (token=0x1b80) (observation-lifetime=57s) "<light>..."
...

> However the size of URI + IP + port is 0(scheme?)+270(authority)+270(path)+270(query)+16(IP)+2(port) = 828 bytes ! Storing 828 bytes seems unadapted to constrained devices.

As someone pointed out somewhere else, the scheme, authority and path
are likely to be stored somewhere already, so it's probably more
something like 4(pointer to resource)+270(query)+16(IP
address)+2(port)+4(remaining lifetime) = 296 bytes.

A constrained device that doesn't serve any parametrizable resources
doesn't have to reserve space for queries, then it's something like
4(pointer to resource)+0(query)+16(IP address)+2(port)+4(remaining
lifetime) = 26 bytes. I think that's reasonable.

> Guido Moritz suggested a new identifier named EventID that could help to create a relation between an obsvervation and the requests required to manage the lifetime of that observation.

If I read his mail correctly, the advantage of the EventID is that
requests to extend the lifetime of an observation don't need to
reiterate the URI of the subject in the request. That saves a few
bytes in the messages, but introduces additional state at both the
server and the client which hurts when it gets out of sync.

What I like about the current solution is that, in the case the server
and the client disagree about the state of the observation, the client
can simply synchronize the conversation state by sending a request to
extend the lifetime of an observation (which is indistinguishable from
a plain observation request) and everything is well again.

> Moreover the current text in coap-observe-0 section 2.1 specify that the token MAY be included. But as I understand coap-3 the token option is a MUST for asynchronous responses. And in a way coap-observe is just multiple asynchronous responses. Do you think the text should be changed ?

Yes, -observe currently doesn't reflect the wording in -coap. That
needs to be fixed.

> One last question. Imagine an observer creating an observation through a proxy. For example a 6lowpan IPv6-only client wants notifications from an IPv4 only server through a dual stack proxy. How the proxy can identify the observer from the notification messages ? The proxy could store the context of the observer during the lifetime of the observation just like the origin server. Also many proxied requests may appear with the same tuple (URI,address,port) from the server point of view. Maybe this use case should be clarified.

The idea is that, when multiple clients observe the same resource
through a proxy, the proxy creates a single observation and notifies
all clients when it receives a notification from the server. The proxy
doesn't need to observe the same resource multiple times, because the
single observation will already make sure that the proxy receives the
current state of the resource whenever it changes.

Klaus

---

From: Guido Moritz <[email-masked]>
Date: Wed, 10 Nov 2010 17:19:24 +0100

> > Guido Moritz suggested a new identifier named EventID that could help to
> create a relation between an obsvervation and the requests required to
> manage the lifetime of that observation.
> 
The advantage is a very simple assignment of the messages to the
subscription. This applies for all messages, the subscription management
(lifetime refresh, unsubscribe,  ...) and for notifications as well. 
Without pushing this discussion in a too theoretical corner, I would argue
Sub/Not is always stateful at both sides. A server must be aware to send a
Not if a resource changes, so the server has a state (subscribers, queries,
...). A client has a state as well, because it must be aware of retrieving a
Not and correctly handling it. 

> a plain observation request) and everything is well again.
In case a server goes down and up again the subscription might be lost. So
there is no other chance for a client to subscribe again after not
retrieving any notifications.
In case a client goes down and retrieves an unknown EventID, the client may
ask the server to send the resource+query to the client to get in sync
again. The client also may cancel the subscription with the unknown EventID
and subscribe again. This would be one more round trip in case of a lost
subscription, but the EventID approach might save numerous bytes especially
for frequent notifications.

If we assume that the resources to subscribe to have a short path and only
short queries, the current approach is fine. But for frequent notifications
with only slightly complex querries, the EventID might result in much more
compact messages and might reduce the required RAM on servers side. 

Guido

---

From: [email-masked]
Date: Wed, 10 Nov 2010 18:04:24 +0100

The notifications do not include the URI but a token.

Illustrating example from Klaus

Matthieu

---

From: Guido Moritz <[email-masked]>
Date: Wed, 10 Nov 2010 20:55:31 +0100

But as I mentioned before, I would say this is not completely straight
forward as tokens are to identify the transaction, not the subscription
itself. I am also thinking about scenarios with CON notifications. In such
cases, using the tokens to identify the subscription might be misleading. So
I would 

vote for a clear separation of transaction (tokens) and subscription logic
(some kind of EventID).

Guido

Von: [email-masked]
[mailto:[email-masked]] 
Gesendet: Mittwoch, 10. November 2010 18:04
An: Guido Moritz
Cc: 'core'; [email-masked]
Betreff: Re: [core] RE observe #66 (new): Identifying observations

Matthieu