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

["Milheiro Mendes, Paulo Jorge" <[e-mail]>]

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.