[icnrg] Review of draft-gundogan-icnrg-ccnx-timetlv-01
"Milheiro Mendes, Paulo Jorge" <email@example.com> Mon, 11 May 2020 15:21 UTC
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8883A0659 for <firstname.lastname@example.org>; Mon, 11 May 2020 08:21:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 ([220.127.116.11]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VyjaOKt4z51V for <email@example.com>; Mon, 11 May 2020 08:21:15 -0700 (PDT)
Received: from mx1.myeers.net (mx1.myeers.net [18.104.22.168]) (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 <firstname.lastname@example.org>; Mon, 11 May 2020 08:21:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=airbus.com; email@example.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<firstname.lastname@example.org>|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<email@example.com>; 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 firstname.lastname@example.org designates 22.214.171.124 as permitted sender) identity=mailfrom; client-ip=126.96.36.199; receiver=MX; envelope-from="email@example.com"; x-sender="firstname.lastname@example.org"; x-conformance=spf_only; x-record-type="v=spf1"; x-record-text="v=spf1 ip4:188.8.131.52/24 ip4:184.108.40.206/19 ip4:220.127.116.11/20 ip4:18.104.22.168/20 ip4:22.214.171.124/18 ip4:126.96.36.199/16 ip4:188.8.131.52/21 ip4:184.108.40.206/16 ip4:220.127.116.11/17 ip4:18.104.22.168/19 ip4:22.214.171.124/19 ~all"
Received-SPF: None (MX: no sender authenticity information available from domain of email@example.com) identity=helo; client-ip=126.96.36.199; receiver=MX; envelope-from="firstname.lastname@example.org"; x-sender="email@example.com"; x-conformance=spf_only
Authentication-Results: MX; spf=Pass firstname.lastname@example.org; spf=None email@example.com; dkim=pass (signature verified) firstname.lastname@example.org; 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 ([188.8.131.52]) 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 <email@example.com>; 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-Received: by 2002:a19:c6c5:: with SMTP id w188mr11259028lff.65.1589210460126; Mon, 11 May 2020 08:21:00 -0700 (PDT)
From: "Milheiro Mendes, Paulo Jorge" <firstname.lastname@example.org>
Date: Mon, 11 May 2020 17:20:24 +0200
To: ICNRG <email@example.com>
Content-Type: multipart/alternative; boundary="000000000000f31aed05a560e4b1"
Subject: [icnrg] Review of draft-gundogan-icnrg-ccnx-timetlv-01
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:email@example.com?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 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.
- [icnrg] Review of draft-gundogan-icnrg-ccnx-timet… Milheiro Mendes, Paulo Jorge
- Re: [icnrg] Review of draft-gundogan-icnrg-ccnx-t… Thomas C. Schmidt