Re: [icnrg] adopting ccnx-timetlv

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

Hello Marc,

thanks for your constructive feedback.  My comments follow below.

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

In earlier days of this document we were considering different
parameters (using more bits for mantissa vs. more for exponent, also
with 2 bytes).  We found the currently documented configuration (3 for
mantissa, 5 for exponent) to be a good compromise.  At least for the
operations "Interest lifetime" and "recommended cache time", the
precision between lower numbers, and the max range (up to 4 years) seem
practical enough for most use cases.

Given that the primary motivation of this feature was to reduce packet
overhead, we did not follow up on the multi-byte representations.
There's not much utility in using more bytes, since (in general-purpose
networks) we can always use the 4- and 8-byte linear versions to encode
large enough numbers with millisecond granularity.

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

Very good point.  I'll take a closer look at your approximations and
will add them to the appendix as implementation guidance.

Cheers,
Cenk

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