Re: [icnrg] Adoption of 'Alternative Delta Time Encoding for CCNx Using Compact Floating-Point Arithmetic' (draft-gundogan-icnrg-ccnx-timetlv)

[Marc Mosko <[e-mail]>]

Here are my thouhts on paths to encode the compressed time.  I think there are a few ways to go forward.  I'll discuss a few pros/cons after enumerating them.

1) Add a new RFC that specifies the compressed time and have it grab its own TLV from IANA.  No modification of RFC8609 needed.   The new RFC should maintain the behavior that L=0 implies no response is expected (i.e. a purely push notification via Interest) -- or specify some other mechanism to indicate that condition if this new TLV is present.

2) Modify 8609 so InterestLifetime understands that L=1 implies compressed form and L > 1 implies normal (milliseconds).  This would update Sec 3.4.1.  I do not think 8569 needs modification.  

3) Modify 8609 so InterestLifetime uses some method to encode its encoding, e.g. 1 byte for a mechanism and 1+ bytes for value.  It defeats having a super-tiny encoding, but it's better than wrapping a TLV in a TLV.  Or you could do something more bit-oriented if you wanted to really compress it out, but I suspect that for anything practical it would spill over to 2 bytes anyway.

Regardless of option #1 or #2 or #3, forwarders need to be modified to understand the compressed time.  A possible PRO of #1 is that if an implementation does not understand it, it will assume some default InterestLifetime.   A possible CON of #2 is that if a router does not know of the update, it would assume the lifetime is some 1 - 255 msec value.

#3 has the same downsides as #2 -- a non-conforming router would think the value was those 2 bytes.   I'm not sure it has any advantages over #1.  At the moment, I think #1 is better than #3.

I do not think that 8569 needs modification to accommodate #1.  The specs already say how to add a new Hop-By-Hop header (https://tools.ietf.org/html/rfc8609#section-4.3).

I look forward to our interim meeting,
Marc

On 7/31/20, 6:46 AM, "icnrg on behalf of Dirk Kutscher" <[e-mail] on behalf of [e-mail]> wrote:

    Hi everyone,

    Hitoshi-san, let me ask you this way: what problems do you see with 
    updating RFC8609?

    Best regards,
    Dirk


    On 31 Jul 2020, at 14:06, Cenk Gündoğan wrote:

    > Hello Hitoshi,
    >
    > thank you for your feedback, my comments follow further down inline.
    >
    > On Fri, Jul 31 2020 at 11:51 +0200, Hitoshi Asaeda wrote:
    >
    >> Hi,
    >>
    >> I don't deny the proposal itself but have a concern about the 
    >> intention; "update" RFC8609.
    >>
    >> Why does this draft update RFC8609? Why can't we keep RFC8609 as is 
    >> and propose the new type values for this proposal as the addition?
    >> The time TLV proposed in this document can coexist with RFC8609 if 
    >> you use the new type values. Why does this need to replace the time 
    >> TLV defined in 8609? Is there any errata reported for the time TLV 
    >> defined in 8609?
    >
    > the current version of this document describes a few alternatives on 
    > how
    > to integrate the compressed time TLV into CCNx. One alternative 
    > proposes
    > to use the Length (L) field of the InterestLifetime TLV to identify 
    > the
    > included encoding (normal time (L>1) vs. compressed time (L==1)
    > representation). This would require a change in RFC8609 (Section 3.4.1
    > [1]).
    >
    > Another alternative might update the message ABNF in Section 2.1 [2] 
    > of
    > RFC8569 to add a new top-level TLV for the compressed 
    > InterestLifeTime.
    >
    > [1] https://tools.ietf.org/html/rfc8609#section-3.4.1
    > [2] https://tools.ietf.org/html/rfc8569#section-2.1
    >
    >>
    >> My comment is that it is better to discuss this document without an 
    >> intention of updating RFC8609.
    >
    > All proposed integration alternatives display advantages and
    > disadvantages. Getting group feedback on this particular topic is 
    > quite
    > valuable for the progression of this work. Thanks! We could also
    > reiterate over the existing integration ideas again (on the list?) in
    > order to stimulate new ideas and solutions (comparable to a draft
    > presentation?).
    >
    > Best,
    > Cenk
    >
    >>
    >> Regards,
    >>
    >> Hitoshi
    >>
    >>
    >>> On Jul 29, 2020, at 21:39, Dirk Kutscher <[e-mail]> wrote:
    >>>
    >>> Hi ICNRG,
    >>>
    >>> This draft 
    >>> (https://datatracker.ietf.org/doc/draft-gundogan-icnrg-ccnx-timetlv/) 
    >>> is intended as an update to RFC 8609 (CCNx Messages in TLV Format).
    >>>
    >>> The authors have just submitted an update that addresses previously 
    >>> made technical comments.
    >>>
    >>> We believe that it would be appropriate to give change control to 
    >>> the Research Group, so the chairs would like to solicit statements 
    >>> indicating support for adoption or concerns against it from people 
    >>> who are 1) not co-authors and 2) have read the latest version.
    >>>
    >>> In case there are questions that you would like to discuss 
    >>> interactively, we should be able to make some time for that on the 
    >>> Monday Interim meeting -- let us know.
    >>>
    >>> Thanks and best regards,
    >>>
    >>> Chairs
    >>>
    >>> _______________________________________________
    >>> icnrg mailing list
    >>> [e-mail]
    >>> https://www.irtf.org/mailman/listinfo/icnrg
    >>
    >> _______________________________________________
    >> icnrg mailing list
    >> [e-mail]
    >> https://www.irtf.org/mailman/listinfo/icnrg
    >
    > --
    > 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

    _______________________________________________
    icnrg mailing list
    [e-mail]
    https://www.irtf.org/mailman/listinfo/icnrg