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

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

On 11/22/19, 12:39 PM, "icnrg on behalf of Cenk Gündoğan" <[e-mail] on behalf of mail=2Bietf=[e-mail]> wrote:

    Hello Marc,
    
    thank you for the feedback. I have a couple of comments and questions
    inlined below.
    
    On Wed, Nov 20 2019 at 07:25 +0100, Mosko, Marc wrote:
    
    > Thomas,
    >
    > I think having more compact encodings is great!  Here's a few comments on draft-gundogan-icnrg-ccnx-timetlv-00.
    >
    > 1) The caption of Fig 3 cites RFC 4574.  Is that correct?  It's also not in the references section.
    
    Thanks .. that definitely does not belong there.
    
    >
    > 2) RFC 5497 is not definitive in the representation of 1 or 2 byte floats, as C must be specified.  In your draft, it would be good to have a section that completely spells out how to go from a timestamp to/from mini/half floats.
    >
    > 3) I agree that playing with the signature time might have unintended security consequences.  The signature time might also be unrelated to other time fields in the packet as it might be generated independently of the content itself, so using it as a time base is not a good idea either.
    
    hm, both, the expiry and signature times in Content Objects are part of
    the security envelope. There is a strong relation between the expiry and
    signature times once a signature is generated. I assume that expiry time
    is also always > signature time, because of the following quote from
    [1]:
    
     The ExpiryTime is a field that exists within the signature envelope
     of a Validation Algorithm.  It is the UTC time in milliseconds after
     which the Content Object is considered expired and MUST no longer be
     used to respond to an Interest from a cache.  Stale content MAY be
     flushed from the cache.
    
    If I am not mistaken, then there should never be expired Content Objects
    in the network. Expiry time can therefore be expressed as a (positive
    only) time delta to the signature time .. or is there any valid use case
    where expired Content Objects get a new signature (and therefore have an
    expiry time < signature time)?
    
    [1] https://tools.ietf.org/html/rfc8569#section-4
    
There may be expired content objects in two conditions.  One is in-flight content objects that expire before reaching a consumer.  That's a corner case.  The publisher or cache initiating the transmission thought it was not expired and it expired during transit.  Two is locally stored content object.  They can expire, and there is no mandate to purge them; it is only a mandate to not transmit them on the network.  A consumer could keep them around for as long as it wants.

The issue with using the expiry time as a delta from the signature is that someone could strip the signature off a content object and re-sign it.  This would attach a new signature time.  If one knew that a certain field was a delta from the signature time, it might be possible to re-calculate it.  This could be a single publisher updating the signature on a content object or manifest to extend it or a 3rd party re-publishing a content object.

Another potential issue is that a content object might have co-signatures, or multiple signature blocks.  This is not in the draft, but it is a technique used in SDSI for cascading signatures and parallel signatures.  If such a feature were introduced in CCNx, one would need a way to express which signature is the time base.  This is not an issue as-is, just something to consider for the future.

Not all ValidationInfos have a signature time.  Some, like a CRC or SHA256 or HMAC, do not have the field.  Some content object, such as those referenced by hash in a manifest that use the root manifest's signature as the trust root, do not have a validation section at all.  So if those want to use an Expiry time, for example, they need to use an absolute time.  So, would it be possible to have a 1 or 2 byte float and be able to tell if it was relative or absolute?  Maybe the 2-byte could have a bit for that.

    >
    > 4) If the RCT becomes relative, then a cache should decrement it.  I'm not a big fan for using relative times here, but it could be done.  I had written up an idea on allowing relative times as an alternative to absolute times in https://tools.ietf.org/html/draft-mosko-icnrg-cachecontrol-00.
    >
    > 5) I think fractions of a second are not important for fields like interest lifetime or RCT, so the exponent does not need to support negatives.  Removing a sign bit and keeping the exponent positive with a normalized form mantissa would have a fairly large range, at least for the 8-bit (a 0.4.4.-0 minifloat).  The 16-bit should keep all the bells and whistles as it has space, and you'd likely use IEEE half precision floats anyway?
    >
    
    I put together this little visualization [2] to show the ranges of
    different time encodings. I assume an 8-bit float without sign bit and
    exponent bias. The legend shows configurations in the typical form:
    (sign bits, exponent bits, mantissa bits, bias).

Great!  I was thinking of doing that myself.  Are you still assuming that 0x00 is defined as 0 (instead of 1)?  I guess I'm asking would one use denormalized numbers with a 0 exponent?
    
    Let's assume that a time value represents seconds. Then we are obviously
    not able to represent sub-second floats. Though, milliseconds might be
    interesting for some use cases (e.g., to quickly delete a PIT trail for
    unsatisfied, but time-sensitive data).
    
    The configurations (0,3,5,0) and (0,6,2,0) have IMO either a very low
    range, or a rather unnecessarily huge range.
    
    (0,4,4,0) can at max represent ~17 hours (63488 seconds).
    (0,5,3,0) has a max time value of ~127 years (4026532000 seconds).
    
    If we assume milliseconds as base unit, then above values change to:
    
    (0,4,4,0): max ~1 minute
    (0,5,3,0): max ~46 days
    
    ~46 days as a max value for lingering PITs are IMO reasonable .. and we
    gain 80 sub-second values (out of 255 possible time codes).

    In previous slides there was also the constant C set to (1/1024). The
    beauty of having (1/1024) instaed of (1/1000, milliseconds) as base is
    that it yields integer values in the seconds range for power-of-2 values
    (1s,2s,4s,...). An application would more likely want to encode "4s",
    instead of "4.096s".

Yes, the ~46 day range /1000 or /1024 sounds like a good option for things like expiry time or cache time, especially for the IoT environment.

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 like the idea of using an IEEE half precision float for the 16-bit
    variant.
    
    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?
    
    Cheers,
    Cenk
    
    [2] https://cgundogan.github.io/minifloat/
    [3] https://github.com/icnrg/draft-gundogan-icnrg-ccnx-timetlv/issues/3
    
    > Marc
    >
    >
    > On 11/19/19, 8:12 PM, "icnrg on behalf of Thomas C. Schmidt" <[e-mail] on behalf of [e-mail]> wrote:
    >
    >     Folks,
    >
    >     following up on our presentation of draft-gundogan-icnrg-ccnx-timetlv:
    >
    >     This proposes to replace time deltas in CCNx by logarithmic encodings
    >     and (maybe) some absolute timer values by deltas w.r.t. the signature time.
    >
    >     We solicit feedback: Do you agree on going this way, or do you suspect
    >     this to be harmful?
    >
    >     Best,
    >       Thomas
    >     --
    >
    >     Prof. Dr. Thomas C. Schmidt
    >     ° Hamburg University of Applied Sciences                  Berliner Tor 7 °
    >     ° Dept. Informatik, Internet Technologies Group   20099 Hamburg, Germany °
    >     ° http://inet.haw-hamburg.de/members/schmidt      Fon: [phone] °
    >
    >     _______________________________________________
    >     icnrg mailing list
    >     [e-mail]
    >     https://www.irtf.org/mailman/listinfo/icnrg
    >
    >
    > _______________________________________________
    > icnrg mailing list
    > [e-mail]
    > https://www.irtf.org/mailman/listinfo/icnrg