Subject: [core] SenML base stride: time offset between records

From: Ari Keränen <[email-masked]>
Date: Wed, 20 Jul 2016 14:27:10 +0000

Hi,

Third suggestion we discussed recently with Christian (Cc'd) is to add a "base time offset" or "base stride" parameter that allows eliding the time value for measurements that have been done at equal intervals. So (slightly modifying Christian's original example), using currently defined format you would have

     "bt": 1320067464,
     "bu": "%RH",
     "v": 21.2, "t": 0 },
     { "v": 21.3, "t": 10 },
     { "v": 21.4, "t": 20 },
     { "v": 21.4, "t": 30 },
      ...

With "base stride" of 10 seconds, that would be

    "bt": 1320067464,
    "bs": 10,
    "bu": "%RH",
     "v": 21.2},
     { "v": 21.3},
     { "v": 21.4},
     { "v": 21.4},
     ...

And of course the benefits become more apparent the more records you have.

This does bring some complexity since you have to do some simple arithmetics based on the "index" of the record to find out the time for each SenML Record. Also it's questionable how often the measurements are done in exact (enough) time intervals. On the other hand, it reduces size of a Pack considerably in relatively common use case.

I would suggest we include this feature in the next version of the SenML draft.

Opinions?

Cheers,
Ari

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 20 Jul 2016 16:43:55 +0200

I don’t feel supper strongly either way. It seems like a nice feature but on the other hand I don’t want to just add a bunch of incremental complexity. I guess I am weakly in favour of this. 

> On Jul 20, 2016, at 4:27 PM, Ari Keränen <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Christian Amsüss <[email-masked]>
Date: Wed, 20 Jul 2016 16:52:59 +0200

On Wed, Jul 20, 2016 at 02:27:10PM +0000, Ari Keränen wrote:
> Third suggestion we discussed recently with Christian (Cc'd) is to add
> a "base time offset" or "base stride" parameter that allows eliding
> the time value for measurements that have been done at equal
> intervals.

On the balance between complexity and achievable compression, I'm
moderately in favor of this.

However, we should think through the numerics of this for non-integer
times. Maybe it might be a good idea to limit base time (even
independently of the strides) and the stride size to integers. (That's
also the easiest way to avoid clients having to add an integer, a
multiple of a decimal and a floating point coming from CBOR in this
situation.)

As the topic of precisely hitting the stride time, I think that a stride
time should accumulate on the base time, and a time delta could still be
applied. The delta can then be, in case of floating point time, the
remaining t can then easily fit in a half float.

Best regards
Christian

-- 
Christian Amsüss                      | Energy Harvesting Solutions GmbH
founder, system architect             | headquarter:
mailto:[email-masked]  | Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39                | http://www.energyharvesting.at/
                                      | ATU68476614

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 20 Jul 2016 18:31:32 +0200

> On Jul 20, 2016, at 4:52 PM, Christian Amsüss <[email-masked]> wrote:
> 

you have just convinced me that values in CBOR should be float not a mixture of different integer, rational, and floating point types

---

From: Christian Groves <[email-masked]>
Date: Thu, 21 Jul 2016 05:41:17 +1000

Hello Ari, all,

No surprise that I'm in favour of this. I wasn't sure about "stride" but 
when I checked the dictionary it said "move over with long measured 
steps" so it seems pretty appropriate.

There was some discussion about whether this would apply to a negative 
offset (e.g. "t": -10} case or just a time series increasing stride from 
the base time? Time series increasing only might minimise the 
implementation complexity but then the ability to map between negative 
time offset and stride would be lost. Any thoughts on that?

Regards, Christian

---

From: Christian Amsüss <[email-masked]>
Date: Wed, 20 Jul 2016 22:46:05 +0200

On Thu, Jul 21, 2016 at 05:41:17AM +1000, Christian Groves wrote:
> offset (e.g. "t": -10} case or just a time series increasing stride from the
> base time? Time series increasing only might minimise the implementation
> complexity but then the ability to map between negative time offset and
> stride would be lost. Any thoughts on that?

If we allow negative strides, we need to limit base time and stride time
to integers (something -- again -- I favor anyway). Otherwise, we're in
numeric elimination land and people will have expectations that just
fail.

Best regards
Christian