Re: [icnrg] Directions on CCNx TimeTLVs: draft-gundogan-icnrg-ccnx-timetlv

[Cenk Gündoğan <[e-mail]>]

Hello Marc,

On Sat, Nov 23 2019 at 02:04 +0100, Mosko, Marc wrote:
>     I put together this little visualization [2] to show the ranges of
>     different time encodings. I assume an 8-bit float without sign bit and
>     exponent bias. The legend shows configurations in the typical form:
>     (sign bits, exponent bits, mantissa bits, bias).
>
> Great!  I was thinking of doing that myself.  Are you still assuming that 0x00 is defined as 0 (instead of 1)?  I guess I'm asking would one use denormalized numbers with a 0 exponent?
>
>     Let's assume that a time value represents seconds. Then we are obviously
>     not able to represent sub-second floats. Though, milliseconds might be
>     interesting for some use cases (e.g., to quickly delete a PIT trail for
>     unsatisfied, but time-sensitive data).
>
>     The configurations (0,3,5,0) and (0,6,2,0) have IMO either a very low
>     range, or a rather unnecessarily huge range.
>
>     (0,4,4,0) can at max represent ~17 hours (63488 seconds).
>     (0,5,3,0) has a max time value of ~127 years (4026532000 seconds).
>
>     If we assume milliseconds as base unit, then above values change to:
>
>     (0,4,4,0): max ~1 minute
>     (0,5,3,0): max ~46 days
>
>     ~46 days as a max value for lingering PITs are IMO reasonable .. and we
>     gain 80 sub-second values (out of 255 possible time codes).
>
>     In previous slides there was also the constant C set to (1/1024). The
>     beauty of having (1/1024) instaed of (1/1000, milliseconds) as base is
>     that it yields integer values in the seconds range for power-of-2 values
>     (1s,2s,4s,...). An application would more likely want to encode "4s",
>     instead of "4.096s".
>
> Yes, the ~46 day range /1000 or /1024 sounds like a good option for things like expiry time or cache time, especially for the IoT environment.
>
> If you denormalize (0,6,3,0), the 0 exponent values are 0.00, 0.25, 0.50, 0.75, 1.00, 1.25, 1.50, 1.75 without playing with a C factor.  If you denormalize (0,4,4,0), it goes in 1/8th increments from [0 .. 4], then in 1/4th [4,8], then 1/2th [8,16], etc.

I did include subnormal numbers in [1]. If we go with seconds as base
unit (and without a C constant), then I get the same values you wrote.

With this setup, we would have a maximum value of ~17 hours for
(0,4,4,0) and ~127 years for (0,5,3,0). 17 hours might be a little less
.. and 127 years a little bit too much.

Instead, we could also apply a bias to (0,5,3,0), let's say -7. This
yields a maximum value of roughly 1 year. At the same time, it allows us
to encode a few more sub-second values (starting at ~1.9 ms).

What do you think about (0,5,3,-7)? Are 56 sub-seconds values too much?

[1] https://cgundogan.github.io/minifloat/

>
>     I like the idea of using an IEEE half precision float for the 16-bit
>     variant.
>
>     The next question (to the group) is how we want to encode them:
>     T_INTLIFE is actually unbounded (as per RFC). It can use a time value of
>     arbitrary octets, although the usefulness for 1- and 2-octet time values
>     in milliseconds is questionable [3]. So, this TimeTLV draft would not
>     just add new functionality, but would *replace* the current behavior, if
>     we use it in T_INTLIFE with Length==1 OR LENGTH==2. Is that something we
>     want?
>

Any ideas or concerns regarding the integration? Is replacing the
existing functionality defined in the CCNx RFC desireable?

Cheers,
Cenk

>     Cheers,
>     Cenk
>
>     [2] https://cgundogan.github.io/minifloat/
>     [3] https://github.com/icnrg/draft-gundogan-icnrg-ccnx-timetlv/issues/3
>
>     > Marc
>     >
>     >
>     > On 11/19/19, 8:12 PM, "icnrg on behalf of Thomas C. Schmidt" <[e-mail] on behalf of [e-mail]> wrote:
>     >
>     >     Folks,
>     >
>     >     following up on our presentation of draft-gundogan-icnrg-ccnx-timetlv:
>     >
>     >     This proposes to replace time deltas in CCNx by logarithmic encodings
>     >     and (maybe) some absolute timer values by deltas w.r.t. the signature time.
>     >
>     >     We solicit feedback: Do you agree on going this way, or do you suspect
>     >     this to be harmful?
>     >
>     >     Best,
>     >       Thomas
>     >     --
>     >
>     >     Prof. Dr. Thomas C. Schmidt
>     >     ° Hamburg University of Applied Sciences                  Berliner Tor 7 °
>     >     ° Dept. Informatik, Internet Technologies Group   20099 Hamburg, Germany °
>     >     ° http://inet.haw-hamburg.de/members/schmidt      Fon: [phone] °
>     >
>     >     _______________________________________________
>     >     icnrg mailing list
>     >     [e-mail]
>     >     https://www.irtf.org/mailman/listinfo/icnrg
>     >
>     >
>     > _______________________________________________
>     > icnrg mailing list
>     > [e-mail]
>     > https://www.irtf.org/mailman/listinfo/icnrg
>
>
> _______________________________________________
> icnrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/icnrg