Re: [icnrg] [EXT] I-D Action: draft-irtf-icnrg-icnping-03.txt

Junxiao Shi <shijunxiao@email.arizona.edu> Mon, 11 April 2022 16:37 UTC

Return-Path: <shijunxiao@email.arizona.edu>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97DA83A1207 for <icnrg@ietfa.amsl.com>; Mon, 11 Apr 2022 09:37:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=email-arizona-edu.20210112.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSchu-4_dCEE for <icnrg@ietfa.amsl.com>; Mon, 11 Apr 2022 09:37:14 -0700 (PDT)
Received: from mail-oa1-x2b.google.com (mail-oa1-x2b.google.com [IPv6:2001:4860:4864:20::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07B243A120E for <icnrg@irtf.org>; Mon, 11 Apr 2022 09:37:13 -0700 (PDT)
Received: by mail-oa1-x2b.google.com with SMTP id 586e51a60fabf-dacc470e03so17828894fac.5 for <icnrg@irtf.org>; Mon, 11 Apr 2022 09:37:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=email-arizona-edu.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5FFgjlHlFk3uZe8IHNl4b18GYStvAGOWZ8GXnVhafLw=; b=3c9qPJWhDBCbF9GfkLiiYq7KXrX0b1DEyn94QnnvOlBtiWN+0xXNvIM8KXkb7NEmJI oz2gfb9F1G6n47ujsKgJ39F8OJLdZJEA9wx7cuDf/l0qYtgCek3CI57e77xt1ueaN0j9 xoyfJzs4cxCFPWBcBvrXQJToCn9eXrIdhzwkbld3DRaBhUZaZ1fKVkB1DFW1GbNMcM8W OoUzqG5vii5Z6uzD1Eht3Eu7D/gqUq/Oc/5T8UGCzGY44md1SUYsPNGWLL9EXCw0xkjb yeU0QibjjqnC0/5l6eahPosbg76+/N7prASRiERLT2rZdh32m0bcxzOiBXSjJlmg/cFA 6IvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5FFgjlHlFk3uZe8IHNl4b18GYStvAGOWZ8GXnVhafLw=; b=MQe4K3eNpJ8cJtg58IR3DGqsQHHZBz8KYRndTNKuLYywBKC/LhbZWC1mUAuLcUdNxb K2NAN0fOnexLNKjjrMvdSCh5AXt7DYSwE1+iHm8SxMYC4Z5Begn17iURCaIRm+DAPnzq 8w9fyvH8s59GkLLABIUa4XH51lbKyNhYPXEtYnivMAtQhlOAGUKWap0iX1ZeZMpcKk7d 0Q8qOci3yRbJcgZy8w4DJtXe9OgTKnWKtjd4ULayYdHpiJdFcGFKcGpZD6rudI7FtUoZ T+qQYkFuqDZwLICP6JmJPfj/5v9TPR0heVJKIDritNOVWX/XXKh5mjqu4YHSzE97/AS7 InuQ==
X-Gm-Message-State: AOAM531guearhNtkkY95yKYl/CYMpwCvewoD9u6Z6MADhzkrYU1Z0uKl 5q6dudvKJN6eifor/hcNi6ClPdWSpOeNRMz0FQxeMPBb2Mzp42yIpsm71jSim+rzkiNGHFD8KR6 FwhlcuKkPCec=
X-Google-Smtp-Source: ABdhPJz8/Bp0Ul2wiRAPGAGhVy9mtsvjS1c6st4rB0sIQ3fKgVReFCOSvcGn4nY/KWH20I4qw8DKXuC22ZM9NvUh4yo=
X-Received: by 2002:a05:6870:41c6:b0:da:b3f:3260 with SMTP id z6-20020a05687041c600b000da0b3f3260mr6284oac.272.1649695032066; Mon, 11 Apr 2022 09:37:12 -0700 (PDT)
MIME-Version: 1.0
References: <163519291458.16034.1879568644895811832@ietfa.amsl.com> <CAOFH+Oaq-it9CV3T82Vm9uHVWGyc4yzu8_qTMwR3WzVtdE13FQ@mail.gmail.com> <2D588ADD-F5F2-47F5-9C7C-A15113395CF9@unomaha.edu> <CAOFH+OZOrno0EWkSPJUD17tYusowDmcw2Z5BgobV6o6av6U08A@mail.gmail.com> <FED6100B-FF22-4231-87AE-68D452EDD268@orandom.net> <23D030F8-DDFD-437A-A289-3F23960021E0@unomaha.edu> <683DC592-2C9C-401B-91A7-46867EBFD773@dkutscher.net>
In-Reply-To: <683DC592-2C9C-401B-91A7-46867EBFD773@dkutscher.net>
From: Junxiao Shi <shijunxiao@email.arizona.edu>
Date: Mon, 11 Apr 2022 12:36:35 -0400
Message-ID: <CAOFH+OYhWBCDgeYwpQpKx01d_kzJga+qZPjP5YHMgxTPkm82kg@mail.gmail.com>
To: Dirk Kutscher <ietf@dkutscher.net>
Cc: Spyridon Mastorakis <smastorakis=40unomaha.edu@dmarc.ietf.org>, icnrg@irtf.org, "David R. Oran" <daveoran@orandom.net>
Content-Type: multipart/alternative; boundary="0000000000005fd6a005dc638ea2"
X-ua-ms: gsuite
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/5l021QWhn7Vl3yc9GEkffZAXtZU>
Subject: Re: [icnrg] [EXT] I-D Action: draft-irtf-icnrg-icnping-03.txt
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 Apr 2022 16:37:20 -0000

Hi Dirk

Yes, I looked at the diff from -05 revision and I believe the errors have
been corrected.

Yours, Junxiao

On Mon, Apr 11, 2022 at 6:23 AM Dirk Kutscher <ietf@dkutscher.net> wrote:

> Hi Junxiao,
>
> Thanks for paying attention and for the additional comments.
>
> Can you check whether your issues have been addressed?
>
> Thanks,
> Dirk
>
>
> On 8 Apr 2022, at 21:15, Spyridon Mastorakis wrote:
>
> Thanks for the comments, Junxiao. The drafts have been updated and your
> comments have been addressed.
>
> Spyros
>
> —
>
> Spyridon (Spyros) Mastorakis, Ph.D.
> Assistant Professor
> Computer Science Department
> University of Nebraska at Omaha
> Peter Kiewit Institute Room 174E
> Associate Editor, IEEE Internet of Things Journal
> Director, Ph.D. Program in Information Technology
> Website: https://sites.google.com/site/spyridonmastorakis
>
> On Apr 5, 2022, at 6:39 AM, David R. Oran <daveoran@orandom.net> wrote:
>
> Non-NU Email
>
> Thanks!
> We’ll get these fixed quickly.
>
> On 4 Apr 2022, at 11:57, Junxiao Shi wrote:
>
> Hi Spyros
>
> I have inspected the diff between -03 and -4. Certain errors are not fully
> fixed. See comments inline.
>
> New problem: in references
>
> [NDNTLV]   "NDN Packet Format Specification.", 2016,
> <
> https://urldefense.com/v3/__http://named-data.net/doc/ndn-tlv/__;!!PvXuogZ4sRB2p-tU!Xz_WVwqvAcMkJkLusl_deBsZ2d92QSiVeCmfC6bOzFHRjdZdhj71JsWc0R-MLFGprkAL$
> > .
>
> The current spec link is:
>
> https://urldefense.com/v3/__https://named-data.net/doc/NDN-packet-spec/current/__;!!PvXuogZ4sRB2p-tU!Xz_WVwqvAcMkJkLusl_deBsZ2d92QSiVeCmfC6bOzFHRjdZdhj71JsWc0R-MLKV7kvFM$
>  . It was last updated
> in 2022.
> You can also cite a specific version on
>
> https://urldefense.com/v3/__https://github.com/named-data/NDN-packet-spec__;!!PvXuogZ4sRB2p-tU!Xz_WVwqvAcMkJkLusl_deBsZ2d92QSiVeCmfC6bOzFHRjdZdhj71JsWc0R-MLMaxcvab$
>  using a commit hash.
>
> On Sun, Mar 6, 2022 at 6:52 PM Spyridon Mastorakis <
> smastorakis@unomaha.edu>
> wrote:
>
> *External Email*
> Dear Junxiao,
>
> Thank you for your comments. We have addressed them in the updated
> versions of our drafts that we just uploaded. Please see below for more
> details:
>
> On Dec 13, 2021, at 9:00 AM, Junxiao Shi <shijunxiao@email.arizona.edu>
> wrote:
>
> Non-NU Email
> ------------------------------
> Dear folks
>
> I had a look at the NDN encoding for ICN Ping Protocol rev03.
> It seems that the protocol partially assumes NDN packet format v0.2, and
> is incompatible with the current NDN packet format.
>
> As of 2019-May
> <
> https://urldefense.com/v3/__https://redmine.named-data.net/issues/4853__;!!PvXuogZ4sRB2p-tU!R1XTGYwBlOXYUAzHhlV6sAyjq-Qz47wI4GLKSybSpxaQ2vKKrLONq9piKdxFWKR6IgjQ$>
> ,
> the NDN packet encoding is written with IETF ABNF syntax.
> However, ICN Ping still specifies its encoding with W3C EBNF syntax, which
> could lead to confusion.
>
>
> Fixed. We converted the packet encoding to the ETF ABNF syntax.
>
>
> RFC5234 <
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc5234__;!!PvXuogZ4sRB2p-tU!Xz_WVwqvAcMkJkLusl_deBsZ2d92QSiVeCmfC6bOzFHRjdZdhj71JsWc0R-MLHhiZDl2$
> > defines the IETF
> ABNF syntax. NDN packet encoding follows this specification.
> In this syntax, a rule is defined by the following sequence:
>
> name =  elements crlf
>
> However, draft-irtf-icnrg-icnping-04 Section 5.2 is still defining a rule
> with ::= operator.
>
> The Parameters element is meant to contain PathSteering TLV.
>
> As suggested below, it may make sense to move it to the NDNLPv2 header.
>
> Section 5.2 defines Ping Echo Reply to be a Data packet with ContentType=0
> and FreshnessPeriod=0.
> Since ContentType defaults to 0 and FreshnessPeriod defaults to 0, neither
> field is necessary.
>
> Importantly, the NDN protocol specifies
> <
> https://urldefense.com/v3/__https://named-data.net/doc/NDN-packet-spec/current/data.html*freshnessperiod__;Iw!!PvXuogZ4sRB2p-tU!R1XTGYwBlOXYUAzHhlV6sAyjq-Qz47wI4GLKSybSpxaQ2vKKrLONq9piKdxFWGIoTdsr$
> >
> :
>
> If the Data does not have a FreshnessPeriod or if it has a FreshnessPeriod
> equal to zero, it MUST be immediately marked “non-fresh”.
> If an Interest contains MustBeFresh element, a node MUST NOT return
> “non-fresh” Data in response to this Interest.
>
> This rule applies to not only the Content Store, but also the forwarding
> pipelines.
> Based on this rule, the Ping Echo Reply packet does not satisfy the Ping
> Echo Request packet, making the ICN Ping incompatible with the current NDN
> packet format.
>
>
> We aim to avoid fetching cached responses from the network (unless a
> request’s base name matches the name of a content object in the CS of a
> forwarder and the client is ok with receiving a cached response). To do
> that in the first place, the operation of a forwarder needs to be different
> than how NFD works right now. So we do not think this is an issue with the
> packet format per se, but rather the operation of the forwarder, which
> needs to be extended/modified to handle ping and traceroute traffic.
>
>
> draft-irtf-icnrg-icnping-04 Section 5.1 says:
>
> Since the NDN packet format does not provide a mechanism to prevent the
> network from caching specific data packets, we use the MustBeFresh element
> for echo requests (in combination with a Freshness Period TLV of value 0
> for echo replies) to avoid fetching cached echo replies with an expired
> freshness period.
>
>
> This still will not work, because an Interest with MustBeFresh cannot be
> satisfied by a non-fresh Data.
> This is enforced not only in NDN forwarders, but also in NDN libraries.
>
> To minimize caching effect, you can either set FreshnessPeriod to 1 (not
> 0), or use a unique name each time (you are already doing this by adding a
> random nonce component), or both.
>
>
> Section 5.2 inserts a "PathSteering TLV" in the Data packet, which appears
> before the Name element.
> The TLV evolvability guidelines of the NDN protocol does not permit adding
> new elements before the Name element.
> New elements should be added later in the packet; to exclude an element
> from the security envelope, it should appear after the SignatureValue
> element.
>
>
> Good point. We have moved the PathSteering TLV after the Signature TLV.
>
> In the case of PathSteering TLV that "might be modified in a hop-by-hop
> fashion", it does not belong in the network layer, but should be added as a
> link layer header in NDNLPv2 or another link layer protocol.
>
> The "PathSteering TLV" cites draft-oran-icnrg-pathsteering, but that
> document only defines a "Path label TLV".
> Its TLV-TYPE number assignment is 0x09, but that number is a "critical"
> TLV-TYPE number that would cause a forwarder that does not understand this
> feature to drop the packet; this choice needs justification.
> Moreover, 0x09 is marked as reserved
> <
> https://urldefense.com/v3/__https://named-data.net/doc/NDN-packet-spec/current/types.html__;!!PvXuogZ4sRB2p-tU!R1XTGYwBlOXYUAzHhlV6sAyjq-Qz47wI4GLKSybSpxaQ2vKKrLONq9piKdxFWM33PpJJ$>
> because
> it conflicts with the former Selectors element in NDN packet format v0.2,
> so that you may need to choose a different number.
> You can then propose a change
> <
> https://urldefense.com/v3/__https://gerrit.named-data.net/admin/repos/NDN-TLV__;!!PvXuogZ4sRB2p-tU!R1XTGYwBlOXYUAzHhlV6sAyjq-Qz47wI4GLKSybSpxaQ2vKKrLONq9piKdxFWA18J1X7$>
> to
> reserve the number in NDN network layer protocol or edit this page
> <
> https://urldefense.com/v3/__https://redmine.named-data.net/projects/nfd/wiki/NDNLPv2__;!!PvXuogZ4sRB2p-tU!R1XTGYwBlOXYUAzHhlV6sAyjq-Qz47wI4GLKSybSpxaQ2vKKrLONq9piKdxFWIEfRn16$>
> to
> reserve the number in NDNLPv2.
>
>
> To some extent, this sounds like an open question to us (i.e., whether
> PathSteering TLV should be a part of the encoding of the base NDN protocol
> or should be included in NDNLPv2). Nevertheless, we believe that since a
> field like HopCount (whose value changes on a hop-by-hop basis) is in the
> base NDN protocol rather than NDNLP, path steering should also be in the
> base protocol, since it too is a hop-by-hop field independent of a
> particular single hop.
>
>
> The "PathSteering TLV" cites draft-oran-icnrg-pathsteering
> <
> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-oran-icnrg-pathsteering-05.html__;!!PvXuogZ4sRB2p-tU!Xz_WVwqvAcMkJkLusl_deBsZ2d92QSiVeCmfC6bOzFHRjdZdhj71JsWc0R-MLLgu6Y3D$
> > ,
> but that document only defines a "Path label TLV", and its encoding differs
> from what's given in Figure 9.
>
> Yours, Junxiao
>
>
> _______________________________________________
> icnrg mailing list
> icnrg@irtf.org
>
> https://urldefense.com/v3/__https://www.irtf.org/mailman/listinfo/icnrg__;!!PvXuogZ4sRB2p-tU!Xz_WVwqvAcMkJkLusl_deBsZ2d92QSiVeCmfC6bOzFHRjdZdhj71JsWc0R-MLBoVZn8p$
>
> DaveO
>
>
> _______________________________________________
> icnrg mailing list
> icnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/icnrg
>
> *External Email*
>