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

[Dirk Kutscher <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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 <
>> [e-mail]>
>> 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 <[e-mail]>
>> 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
>> [e-mail]
>>
>> https://urldefense.com/v3/__https://www.irtf.org/mailman/listinfo/icnrg__;!!PvXuogZ4sRB2p-tU!Xz_WVwqvAcMkJkLusl_deBsZ2d92QSiVeCmfC6bOzFHRjdZdhj71JsWc0R-MLBoVZn8p$
>>
>> DaveO
>>
>>
>> _______________________________________________
>> icnrg mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/icnrg
>>
>> *External Email*
>>

> _______________________________________________
> icnrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/icnrg