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

[Junxiao Shi <[e-mail]>]

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,
<http://named-data.net/doc/ndn-tlv/>.

The current spec link is:
https://named-data.net/doc/NDN-packet-spec/current/ . It was last updated
in 2022.
You can also cite a specific version on
https://github.com/named-data/NDN-packet-spec 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://datatracker.ietf.org/doc/html/rfc5234> 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://www.ietf.org/archive/id/draft-oran-icnrg-pathsteering-05.html>,
but that document only defines a "Path label TLV", and its encoding differs
from what's given in Figure 9.

Yours, Junxiao