Re: [icnrg] [EXT] I-D Action: draft-irtf-icnrg-icnping-03.txt
Dirk Kutscher <ietf@dkutscher.net> Tue, 12 April 2022 07:43 UTC
Return-Path: <ietf@dkutscher.net>
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 278823A00D3; Tue, 12 Apr 2022 00:43:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Level:
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 1qcovVqagx3u; Tue, 12 Apr 2022 00:43:10 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) (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 69BB43A005F; Tue, 12 Apr 2022 00:43:09 -0700 (PDT)
Received: from [192.168.1.50] ([95.89.114.110]) by mrelayeu.kundenserver.de (mreue107 [212.227.15.183]) with ESMTPSA (Nemesis) id 1N7AEs-1o1SD50uL6-017Z2f; Tue, 12 Apr 2022 09:42:39 +0200
From: Dirk Kutscher <ietf@dkutscher.net>
To: Junxiao Shi <shijunxiao@email.arizona.edu>
Cc: icnrg@irtf.org, Spyridon Mastorakis <smastorakis=40unomaha.edu@dmarc.ietf.org>, "David R. Oran" <daveoran@orandom.net>
Date: Tue, 12 Apr 2022 09:42:33 +0200
X-Mailer: MailMate (1.14r5852)
Message-ID: <D41F4837-DC11-4921-8D24-A5FAFBD3BCB6@dkutscher.net>
In-Reply-To: <CAOFH+OYhWBCDgeYwpQpKx01d_kzJga+qZPjP5YHMgxTPkm82kg@mail.gmail.com>
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> <CAOFH+OYhWBCDgeYwpQpKx01d_kzJga+qZPjP5YHMgxTPkm82kg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_C99B91F8-8913-4E89-869E-82FE75E3572F_="; micalg="pgp-sha1"; protocol="application/pgp-signature"
X-Provags-ID: V03:K1:VsNE9C5sqUqH+ivnP2Hvn7FtwqNByv5sYmbKWjVpBWiauZzqZpY +myUOl1YlniHqFNbW/5lpwQbOeVpaLF5bh4HfZLuN9H/h/ca8y5TDDlKbiLB+3QJFZhHWNg iu1pD1ol8ugkfJ/aMe31xO2iXSUPWqZ8XntgneOARagXPZAlmVI6ltRHqGn+4kHmi9Jj+GC 0SyBUoDsr1k58WcQOmIfA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:UIRixOpflX0=:/rEoFARymW7Y39Xmso8Dq+ +scNWLBulVl26kdHyoJDGFhqRZAhOcXQtphF3J9lMracKifEtTVLjTeCB2miiDKjEtFF4fRLh xTwE3oZCwUJqDtIysqL01BWHuhboBBtqi/EbLIOG1otH6Yb6toIormoYvS7/O2gJdbnYtz89Z DNmXfCLxt3T8DIIN5W3jXyvTx8CFxuWkFO7ItKL/9jwBBm6hO52kp7HzYWhvOYazomeID1hdv S+lUlCuorD7HkAbhxf8rZaKTjdtueiriEZEbY30JJBs0+0o2V8SzyAB5MRW0sPrh/egZ43QG3 kUbUnVNmf/8GEiqsRnoZ4JLr9GBmAxgAR251jCCNZA4FEwTzhVobSEswNa5LaNb4OhqL7psqq 92m3TIDd+NsOZOK0tau0oThXKYAVeAxMuErPIUrUyLJ5AEovG8KyVzraiZPVZD2T+GpH1VK9m otZl9g2pLdjo6lB0HdmpWc8B/OKBHZYWEmKOcN7vvtZFWshCpVlLBft8WdTzMS7e+RGlapwzJ /HyBzy3JxlM01el2XX51nzWZdiy2L7ZQRjTtC9Dd/kUII9CYzgdnP3sCs427b7G3erWNCC4Kk hIhuJVQMvMapQl3/Uw0fYcMxxrClBVzUvjTywlRTf07rXSy2kHWisgbXMZgq49lXLLkGrikpn zeYDwxP2ZlL3YlC26jX9n1C0w96Y3Zpk2bqHeRyY5DSM2Y5BNaJvOr93NqHZ4NBnxr/8=
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/_7Hymg52u6go62kuQivJBKugEK8>
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: Tue, 12 Apr 2022 07:43:16 -0000
Thanks – I'll request IRSG review for both documents shortly. Dirk On 11 Apr 2022, at 18:36, Junxiao Shi wrote: > 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* >> > _______________________________________________ > icnrg mailing list > icnrg@irtf.org > https://www.irtf.org/mailman/listinfo/icnrg
- [icnrg] I-D Action: draft-irtf-icnrg-icnping-03.t… internet-drafts
- Re: [icnrg] [EXT] I-D Action: draft-irtf-icnrg-ic… Junxiao Shi
- Re: [icnrg] [EXT] I-D Action: draft-irtf-icnrg-ic… David R. Oran
- Re: [icnrg] [EXT] I-D Action: draft-irtf-icnrg-ic… Spyridon Mastorakis
- Re: [icnrg] [EXT] I-D Action: draft-irtf-icnrg-ic… Junxiao Shi
- Re: [icnrg] [EXT] I-D Action: draft-irtf-icnrg-ic… David R. Oran
- Re: [icnrg] [EXT] I-D Action: draft-irtf-icnrg-ic… Spyridon Mastorakis
- Re: [icnrg] [EXT] I-D Action: draft-irtf-icnrg-ic… Dirk Kutscher
- Re: [icnrg] [EXT] I-D Action: draft-irtf-icnrg-ic… Junxiao Shi
- Re: [icnrg] [EXT] I-D Action: draft-irtf-icnrg-ic… Dirk Kutscher