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

From: Spyridon Mastorakis <[email-masked]>
Date: Sun, 6 Mar 2022 23:52:40 +0000

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 <[email-masked]<mailto:[email-masked]>> 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.

Section 5.1 defines that the Name of a Ping Echo Request should have a "ping" suffix, so that it can be identified as a Ping Echo Request.
Since NDN packet format v0.3, name components that require special processing should use a KeywordNameComponent (TLV-TYPE 0x20) rather than a GenericNameComponent.
This helps to avoid conflicts with existing protocols, such as the ndnping application<https://urldefense.com/v3/__https://github.com/named-data/ndn-tools/tree/585e18a5e3be4d2d33053dbad2223e5d986d65fa/tools/ping*ndnping-protocol__;Iw!!PvXuogZ4sRB2p-tU!R1XTGYwBlOXYUAzHhlV6sAyjq-Qz47wI4GLKSybSpxaQ2vKKrLONq9piKdxFWF1AnGgy$>.

Fixed.

Section 5.1 defines Ping Echo Request to be an Interest with MustBeFresh "selector".
NDN packet format has eliminated the concept of selectors.
It's called "MustBeFresh element" now.

Fixed.

Section 5.1 mentions a "Parameters" element.
It's been renamed to "ApplicationParameters".
Also, the inclusion of an ApplicationParameters requires the inclusion of a ParametersSha256DigestComponent somewhere in the Name (it does not have to be the last component).
It's necessary to specify where this component should be placed.

We have addressed this comment in Section 5.1.

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.

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.

Thanks,
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

Yours, Junxiao

On Mon, Oct 25, 2021 at 4:17 PM <[email-masked]<mailto:[email-masked]>> wrote:
External Email

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Information-Centric Networking RG of the IRTF.

        Title           : ICN Ping Protocol Specification
        Authors         : Spyridon Mastorakis
                          Jim Gibson
                          Ilya Moiseenko
                          Ralph Droms
                          Dave Oran
        Filename        : draft-irtf-icnrg-icnping-03.txt
        Pages           : 20
        Date            : 2021-10-25

Abstract:
   This document presents the design of an ICN Ping protocol.  It
   includes the operations of both the client and the forwarder.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-irtf-icnrg-icnping/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-irtf-icnrg-icnping/__;!!PvXuogZ4sRB2p-tU!R1XTGYwBlOXYUAzHhlV6sAyjq-Qz47wI4GLKSybSpxaQ2vKKrLONq9piKdxFWDngDz72$>

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-irtf-icnrg-icnping-03.html<https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-irtf-icnrg-icnping-03.html__;!!PvXuogZ4sRB2p-tU!R1XTGYwBlOXYUAzHhlV6sAyjq-Qz47wI4GLKSybSpxaQ2vKKrLONq9piKdxFWHAoh8T7$>

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-irtf-icnrg-icnping-03<https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-irtf-icnrg-icnping-03__;!!PvXuogZ4sRB2p-tU!R1XTGYwBlOXYUAzHhlV6sAyjq-Qz47wI4GLKSybSpxaQ2vKKrLONq9piKdxFWNsF9P5L$>

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/<https://urldefense.com/v3/__ftp://ftp.ietf.org/internet-drafts/__;!!PvXuogZ4sRB2p-tU!R1XTGYwBlOXYUAzHhlV6sAyjq-Qz47wI4GLKSybSpxaQ2vKKrLONq9piKdxFWEPncuiM$>

_______________________________________________
icnrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/icnrg<https://urldefense.com/v3/__https://www.irtf.org/mailman/listinfo/icnrg__;!!PvXuogZ4sRB2p-tU!R1XTGYwBlOXYUAzHhlV6sAyjq-Qz47wI4GLKSybSpxaQ2vKKrLONq9piKdxFWOFH0Dtj$>

_______________________________________________
icnrg mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.com/v3/__https://www.irtf.org/mailman/listinfo/icnrg__;!!PvXuogZ4sRB2p-tU!R1XTGYwBlOXYUAzHhlV6sAyjq-Qz47wI4GLKSybSpxaQ2vKKrLONq9piKdxFWOFH0Dtj$