References: <73a5a9ff-03c2-3b63-576d-8811c84b90c4@haw-hamburg.de>
 <9AB2EAD4-4458-4BD3-B263-A8C9BDAAB25B@parc.com> <87r21zy7ba.fsf@gundogan.net>
 <2823BFCD-3228-4E8D-8B7F-D27C9FF046CA@parc.com>
User-agent: mu4e 1.2.0; emacs 26.3
From: Cenk =?utf-8?B?R8O8bmRvxJ9hbg==?= <mail+ietf@gundogan.net>
To: icnrg@irtf.org
In-reply-to: <2823BFCD-3228-4E8D-8B7F-D27C9FF046CA@parc.com>
Date: Mon, 25 Nov 2019 12:37:25 +0100
Message-ID: <87blt0191m.fsf@gundogan.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
 micalg=pgp-sha256; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/4OWtt5xNCjrktDtB9Ai1J6pqRL4>
Subject: Re: [icnrg] Directions on CCNx TimeTLVs:
 draft-gundogan-icnrg-ccnx-timetlv
Precedence: list

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

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 den=
ormalized numbers with a 0 exponent?
>
>     Let's assume that a time value represents seconds. Then we are obviou=
sly
>     not able to represent sub-second floats. Though, milliseconds might be
>     interesting for some use cases (e.g., to quickly delete a PIT trail f=
or
>     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 val=
ues
>     (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 thing=
s 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 deno=
rmalize (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 val=
ues
>     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=3D=3D1 OR LENGTH=3D=3D2. Is that s=
omething 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" <icnrg=
-bounces@irtf.org on behalf of t.schmidt@haw-hamburg.de> wrote:
>     >
>     >     Folks,
>     >
>     >     following up on our presentation of draft-gundogan-icnrg-ccnx-t=
imetlv:
>     >
>     >     This proposes to replace time deltas in CCNx by logarithmic enc=
odings
>     >     and (maybe) some absolute timer values by deltas w.r.t. the sig=
nature 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
>     >     =C2=B0 Hamburg University of Applied Sciences                  =
Berliner Tor 7 =C2=B0
>     >     =C2=B0 Dept. Informatik, Internet Technologies Group   20099 Ha=
mburg, Germany =C2=B0
>     >     =C2=B0 http://inet.haw-hamburg.de/members/schmidt      Fon: +49=
-40-42875-8452 =C2=B0
>     >
>     >     _______________________________________________
>     >     icnrg mailing list
>     >     icnrg@irtf.org
>     >     https://www.irtf.org/mailman/listinfo/icnrg
>     >
>     >
>     > _______________________________________________
>     > icnrg mailing list
>     > icnrg@irtf.org
>     > https://www.irtf.org/mailman/listinfo/icnrg
>
>
> _______________________________________________
> icnrg mailing list
> icnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/icnrg

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEO3dMsPVVAdvZ+Oc2o9vC90TUhNIFAl3bvPUACgkQo9vC90TU
hNJ8+RAAixvmGQG3nY4Fw5ISCkfRZRnCD/n1sY37TaXr9PBhNvm0WCVHmIrwXZvq
R9Qjx+VrCWORBZ9ejquPu4Q+6NTS1+D3KZU6GNV6hek03Guynb/gIwVnyp3gWSrU
CwuOoki9ly7aeHm3RlYWmzzKjudQ/RD03FAHp10oG5ah72qIamW01anImaQFsr68
zupQPTUYraL5XoS5SfP6HffMt7dPVXMA6M5wvkeoFnPNJxxgaocWR9oigLmKSyMy
1kITNicapu4PgCYykPqNFLp57omZt0Xza2wKwut4t6YP7iSN+KUihZdA96XZSoxH
9hqMVFQGQCVVWvWjaerGdrVzK2K9VzI4CjUfbxjRLJCj+lkBAmH+9yq17q3/t/9c
13Hc+Jm+SaWEvAacrE+SEPeckq7yAYkKrHkWYFV/oCuFPsJFAEfxzBiIel7ybXWw
8QPLTssVcwKeaE0J9KJyar76S7J3lTqurO9ygeeWaDhd3ed9Ops6kgXqpkprl7Ko
OYZ3gf5scjRpsbvpN6yKa29oRd6wrUs5t8Z+hbjj1uVbKKo/nOVuxqeU0TBbo2OF
iPBSm3cYVjOLxmLDqLT61wZc75HJGxST1kgEOVF/Qtye7UecBe17CEMcIBeLXMCt
4HtPl4DBI15Q6cgyHnTetw9QIdyZcwH2R38GwG+9CymNFHdoNXM=
=G1eI
-----END PGP SIGNATURE-----
--=-=-=--