Subject: [core] Observing Resources in CoAP: re-ordering

From: Oscar Novo <[email-masked]>
Date: Fri, 22 Jul 2011 12:10:28 +0200

Hi,

I think the way the observe draft handles reordering is far too complicated. Besides, I'm wondering how this solution would work for sleeping clients. Have you think about it? At least, I can see some problems with the actual solution.

I think a neat solution would be that the server increments in one an integer value in every notification to indicate the order of the notifications. What do you think about that?

Cheers,

Oscar

[http://www.ericsson.com/shared/images/Email_line.gif]

OSCAR NOVO
Research Engineer, Ericsson Research

Nomadiclab, Services and Software
Ericsson Finland, Oy L M Ericsson Ab
Hirsalantie 11
02420 Jorvas, Finland
www.ericsson.com

[http://www.ericsson.com/shared/images/Email.gif]

This Communication is Confidential. We only send and receive email on the basis of the term set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Fri, 22 Jul 2011 10:20:34 +0000

Hello

Sleeping nodes could have a function to map their internal clock to that current integer and only update the value when sending notifications.
But I would also prefer the a simple counter for the notifications. If the subscriber is interested in timing, typical applications would include a proper timestamp in the notification anyway.

This way I client can also detect how many NON-notifications were lost (or even CONs if the link is really bad for some time).

Regards
Matthias

From: [email-masked] [mailto:[email-masked]] On Behalf Of Oscar Novo
Sent: Freitag, 22. Juli 2011 12:10
To: [email-masked]; [email-masked]
Subject: [core] Observing Resources in CoAP: re-ordering

Hi,

Cheers,

Oscar

[Description: Image removed by sender. line]
OSCAR NOVO
Research Engineer, Ericsson Research

[Description: Image removed by sender. Ericsson]

---

From: Klaus Hartke <[email-masked]>
Date: Fri, 22 Jul 2011 18:55:51 +0200

The reordering mechanism was designed to make as few requirements on
implementations as possible. This led to some fairly complex language
in the draft, but allows for many very simple implementations. I agree
that the text should be simplified; there is already a ticket on that
(#129).

A simple counter for notifications is actually an acceptable
implementation, provided that the server does not reuse the same
counter value within 2^16 seconds.

Another acceptable implementation is to use the current value of the
device's clock. Again, the only requirement is that the same value is
not reused within 2^16 seconds. There is no requirement that the clock
returns the correct date/time or that the clock ticks exactly every
second.

Here's an implementation in Python:

Server:

    message.observe = long(time.time()) % (2**16)

Client:

    obs = lookup(message.token)

    v1 = obs.v
    t1 = obs.t
    v2 = long(message.observe)
    t2 = long(time.time())

    if (v1 - v2) % (2**16) < (2**15) and t2 < (t1 + (2**14)):
        print "Discard"
    else:
        obs.v = v2
        obs.t = t2
        print "Accept"

The server needs no state to generate the option value. The client
needs just to remember two values per observation relationship; the
if-expression is copied literally from the draft. I'm not sure how
this can be further simplified; suggestions are welcome.

Regarding sleeping devices, draft-arkko-core-sleepy-sensors-01 states
for Message IDs: "We have found that using a suitably shifted value of
a real-time clock is the most convenient way to generate a good value
for this field. On many small platforms, a real-time clock can be kept
counting with a very small amount of power. Note that it does not
matter what value the real-time clock is initially initialized to; the
only thing that matters for the Message ID field is that it keeps
changing." The same applies for the Observe option value, so I see no
problem here at present.

Can you expand on the problems you see with sleeping devices?

Klaus

---

From: Oscar Novo <[email-masked]>
Date: Mon, 25 Jul 2011 12:31:27 +0200

If we suppose the case of a network which has some sleeping nodes and some caching nodes which store the observation methods and deliver them once the sleeping-nodes are awake. How an sleeping observer could handle the historical notifications data of a subject if the wake up time of the node is higher than 18.2 hours?

As you said, simplifying some parts of the text might help. Right now, the complexity of it make it difficult to understand the draft.  

Oscar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Klaus Hartke
Sent: 22. heinäkuuta 2011 19:56
To: [email-masked]
Subject: Re: [core] Observing Resources in CoAP: re-ordering

The reordering mechanism was designed to make as few requirements on implementations as possible. This led to some fairly complex language in the draft, but allows for many very simple implementations. I agree that the text should be simplified; there is already a ticket on that (#129).

A simple counter for notifications is actually an acceptable implementation, provided that the server does not reuse the same counter value within 2^16 seconds.

Another acceptable implementation is to use the current value of the device's clock. Again, the only requirement is that the same value is not reused within 2^16 seconds. There is no requirement that the clock returns the correct date/time or that the clock ticks exactly every second.

Server:

Client:

    v1 = obs.v
    t1 = obs.t

The server needs no state to generate the option value. The client needs just to remember two values per observation relationship; the if-expression is copied literally from the draft. I'm not sure how this can be further simplified; suggestions are welcome.

Regarding sleeping devices, draft-arkko-core-sleepy-sensors-01 states for Message IDs: "We have found that using a suitably shifted value of a real-time clock is the most convenient way to generate a good value for this field. On many small platforms, a real-time clock can be kept counting with a very small amount of power. Note that it does not matter what value the real-time clock is initially initialized to; the only thing that matters for the Message ID field is that it keeps changing." The same applies for the Observe option value, so I see no problem here at present.

Klaus

> I think a neat solution would be that the server increments in one an integer value in every notification to indicate the order of the notifications. What do you think about that?
_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 25 Jul 2011 14:02:38 +0200

> If we suppose the case of a network which has some sleeping nodes and some caching nodes which store the observation methods and deliver them once the sleeping-nodes are awake. How an sleeping obse…

I'm not sure I understand the question, but after 18.2 hours the time limit of t2 < (t1 + (2**14)) is long gone, so there would be no need to check for reordered messages reaching back that long.

Gruesse, Carsten