Re: [icnrg] adopting ccnx-timetlv

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

Hello Marc,

the new version of the document includes a section in the appendix on
efficiently converting the compact time [1].

We mostly followed the comments from your mail below.  However, we did a
couple of changes and I'd appreciate your feedback on these:

1. Since CCNx is working with milliseconds and not microseconds, we did
   adjust the exponent for conversion from 2^20 to 2^10.

2. Converting to milliseconds, the error is only ~2.4%

3. Because of the smaller error, we did not include the correction terms
   in the current text.  One problem with the correction terms was that
   (due to the small range of the mantissa, 3 bits), shifting it by more
   than 3 bits would result in loss of information.

Cheers,
Cenk

[1] https://www.ietf.org/archive/id/draft-irtf-icnrg-ccnx-timetlv-00.html#appendix-B

On Mon, Apr 11 2022 at 17:23 +0000, Marc Mosko wrote:

> A late reply, but I support adopting this update.  I also favor updating 8609, because one needs to update routers anyway, either for the new
> TLV or for the new LEN=1 semantics.
>
>  
>
> Has there been consideration of also allowing 2 or 4 bytes representations?  Do those offer any advantages to counter added complexity?  I only
> mention this because if you’re going to update the spec, maybe make it more comprehensive.
>
>  
>
> The common operation is to convert the compact representation into microseconds, so a forwarder can make a comparison.  I would
> recommend adding (in an appendix?) equations to convert (a,b) into microseconds using all integer operations (shifts, plus, minus), or at least a
> good approximation to binary microseconds (2^-20).  It should not be required for a forwarder to do floating point operations on a packet.  We
> should make it easy for an implementor to do the right thing.
>
> I believe these are the approximate equations for the time in microseconds:
>
> (b = 0): a << 17
>
> (b > 0): (2^20 + a << 17) << b >> 5
>
>  
>
> Except for the (0,0) case, these estimates will always be 4.86% over the actual value.  One can reduce that to a -1.7% error by subtracting E>>4
> from the estimate E
>
>  
>
> (b=0): (a << 17) – (a << 13)
>
> (b>0): (2^20 + a << 17) << b >> 5 – ((2^20 + a << 17) << b >> 9)
>
>  
>
> Of course, one could keep adding more correction terms, but I doubt it’s worth the effort.
>
>  
>
> Marc
>
>  
>
>  
>
> From: icnrg <[e-mail]> on behalf of Dirk Kutscher <[e-mail]>
> Date: Monday, April 11, 2022 at 3:25 AM
> To: ICNRG <[e-mail]>
> Subject: Re: [icnrg] adopting ccnx-timetlv
>
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and
> know the content is safe.
>
>  
>
> Hello ICNRG,
>
> we have not heard of any concerns, so let's adopt this document.
>
> Cenk and co-authors, please submit your next revision as draft-irtf-icnrg-ccnx-timetlv-00.
>
> Thanks,
> Dirk
>
> On 29 Mar 2022, at 14:36, Dirk Kutscher wrote:
>
>  Hello ICNRG,
>
>  as discussed at last week's ICNRG meeting, we are considering to adopt draft-gundogan-icnrg-ccnx-timetlv as a RG work item.
>
>  Title: Alternative Delta Time Encoding for CCNx Using Compact Floating-Point Arithmetic
>
>  Abstract:
>  CCNx utilizes delta time for a number of functions. When using CCNx
>  in environments with constrained nodes and/or bandwidth constrained
>  networks, it is valuable to have a compressed representation of delta
>  time. In order to do so, either accuracy or dynamic range has to be
>  sacrificed. Since the current uses of delta time do not require both
>  simultaneously, one can consider a logarithmic encoding such as that
>  specified in [IEEE.754.2019]. This document updates CCNx messages
>  in TLV Format (RFC8609) to specify this alternative encoding.
>
>  ·         Cenk's presentation from last week
>
>  ·         draft-gundogan-icnrg-ccnx-timetlv
>
>  Please let us have any feedback (support, doubts etc.) until end of next week, i.e., Friday, 2022-04-08.
>
>  Thanks,
>  Dirk and Dave
>
> -------------------------------------------------------------------------------------------------------------------------
>
>  icnrg mailing list
>  [e-mail]
>  https://www.irtf.org/mailman/listinfo/icnrg
>
> _______________________________________________
> icnrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/icnrg