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

Cenk Gündoğan <mail+ietf@gundogan.net> Mon, 25 November 2019 11:37 UTC

Return-Path: <mail+ietf@gundogan.net>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27CF4120914 for <icnrg@ietfa.amsl.com>; Mon, 25 Nov 2019 03:37:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (bad RSA signature)" header.d=gundogan.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvxOgD2ZVJyW for <icnrg@ietfa.amsl.com>; Mon, 25 Nov 2019 03:37:28 -0800 (PST)
Received: from mail.localdomain (trantor.gundogan.net [37.120.167.193]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71DA412090F for <icnrg@irtf.org>; Mon, 25 Nov 2019 03:37:28 -0800 (PST)
Received: from localhost (unknown [141.22.28.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by mail.localdomain (Postfix) with ESMTPSA id B5D8929362 for <icnrg@irtf.org>; Mon, 25 Nov 2019 12:32:31 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gundogan.net; s=201712; t=1574681551; bh=5jIg6WIhcsvxIilA0SEE3ldve9BG0//zbjHLGEZdt5Y=; h=References:From:To:Subject:In-reply-to:Date:From; b=o6wl/u47nGad6aFSVW4/qqI3jBYoQKU8I499XiZfJnFZpkV1jvST0EGx6IBStgrGV 9JVPVxJoJCviPAACAAubGzLKjLMmZwJgHh2lSCNMIzeNV/pYC+iXLLKA9m6mm3uuE4 C8OFRBX0LkG8v/+NCv4VIqvZs3gIoirmaXFUPdCJtWa10AyMtZtR52tplagm88nfHd 3mlysdPSYLv0b+LNzegT4Y0q/N6QaZCuLBOwVxVvQj4mFO3amugxYET0K3YEgvusjt KBazDo2HCSyergWEH2uVYsS5Ivn9azZrmtuaZafmFveZgJGs9h01bikCxKfaIFA/lR dQgjnSEz/pmEw==
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
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Nov 2019 11:37:30 -0000

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" <icnrg-bounces@irtf.org on behalf of t.schmidt@haw-hamburg.de> 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: +49-40-42875-8452 °
>     >
>     >     _______________________________________________
>     >     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