Re: [icnrg] Directions on CCNx TimeTLVs: draft-gundogan-icnrg-ccnx-timetlv

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

Replies below.  I edited down the history to make it a bit more concise.

On 11/25/19, 3:37 AM, "icnrg on behalf of Cenk Gündoğan" <[e-mail] on behalf of mail=2Bietf=[e-mail]> wrote:
    >
    > If you denormalize (0,6,3,0), the 0 exponent values are 0.00, 0.25, 0.50, 0.75, 1.00, 1.25, 1.50, 1.75 without playing with a C factor.  If you denormalize (0,4,4,0), it goes in 1/8th increments from [0 .. 4], then in 1/4th [4,8], then 1/2th [8,16], etc.
    
    I did include subnormal numbers in [1]. If we go with seconds as base
    unit (and without a C constant), then I get the same values you wrote.
    
    With this setup, we would have a maximum value of ~17 hours for
    (0,4,4,0) and ~127 years for (0,5,3,0). 17 hours might be a little less
    ... and 127 years a little bit too much.
    
    Instead, we could also apply a bias to (0,5,3,0), let's say -7. This
    yields a maximum value of roughly 1 year. At the same time, it allows us
    to encode a few more sub-second values (starting at ~1.9 ms).
    
    What do you think about (0,5,3,-7)? Are 56 sub-seconds values too much?
    
I think the (0,5,3, [-5, ... -7]) range looks good.  -5 is just under 4 years, -7 is just under 1 year.  At the low end -5, is about 8msec resolution, whereas -7 is about 2 msec.  -6 is ~ 2 years range and about 4 msec resolution at the low end.

For expiry time, I think 1 second resolution is plenty, and 4 years (for IoT use case) is also pretty good, considering that one could use a 2-byte or 8-byte value if one really needed more.   Same for recommended cache time.

For Interest lifetime, I personally are not a fan of trying to use very short Internet lifetime for PIT expiry at packet RTTs -- it's too easy for the standard deviation of arrival times to make small values counter-productive.  So I'm OK with a lower resolution like -5 vs -7 to get more range.

I think I would tend to let the 1-byte minifloat be less precise and have more range.  If one really needs precision, then use a 2-byte half float.

For the 2-byte encoding, I suggested using the standard IEEE half-float, but I now realize that it uses a -15 bias, so the maximum value is only 65519.  Maybe we want to use something more like (1, 5, 10, -12) or something to get more range if we are using seconds as the unit.  I've not plotted out the values for this.

These encodings work for relative times.  We still need to conjure up a time base.  Interest Lifetime is already a relative value, so that works OK.  The cache times either need a time base or we need to allow a relative encoding using Age style fields.  

Here are some options for relative times.  I think I prefer #1 or #4, but it needs more thinking through.

1) 2-byte encoding:  <1-byte uint8_t offset from year 2000> + <1-byte mini-float> or 3-byte encoding <1-byte offset from year 2000> + <2-byte half float>.  This would use the 0th second of year 2000, 2001, ..., 2255 as the base of the mini/half float.  If the spec survives until year 2200 or so, we can update the definition __  If one uses (0, 5, 3, -7), you get pretty good resolution over the 1-year time bases.  I'm not convinced one needs the 3-byte encoding using this method.

2) Define a new TimeBase field to designate the year to use as the base and keep the other encodings as 1-byte or 2-bytes. The TimeBase would define the offset to the year epoch (say a year 2000 base?).  This requires an extra 4 bytes of TLV overhead so it would be at least +5 bytes, whereas encoding the year base in #1 is only +1 or +2 extra bytes (2 extra bytes if you have both ExpiryTime and RCT).  Or #4 that requires 0 extra bytes.

3) Use an exponential timebase, such as 2000 + 2^(n/k), where we get to pick the constant k.  As opposed to the additive method in #1 or #2, this is essentially unbounded. One could even choose a smaller offset, like 1900 instead of 2000.  This gets pretty complicated and very poor precision as the years go out in the future.

4) Use (0, 5, 3, 0) relative to year 2000 (i.e. years 2000 - 2127), or (0, 5, 3, +1) relative to 2000 for times in years 2000 - 2255.  Small encoding, but poor resolution as you go out in years.

5) Use an Age-style relative cache time.

    >     The next question (to the group) is how we want to encode them:
    >     T_INTLIFE is actually unbounded (as per RFC). It can use a time value of
    >     arbitrary octets, although the usefulness for 1- and 2-octet time values
    >     in milliseconds is questionable [3]. So, this TimeTLV draft would not
    >     just add new functionality, but would *replace* the current behavior, if
    >     we use it in T_INTLIFE with Length==1 OR LENGTH==2. Is that something we
    >     want?
    >
    
    Any ideas or concerns regarding the integration? Is replacing the
    existing functionality defined in the CCNx RFC desireable?

I am hesitant to have the type of a value determined by its length -- for both Interest Lifetime and the cache times.  But I am not coming up with a more cleaver solution.

For hash values, we used a TLV inside a TLV.  That's 4 extra bytes to define the hash type, but that is relative to 32-byte (256 bit) values, so the relative overhead is not too bad.  But a TLV inside a TLV does not make sense for 1 or 2 byte values.

One could do a self-describing Number type, such as with a 4-bit or 8-bit header, then re-define various TLVs to use the Number type encoding.  This would let us encode all the standard formats (uint8_t, int8_t, uint16_t, ..., int64_t, float32, float64, (0, 5, 3, 0) float, ...).  This means that Number type TLVs would always be, say, 1-byte larger than the encoding, but you get a lot of flexibility.  An more importantly, the type is no longer defined by the length.  It also means that you can use whatever encoding is most suitable for the field usage for any particular message.  The downside is that comparisons can no longer be done with memcmp() in many cases.  On the bright side, the fast path of the forwarder does not evaluate any of the time fields, so it is only a hit on end systems or caches or firewalls filtering on values.

Marc