Subject: [icnrg] Fwd: New Version Notification for draft-gundogan-icnrg-ccnx-timetlv-01.txt

From: Cenk Gündoğan <[email-masked]
Date: Mon, 09 Mar 2020 20:00:48 +0100

Dear ICNRG,

we updated our CCNx Time TLV draft to include the following changes:

* we removed the previously included discussion on using a time base TLV
  for (absolute) RecommendedCacheTime (RCT) TLVs in content objects. The
  current approach interprets RCT as absolute (normal behavior) for UTC
  timestamps (8 octets), and as relative for a compact timestamp (1
  octet).

* we added an explicit configuration for exponent, mantissa, and bias to
  Section 4. That configuration yields a milli second resolution for
  lower time values and can also (with low resolution) reaches values
  has high as ~4 years.

* we added a few alternatives to section 5 (CCNx protocol integration)
  to provide more material for discussions. This topic needs to converge
  to a distinct solution, though.

As always, any feedback is highly appreciated.

Cheers,
Cenk

On Mon, Mar 09 2020 at 19:42 +0100, [email-masked] wrote:

> A new version of I-D, draft-gundogan-icnrg-ccnx-timetlv-01.txt
> has been successfully submitted by Cenk Gundogan and posted to the
> IETF repository.
>
> Name:		draft-gundogan-icnrg-ccnx-timetlv
> Revision:	01
> Title:		An Alternative Delta Time encoding for CCNx using Interval Time from RFC5497
> Document date:	2020-03-09
> Group:		Individual Submission
> Pages:		8
> URL:            https://www.ietf.org/internet-drafts/draft-gundogan-icnrg-ccnx-timetlv-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-gundogan-icnrg-ccnx-timetlv/
> Htmlized:       https://tools.ietf.org/html/draft-gundogan-icnrg-ccnx-timetlv-01
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-gundogan-icnrg-ccnx-timetlv
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-gundogan-icnrg-ccnx-timetlv-01
>
> 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 RFC5497.  This document updates _CCNx messages in TLV
>    Format_ (RFC8609) to specify this alternative encoding.
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat

--
Cenk Gündoğan

Hamburg University of Applied Sciences
Dept. of Computer Science / Internet Technologies Group
Berliner Tor 7, 20099 Hamburg, Germany
Fon: +49 40 42875 - 8426
Mail: [email-masked]
Web: https://www.inet.haw-hamburg.de/

---

From: "Mosko, Marc <[email-masked]>" <[email-masked]>
Date: Tue, 10 Mar 2020 06:09:39 +0000

I think this draft is very clear and easy to follow.  The only addition I would make is to include an appendix with a few test vectors, say 0, a subnormal, and a normal or two.  Or put them in the main text as examples.

One question to consider is, would there be more possible time encodings beyond this?  Do we need a way to clearly distinguish between time encodings for fields, or is inferring the encoding based on the length acceptable?  I would probably rule out a nested encoding, as that is counter-productive when trying to introduce a 1 byte scheme. 

Marc

On 3/9/20, 12:03 PM, "icnrg on behalf of Cenk Gündoğan" <[email-masked] on behalf of mail=2Bietf=[email-masked]> wrote:

    Dear ICNRG,

    

    
    Cheers,
    Cenk

    --
    Cenk Gündoğan

---

From: Cenk Gündoğan <[email-masked]>
Date: Wed, 11 Mar 2020 12:20:04 +0100

Hello Marc,

> I think this draft is very clear and easy to follow.  The only addition I would make is to include an appendix with a few test vectors, say 0, a subnormal, and a normal or two.  Or put them in the…

There are a few numbers in section 4:
   o  Minimum subnormal number: 0 seconds
   o  Maximum subnormal number: ~0.054688 seconds
   o  Minimum normalized number: ~0.062500 seconds
   o  Maximum normalized numbers: [~3.46, ~3.72, ~3.99] years

we can put a few more into the appendix to show how the resolution
degrades with higher numbers. That would be a good addition to the
document.

> One question to consider is, would there be more possible time encodings beyond this?  Do we need a way to clearly distinguish between time encodings for fields, or is inferring the encoding based…

+1 to ruling out the nested TLV approach.

Currently, there are only two TLVs that benefit from the compact
timestamp encoding: InterestLifetime and RCT (in relative time form).

For these, the currently defined, positive-only, 1-octet configuration
(exponent=5,mantissa=3,bias=-5) is IMO sufficient. Using the TLV-Length
as an indicator (L==1) has the advantage of being quite unobtrusive. It
is not very flexible and extensible, though (as you pointed out).

For future relative-time TLVs, we can also define another
(sign,exponent,mantissa,bias) configuration (for L==1), if they require
different properties, e.g., negative number support, microsecond
resolution .. I currently cannot think of a reasonable use case that
requires multiple configurations for a single relative-time TLV.

We could also opt for a flat structure: New InterestLifetime / RCT /
... upper-level TLVs that reside next to the original TLVs (guarded with
an exclusive or, since only one encoding for InterestLifetime / RCT /
... shall be used at the same time). This would require an update to the
message structure BNF ..

Cheers,
Cenk

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

---

From: "Mosko, Marc <[email-masked]>" <[email-masked]>
Date: Thu, 12 Mar 2020 03:31:15 +0000

For the test vectors, I was thinking of something mind numbingly simple, such as

Value		Encoding
0		0x00
0.031250	0x04
0.062500	0x08
0.203125	0x15
1.000000	0x28
2.000000	0x30
67108864.0	0xF8
125829120.0	0xFF

It would also be useful to have written out the algorithm to encode a number.  Here's a basic swipe that it, but one needs to define the floor/ceiling/rounding used for m, which I did not include.  IEEE 754 defines a few different roundings.  I believe the default is round to nearest, with ties going to the one with an even last significant digit.  In any case, you need to pick one.  

On most cpus, floor(log2(v)) is a simple and quick bit counting instruction, and the exponents are bit shifting, so I bet one could implement the algorithm with nothing but rotates, adds, subtracts, and bit counting.  Maybe including an efficient x86 version of the algorithm using C intrinsics would be nice.

Encode(v)
If v = 0 then 
	return (0,0)
e = max(0, floor(log2(v))-b)
If v < 0.0625 then 
	m = (v/2^(1+b)) * m_max
	m = (v/2^(e+b) - 1) * m_max
return (e,m)

As m_max is 8 (2^3), one could simplify those equations a little.

Marc

On 3/11/20, 4:20 AM, "icnrg on behalf of Cenk Gündoğan" <[email-masked] on behalf of mail=2Bietf=[email-masked]> wrote:

    Hello Marc,

    

    

    
    
    We could also opt for a flat structure: New InterestLifetime / RCT /
    .... upper-level TLVs that reside next to the original TLVs (guarded with
    an exclusive or, since only one encoding for InterestLifetime / RCT /
    .... shall be used at the same time). This would require an update to the
    message structure BNF ..
    
    Cheers,
    Cenk
    
    >
    > Marc
    >
    > On 3/9/20, 12:03 PM, "icnrg on behalf of Cenk Gündoğan" <[email-masked] on behalf of mail=2Bietf=40gundogan.net@dmarc..ietf.org> wrote:
    >
    >     Dear ICNRG,
    >

---

From: Junxiao Shi <[email-masked]>
Date: Thu, 12 Mar 2020 00:02:13 -0400

Hi Cenk

Section 7 has a bad link in:
This document makes no semantic changes to *RFC8965*

Yours, Junxiao

On Mon, Mar 9, 2020, 15:03 Cenk Gündoğan <mail=2Bietf=
[email-masked]> wrote:

> > URL:
> https://www.ietf.org/internet-drafts/draft-gundogan-icnrg-ccnx-timetlv-01.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-gundogan-icnrg-ccnx-timetlv/
> > Htmlized:
> https://tools.ietf.org/html/draft-gundogan-icnrg-ccnx-timetlv-01
> > Htmlized:
> https://datatracker.ietf.org/doc/html/draft-gundogan-icnrg-ccnx-timetlv
> > Diff:
> https://www.ietf.org/rfcdiff?url2=draft-gundogan-icnrg-ccnx-timetlv-01
> >
> > Abstract:

---

From: Cenk Gündoğan <[email-masked]>
Date: Thu, 12 Mar 2020 10:16:19 +0100

Hello Junxiao,

> This document makes no semantic changes to *RFC8965*

thank you. I amended a fix to the src repository [1].

[1] https://github.com/icnrg/draft-gundogan-icnrg-ccnx-timetlv

Cheers,
Cenk

>> https://www.ietf.org/internet-drafts/draft-gundogan-icnrg-ccnx-timetlv-01..txt
>> > Status: