Subject: [core] duration type comments

From: Peter Bigot <[email-masked]>
Date: Thu, 26 Aug 2010 06:23:05 -0500

Rather than spend a lot of time on this one:

1. It is suggested that many options require a duration.  I could find only
two: subscription-lifetime and max-age.  Before determining the encoding,
the characteristics of these durations should be reviewed.  I suspect
virtually every use of subscription-lifetime will be either "forever" or
"stop".  What range of durations are reasonably expected for Max-Age for
resources that reflect measurements of real-world data?

2. While we could select an encoding that supports only those durations
we're thinking about now, I would prefer one that could handle other natural
uses of duration, like "how long until a scheduled event".  For that use, a
set of representable values that is not closed under subtraction is
unsuitable.

3. A detailed description of the subscription-lifetime option encoding in
variable-length-integer format takes one third of a page in
draft-hartke-coap-observe-02.  The pseudo-FP approach takes three pages to
motivate and describe, plus five pages to list its values.  It's a nice
solution, but any claim that this decreases complexity relative to
variable-length-integer is indefensible.

4. I'm not going to bother to implement this right now to see how much space
it takes, but if we continue to create novel encodings that require, for
example, three times as much ROM as a comparable straightforward encoding,
CoAP will be unimplementable on the very devices where it's most needed.

Peter

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 26 Aug 2010 15:09:57 +0200

On Aug 26, 2010, at 13:23, Peter Bigot wrote:

> 1. It is suggested that many options require a duration.  I could find only two: subscription-lifetime and max-age.  Before determining the encoding, the characteristics of these durations should be reviewed.  I suspect virtually every use of subscription-lifetime will be either "forever" or "stop".  What range of durations are reasonably expected for Max-Age for resources that reflect measurements of real-world data?

I don't have a scientifically grounded answer for that, but various discussions I have had so far indicate that 1 second to a couple of months is about the right range.

> 2. While we could select an encoding that supports only those durations we're thinking about now, I would prefer one that could handle other natural uses of duration, like "how long until a scheduled event".  For that use, a set of representable values that is not closed under subtraction is unsuitable.

It is always hard to design for unknown future requirements.
The duration type was indeed meant for soft-state/lifetime-like durations, not for anything approaching precise timing (there is no consideration of clock skew or leap seconds, for instance).

> 3. A detailed description of the subscription-lifetime option encoding in variable-length-integer format takes one third of a page in draft-hartke-coap-observe-02.  The pseudo-FP approach takes three pages to motivate and describe, plus five pages to list its values.  It's a nice solution, but any claim that this decreases complexity relative to variable-length-integer is indefensible.

This is a deliberately unfair statement.
I wrote expansive text, erring on the side of redundancy, when I noticed not every implementer has the CS background about number representations I would have expected.
A description of binary numbers at this level of detail would be about as long.
The actual description is five lines of C, four of which are constant definitions.

The reduced complexity comes from the reduced variability in length, not from a shorter description.
But maybe I'm the only one who sees that advantage.

> 4. I'm not going to bother to implement this right now to see how much space it takes, but if we continue to create novel encodings that require, for example, three times as much ROM as a comparable straightforward encoding, CoAP will be unimplementable on the very devices where it's most needed.

The implementation is in the draft.

I think the meta-observation here is that the technical advantages or disadvantages are mostly irrelevant where people are significantly more familiar with one way of doing things than with another way.  I do think that is an important consideration in protocol design.  I just wasn't prepared for such a reaction in this case.  (This is not about you, others had the same reaction.)  I'm willing to learn.

Gruesse, Carsten

---

From: Zach Shelby <[email-masked]>
Date: Thu, 26 Aug 2010 17:01:24 +0300

> I think the meta-observation here is that the technical advantages or disadvantages are mostly irrelevant where people are significantly more familiar with one way of doing things than with another…

It is true that this has more to do with the humans than machines, although the format does have limitations if used where it wasn't meant to be. I'm pretty neutral on this, but to concentrate energy on things we really need to work on like security - I suggest we stick with the variable length integer format for coap-observe and other durations.  

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297