Subject: Re: [icnrg] adopting ccnx-timetlv

From: Dirk Kutscher <[email-masked]>
Date: Mon, 11 Apr 2022 12:25:24 +0200

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](https://datatracker.ietf.org/meeting/113/session/icnrg), we are considering to adopt [draft-gundogan-icnrg-ccnx-timetlv](https://datatracker.ietf.org/doc/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](https://datatracker.ietf.org/meeting/113/materials/slides-113-icnrg-alternative-delta-time-encoding-for-ccnx-01)
> * [draft-gundogan-icnrg-ccnx-timetlv](https://datatracker.ietf.org/doc/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
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg

---

From: Marc Mosko <[email-masked]>
Date: Mon, 11 Apr 2022 17:23:30 +0000

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 <[email-masked]> on behalf of Dirk Kutscher <[email-masked]>
Date: Monday, April 11, 2022 at 3:25 AM
To: ICNRG <[email-masked]>
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,

Thanks,
Dirk

Hello ICNRG,

as discussed at last week's ICNRG meeting<https://datatracker.ietf.org/meeting/113/session/icnrg>, we are considering to adopt draft-gundogan-icnrg-ccnx-timetlv<https://datatracker.ietf.org/doc/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<https://datatracker.ietf.org/meeting/113/materials/slides-113-icnrg-alternative-delta-time-encoding-for-ccnx-01>
·         draft-gundogan-icnrg-ccnx-timetlv<https://datatracker.ietf.org/doc/draft-gundogan-icnrg-ccnx-timetlv/>

Thanks,
Dirk and Dave

________________________________

icnrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/icnrg

---

From: Cenk Gündoğan <[email-masked]>
Date: Mon, 11 Apr 2022 22:49:49 +0200

Hello Marc,

thanks for your constructive feedback.  My comments follow below.

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

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

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

Cheers,
Cenk

>  as discussed at last week's ICNRG meeting, we are considering to adopt draft-gundogan-icnrg-ccnx-timetlv as a RG work item.
>
>  ·         Cenk's presentation from last week
>
>  ·         draft-gundogan-icnrg-ccnx-timetlv
>
> -------------------------------------------------------------------------------------------------------------------------
>
>  icnrg mailing list
>  [email-masked]