Re: [icnrg] Review of draft-gundogan-icnrg-ccnx-timetlv-01

["Thomas C. Schmidt" <[e-mail]>]

Dear Paulo,

many thanks for the review. We will carefully go through your feedback 
and will be back then.

Best,
  Thomas

On 11/05/2020 17:20, Milheiro Mendes, Paulo Jorge wrote:
> Dear All,
> 
> In this email I provide my revision of the draft  "An Alternative Delta 
> Time encoding for CCNx using Interval Time from RFC5497" - 
> draft-gundogan-icnrg-ccnx-timetlv-01 ( 
> https://tools.ietf.org/pdf/draft-gundogan-icnrg-ccnx-timetlv-01.pdf ).
> 
> A) Overall comments
> 
> The motivation (abstract and intro) needs to be revised, it is not clear 
> in which scenarios CCNx would benefit from the extra complexity and 
> reduced time accuracy. I come to this issue in the detailed comments 
> provided below.
> 
> Moreover, it is worthy to clarify that this draft aims to improve the 
> efficiency of CCNx operation in a specific set of networks (bandwidth 
> constrained networks or constrained  nodes). Deployment/applicability 
> scenarios should be described in order to justify the impact that this 
> draft may have. For instance, when deploying an CCNx based IoT network, 
> sensors and actuators may have a CCNx implementation based on this 
> draft, but IoT aggregators and the remaining network may not need it. 
> How will this work? How will the CCNx functions that make use of delta 
> times operate in an end-to-end fashion? For instance when will Interest 
> messages be made short in an end-to-end scenario that included 
> constrained networks (e.g. sensors) and not constrained ones (e.g. 
> access to cloud).
> 
> The draft does not consider some of the time representations on CCNx 
> (such as signature and expiry time). At the end, the draft proposes a 
> compression of one delta time (Interest Lifetime) and of one absolute 
> time (Recommended Cache Time). Again the question is, what is really the 
> impact that the described method has on the efficiency of CCNX, since 
> not all time definitions are compressed? Do we gain anything in adding 
> the extra complexity, and less time accuracy, to compress just a subset 
> of time definitions?
> 
> 
> B) Comments per section
> 
> Section 1:
> 
> It would be good to clarify the relationship of the proposed logarithmic 
> encoding schemes with the stateless and stateful compression schemes 
> defined in draft-irtf-icnrg-icnlowpan-06 to improve efficiency of CCNx 
> and NDN over IEEE 802.15.4 networks. By what is written in the 
> introduction it seems that the compression schemes described in 
> draft-irtf-icnrg-icnlowpan-06 are not efficient since they sacrifice 
> either accuracy or dynamic range or both. But then on section 3.1, this 
> draft mentions that the current usage of delta time does not require 
> both accuracy and dynamic range simultaneously.
> 
> 
> Section 3.1:
> 
> The reference to sections 2.1, 2.2, 2.4.2, 10.3 is misleading. They seem 
> to refer to RFC 8569, but this is not clear in the way the text is written.
> 
> Some concepts, such as a time described as a "hop-by-hop header value", 
> are not explained. Since this is mentioned in RFC5487, a reference 
> should be added.
> 
> By what is written it seems that the major contribution of this draft is 
> the definition of a logarithmic encoding for the compression of delta 
> times, as that specified in [RFC5497]. What is the difference between 
> the logarithmic encoding described in this draft and the one described 
> in [RFC5497]?
> 
> Or the major contribution of this draft is not so much the logarithmic 
> encoding but a method to update CCNx messages in TLV Format to support 
> this alternative encoding. But in this case, what is the difference to 
> [RFC8609]?
> 
> Before following sections 4 and 6, section 3.1 could provide a better 
> statement of the contribution related to RFC 5497 and RFC8609.
> 
> Section 3.2:
> 
> This draft is presented as being dedicated to study how to improve the 
> operation of CCNx while utilizing Delta Times for a number of functions. 
> But in this section a lot of attention is dedicated to Absolute Time 
> usage in CCNx, just to mention that the current draft does not consider 
> most of them, with the exception of the Recommended Cache Time. This 
> section should be shortened, aiming to focus the draft.
> 
> Section 4:
> 
> As mentioned before, this document should clarify what brings new in 
> relation to RFC5497. In relation to IEEE.754.2019, the difference is 
> that the proposed approach only encodes positive numbers. Which is fine 
> when the goal is only to encode Interest lifetime and Recommended Cache 
> Time. But the question is: why can´t the IEEE.754.2019 encoding be used? 
> If the time values to be encoded are always positive the IEEE.754.2019 
> method should not result in a positive compressed number?
> 
> In which part of the network will the compression algorithm be 
> implemented? In a consumer, before generating an Interest packet? I see 
> the need to do this in a consumer, if it is constrained or if it is 
> placed in a constrained network. But what happens if the consumer is not 
> in a constrained network, but the producer is?
> 
> Section 5:
> 
> The problem of using the proposed approach in an heterogeneous scenario 
> (with constrained segments and non-constrained segments) is clear in 
> this section where it is proposed to simply allow a 1-byte length as an 
> alternative to the 8-byte length. This would mean that in heterogeneous 
> end-to-end cases, the compressed (less accurate) times will be used in 
> the non-constrained network segment that may correspond to the largest 
> part of the network. Considering the example provided in section 5 
> (IoT), it may be considered that the only constrained part of the 
> end-to-end part from a sensor to a cloud is the first hop from the 
> sensor to an IoT aggregator. Is it worth introducing more complexity in 
> such a case?
> 
> This approach seems to bring benefits in scenarios in which all CCNx 
> nodes (consumers, producers, relays/routers) are in a constrained 
> scenario. What scenario would this be? Manets? Vanets?
> 
> 
> Cheers
> 
> 
> *Paulo Mendes, Ph.D*
> 
> Senior Scientist
> 
> Central Research and Technology, XRC
> 
> *Airbus*
> 
> The information in this e-mail is confidential. The contents may not be 
> disclosed or used by anyone other than the addressee. Access to this 
> e-mail by anyone else is unauthorised.
> If you are not the intended recipient, please notify Airbus immediately 
> and delete this e-mail.
> Airbus cannot accept any responsibility for the accuracy or completeness 
> of this e-mail as it has been sent over public networks. If you have any 
> concerns over the content of this message or its Accuracy or Integrity, 
> please contact Airbus immediately.
> All outgoing e-mails from Airbus are checked using regularly updated 
> virus scanning software but you should take whatever measures you deem 
> to be appropriate to ensure that this message and any attachments are 
> virus free.

-- 

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] °