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

From: "Dirk Kutscher" <[email-masked]>
Date: Wed, 29 Jul 2020 14:39:21 +0200

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

---

From: Hitoshi Asaeda <[email-masked]>
Date: Fri, 31 Jul 2020 18:51:00 +0900

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?

My comment is that it is better to discuss this document without an intention of updating RFC8609.

Regards,

Hitoshi

> On Jul 29, 2020, at 21:39, Dirk Kutscher <[email-masked]> 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
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg

---

From: Cenk Gündoğan <[email-masked]>
Date: Fri, 31 Jul 2020 14:06:13 +0200

Hello Hitoshi,

thank you for your feedback, my comments follow further down inline.

> 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…

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

--
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: "Dirk Kutscher" <[email-masked]>
Date: Fri, 31 Jul 2020 15:46:23 +0200

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:

>> 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?
>
>>> (https://datatracker.ietf.org/doc/draft-gundogan-icnrg-ccnx-timetlv/) 
>>> is intended as an update to RFC 8609 (CCNx Messages in TLV Format).
>>>
>>> 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.
>>>

---

From: Marc Mosko <[email-masked]>
Date: Fri, 31 Jul 2020 17:44:30 +0000

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" <[email-masked] on behalf of [email-masked]> wrote:

    Hi everyone,

    Best regards,
    Dirk