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

"Milheiro Mendes, Paulo Jorge" <paulo.mendes@airbus.com> Mon, 11 May 2020 15:21 UTC

Return-Path: <paulo.mendes@airbus.com>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 4E8883A0659 for <icnrg@ietfa.amsl.com>; Mon, 11 May 2020 08:21:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=airbus.com header.b=YBlQ5CTx; dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=airbus.com header.b=HdHNGYok
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id VyjaOKt4z51V for <icnrg@ietfa.amsl.com>; Mon, 11 May 2020 08:21:15 -0700 (PDT)
Received: from mx1.myeers.net (mx1.myeers.net []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A4DA3A077A for <icnrg@irtf.org>; Mon, 11 May 2020 08:21:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=airbus.com; i=@airbus.com; l=19911; q=dns/txt; s=eers-ng2048; t=1589210465; x=1620746465; h=mime-version:from:date:message-id:subject:to; z=MIME-Version:=201.0|From:=20"Milheiro=20Mendes,=20Paulo =20Jorge"=20<paulo.mendes@airbus.com>|Date:=20Mon,=2011 =20May=202020=2017:20:24=20+0200|Message-ID:=20<CAD6RcJYA F4VLzVQH1sW1QvhLJ3EXsx2tyieTqjmyb+z6HHF65g@mail.gmail.com >|Subject:=20Review=20of=20draft-gundogan-icnrg-ccnx-time tlv-01|To:=20ICNRG=20<icnrg@irtf.org>; bh=gRRA8JRnV44dU6URZxgUiBuDu+l2LeAG196dkXmT4XE=; b=YBlQ5CTxFzuEr04mxqKjbDRC2oDVeobK+c6oURQWT3++h3rmIJoRruQn e7+oTNRYuT6gjswXjyZrvre029NS1pey23Ll246JK8FrAc0W+sS+GaGrV crsyZWsqCZbrJsbRfJ3ToxXDlsl+DajimewBCL/c5YWveFkmtk+F7Hj1K T9AViCw548ZxRXehjcfJFE/ON6NqXNA4Lv0tsAQ8aAk25Q1jKoBAoNYHY DvHXQI5xJjin3QKwd3RzXR5N2bjAgJydBfex3n/fXonP1KRfWvKLpuMF/ BUiSo9LnETlZ1YHw5SVwWHw/ZM3EduIE1FoBMY7aAs2FqgfES44lpS7dN A==;
Received-SPF: Pass (MX: domain of paulo.mendes@airbus.com designates as permitted sender) identity=mailfrom; client-ip=; receiver=MX; envelope-from="paulo.mendes@airbus.com"; x-sender="paulo.mendes@airbus.com"; x-conformance=spf_only; x-record-type="v=spf1"; x-record-text="v=spf1 ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ~all"
Received-SPF: None (MX: no sender authenticity information available from domain of postmaster@mail-lf1-f72.google.com) identity=helo; client-ip=; receiver=MX; envelope-from="paulo.mendes@airbus.com"; x-sender="postmaster@mail-lf1-f72.google.com"; x-conformance=spf_only
Authentication-Results: MX; spf=Pass smtp.mailfrom=paulo.mendes@airbus.com; spf=None smtp.helo=postmaster@mail-lf1-f72.google.com; dkim=pass (signature verified) header.i=@airbus.com; dmarc=pass (p=none dis=none) d=airbus.com
X-IronPort-AV: E=Sophos;i="5.73,380,1583190000"; d="scan'208,217";a="149741006"
Received: from mail-lf1-f72.google.com ([]) by mx1.myeers.net with ESMTP/TLS/AES128-GCM-SHA256; 11 May 2020 17:21:01 +0200
Received: by mail-lf1-f72.google.com with SMTP id t11so3667505lfc.17 for <icnrg@irtf.org>; Mon, 11 May 2020 08:21:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=airbus.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=xZ38vvuOC1ucfGrH1Ovwih3Q0gS+65gDXUD2F2uuf6I=; b=HdHNGYok9PEutJMgwA+yz3vi7dGlSEz3FFBhJUkBim3qUyIquXh6pbGxJpKbfyt7WW MY2R2T6yOpyqjm5WSxtftRmEOxjdptp3IOTXUkLvXJShXfb9SwULl9s58lpz/wPLQNNY AqlHP4Bweuzop2wzlrc3fC4F/DMZ0entojwy3fId7BHpSRm5Nq6zQHeCxNvBUr6CF+kE AiK6Ya8o5sN/4v5xn1wjz4LuBLQWgez1JpYP779t6jQS4WKmdNpg6gi9gkVJ7BQkp24T m8kw60ag+erC4VxoE1VZuof80y1iGcyubdZKXern+Gz4Wo9SJJhOoDhf3ZD/U0xaeLlP hJhg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=xZ38vvuOC1ucfGrH1Ovwih3Q0gS+65gDXUD2F2uuf6I=; b=f1t/BQ5NE5xvlTzhHbeqGO9hEjelzgPvPO2LJjTG2g9M07+vdZTUhz9WaZeHLBCTEu XqKJoy1rgAN9r67f31scpOBytPHIKWUEL05aJ1HHztnlD5Qg6Pr+ao8na2pYaJRsIA30 UjyAh0uPN5JtMy2dbJ7T3k+4aSaIl/cGSbyxWo5MvkYo9rpZ12bxeq+p8SMOeadhDHib x0bCO0oetuuyn//QC8cNDhTJ6++NTl0m7LTlc6YWHuLeFGoi5joeJMlyeRnA5720rNHN J9FyoGMC75BbPCw10jArF2XzMwho03+NLR/1vRzS/3momLvYOnHzavHk04MBkILP+3Ez LHSw==
X-Gm-Message-State: AOAM531Qh0U2u/zkjyWAtXTdJsYjBHKbUx+bP8WfKMZ76GXSZ2HtHYVq Rb0NpD+GtJ8ZTKiUq13wl2aXURjk4g7nvGBb2XJourB15hkZL2HQJfWf2vTpgCNxTBgfDdGoj7H +NMgYTSJw1LtHbSL9LCuaHA==
X-Received: by 2002:a19:c6c5:: with SMTP id w188mr11259053lff.65.1589210460866; Mon, 11 May 2020 08:21:00 -0700 (PDT)
X-Google-Smtp-Source: ABdhPJxSIwq2WtdpAMiAcgCME7CFCRFtgdlF+jht/JOziU6guTH8eMtBtY3HnwkqzSD/j3v0ag4HA6cW2dSrdhSjMrE=
X-Received: by 2002:a19:c6c5:: with SMTP id w188mr11259028lff.65.1589210460126; Mon, 11 May 2020 08:21:00 -0700 (PDT)
MIME-Version: 1.0
From: "Milheiro Mendes, Paulo Jorge" <paulo.mendes@airbus.com>
Date: Mon, 11 May 2020 17:20:24 +0200
Message-ID: <CAD6RcJYAF4VLzVQH1sW1QvhLJ3EXsx2tyieTqjmyb+z6HHF65g@mail.gmail.com>
To: ICNRG <icnrg@irtf.org>
Content-Type: multipart/alternative; boundary="000000000000f31aed05a560e4b1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/t0g8oMuBWLKj-qbExoKOXHHie8I>
Subject: [icnrg] Review of draft-gundogan-icnrg-ccnx-timetlv-01
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 May 2020 15:21:17 -0000

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

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

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

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?


*Paulo Mendes, Ph.D*

Senior Scientist

Central Research and Technology, XRC

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.