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

Cenk Gündoğan <> Fri, 22 November 2019 20:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 80AD41200EC for <>; Fri, 22 Nov 2019 12:39:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Status: No, score=-1.699 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, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (2048-bit key) reason="fail (bad RSA signature)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2R4TIQ4-JNWI for <>; Fri, 22 Nov 2019 12:39:39 -0800 (PST)
Received: from mail.localdomain ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 857051200BA for <>; Fri, 22 Nov 2019 12:39:39 -0800 (PST)
Received: from localhost ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by mail.localdomain (Postfix) with ESMTPSA id 9ACF929181 for <>; Fri, 22 Nov 2019 21:34:48 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=201712; t=1574454888; bh=KJV6kjJekSGZcpTbKfGbt6aPl6Rr8hlXm6QzxxOu1BM=; h=References:From:To:Subject:In-reply-to:Date:From; b=EVllqEVEoD89zVB6kKtiOFvKZ2qDGAcipmkEWCZYvCiIOMwnyVyOBaiWfwkWYM2TG NFlO9t7W9MzD0V3hqgKvplVY8ELo1K1uWzTiJdx+CMZ8tnAl+9exKLEYDnDZLn03z5 xrBFebPg7naxp44XuyKBm3/27D0trCBqS05Qz0bfKjX/gYosvijEFAyJCsNts4+WBr 4nqTFk5yO2MOPVVye++KdE+JHLftsNlIhVxYDmuwAccHb/TzwFEZnXDACjrjxjKWEM NTb5mJPJOVtBasnqGZlWwiQu7t1pKl1nxXDY5VfFkHj+Ag39wBDbdz5bSMn7u347hc JWyCi+psdlF0Q==
References: <> <>
User-agent: mu4e 1.2.0; emacs 26.3
From: Cenk Gündoğan <>
In-reply-to: <>
Date: Fri, 22 Nov 2019 21:39:21 +0100
Message-ID: <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: <>
Subject: Re: [icnrg] Directions on CCNx TimeTLVs: draft-gundogan-icnrg-ccnx-timetlv
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 22 Nov 2019 20:39:42 -0000

Hello Marc,

thank you for the feedback. I have a couple of comments and questions
inlined below.

On Wed, Nov 20 2019 at 07:25 +0100, Mosko, Marc wrote:

> Thomas,
> I think having more compact encodings is great!  Here's a few comments on draft-gundogan-icnrg-ccnx-timetlv-00.
> 1) The caption of Fig 3 cites RFC 4574.  Is that correct?  It's also not in the references section.

Thanks .. that definitely does not belong there.

> 2) RFC 5497 is not definitive in the representation of 1 or 2 byte floats, as C must be specified.  In your draft, it would be good to have a section that completely spells out how to go from a timestamp to/from mini/half floats.
> 3) I agree that playing with the signature time might have unintended security consequences.  The signature time might also be unrelated to other time fields in the packet as it might be generated independently of the content itself, so using it as a time base is not a good idea either.

hm, both, the expiry and signature times in Content Objects are part of
the security envelope. There is a strong relation between the expiry and
signature times once a signature is generated. I assume that expiry time
is also always > signature time, because of the following quote from

 The ExpiryTime is a field that exists within the signature envelope
 of a Validation Algorithm.  It is the UTC time in milliseconds after
 which the Content Object is considered expired and MUST no longer be
 used to respond to an Interest from a cache.  Stale content MAY be
 flushed from the cache.

If I am not mistaken, then there should never be expired Content Objects
in the network. Expiry time can therefore be expressed as a (positive
only) time delta to the signature time .. or is there any valid use case
where expired Content Objects get a new signature (and therefore have an
expiry time < signature time)?


> 4) If the RCT becomes relative, then a cache should decrement it.  I'm not a big fan for using relative times here, but it could be done.  I had written up an idea on allowing relative times as an alternative to absolute times in
> 5) I think fractions of a second are not important for fields like interest lifetime or RCT, so the exponent does not need to support negatives.  Removing a sign bit and keeping the exponent positive with a normalized form mantissa would have a fairly large range, at least for the 8-bit (a 0.4.4.-0 minifloat).  The 16-bit should keep all the bells and whistles as it has space, and you'd likely use IEEE half precision floats anyway?

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).

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".

I like the idea of using an IEEE half precision float for the 16-bit

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



> Marc
> On 11/19/19, 8:12 PM, "icnrg on behalf of Thomas C. Schmidt" < on behalf of> 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 °
>     °      Fon: +49-40-42875-8452 °
>     _______________________________________________
>     icnrg mailing list
> _______________________________________________
> icnrg mailing list