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

["Mosko, Marc <[e-mail]>" <[e-mail]>]

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" <[e-mail] on behalf of mail=2Bietf=[e-mail]> wrote:

    Hello Marc,
    
    On Tue, Mar 10 2020 at 07:09 +0100, Mosko, Marc wrote:
    
    > 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.
    
    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 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.
    
    +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
    
    >
    > Marc
    >
    > On 3/9/20, 12:03 PM, "icnrg on behalf of Cenk Gündoğan" <[e-mail] on behalf of mail=2Bietf=40gundogan.net@dmarc..ietf.org> wrote:
    >
    >     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, [e-mail] 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: [phone] - 8426
    >     Mail: [e-mail]
    >     Web: https://www.inet.haw-hamburg.de/
    >
    >
    > _______________________________________________
    > icnrg mailing list
    > [e-mail]
    > https://www.irtf.org/mailman/listinfo/icnrg