<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Junxiao,</p>
<p>many thanks for the ref., and for your work indeed, I could
answer most of my previous questions by reading it. <br>
</p>
<p>I am still trying to weigh up the assumption of certain works
(e.g., the defense mechanism originally proposed in the
Producer-Assisted-Pushback [NDN-0065] and afterwards refined in "<i>Expect
More from the Networking: DDoS Mitigation by FITT in Named Data
Networking</i>") which consider routers understanding (or at
least checking for) application-level NACKs within their
forwarding strategies (if I understand those works well). <br>
</p>
<p>Regards,</p>
<p>Salvatore<br>
</p>
<div class="moz-cite-prefix">On 07/05/20 23:21, Junxiao Shi wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAOFH+OYo2MDW_A-dJt8PedKywxTRepDz_Q7hrMe2o8RHA94Zrg@mail.gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">
<div>Hi Salvatore</div>
<div><br>
</div>
<div>Excerpts from the NDN protocol (Named Data Networking in
Local Area Networks <a
href="https://hdl.handle.net/10150/625652" target="_blank"
moz-do-not-send="true">https://hdl.handle.net/10150/625652</a>
section 2.2.2) regarding application Nack:</div>
<div style="margin-left:40px">As a special case, the Data
could be an attestation by a data producer that the
requested content does not exist. This special Data must be
signed by the data producer, and from network point of view
it satisfies the Interest just like a regular Data. In case
the requested content would be generated in the future, the
packet payload may inform the consumer to re-express the
Interest after waiting a certain period of time.</div>
Note that in this protocol spec, the term "application Nack"
is avoided in favor of "attestation that the content does not
exist" to avoid confusion.<br>
<div><br>
</div>
<div>"from network point of view it satisfies the Interest
just like a regular Data" means that network forwarders
should process such a Data packet like any other Data
packet, and no special treatment is allowed.</div>
<div><br>
</div>
<div>"the packet payload may inform the consumer to re-express
the Interest after waiting a certain period of time"
indicates that the Content is not required to be empty. What
goes into the Content of such a Data packet is determined by
the application (i.e. agreement between consumer and
producer), and has no meaning in network layer.<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>Regarding network Nack, an example encoding is: (taken
from <a
href="https://github.com/usnistgov/ndn-dpdk/blob/c1c73f749675c7c65a0755463ffc357839bb1026/ndn/nack_test.go#L19"
target="_blank" moz-do-not-send="true">this test case</a>)<br>
</div>
<div><span style="font-family:monospace">6418 LpPacket<br>
</span></div>
<div><span style="font-family:monospace"> FD032005 Nack<br>
</span></div>
<div><span style="font-family:monospace"> FD03210196
NackReason<br>
</span></div>
<div><span style="font-family:monospace">500D LpPayload<br>
</span></div>
<div><span style="font-family:monospace"> 050B Interest<br>
</span></div>
<div><span style="font-family:monospace"> 0703080141 Name<br>
</span></div>
<div><span style="font-family:monospace"> 0A04A0A1A2A3
Nonce<br>
</span></div>
<div>See Named Data Networking in Local Area Networks <a
href="https://hdl.handle.net/10150/625652" target="_blank"
moz-do-not-send="true">https://hdl.handle.net/10150/625652</a>
section 3.2.3 and section 6.3.1 for more information about
network Nack.
</div>
<div><br>
</div>
<div>Yours, Junxiao<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, May 7, 2020 at 4:48
PM Salvatore Signorello via Ndn-interest <<a
href="mailto:ndn-interest@lists.cs.ucla.edu"
target="_blank" moz-do-not-send="true">ndn-interest@lists.cs.ucla.edu</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<p style="text-align:center"><font color="red"><b>External
Email</b><br>
</font></p>
<p>Dear members,</p>
<p>I am trying to understand how NACK packets look like in
the current NDN codebase. I am aware that the NACK
functionality has been extensively debated over time
among this community, but I have only partially followed
this thread, so please bear with me if I am missing any
important point I should know. Your guidance will be
very much appreciated.<br>
</p>
<p><br>
</p>
<p>I am not sure whether that exact difference still holds
or not, but in my mind I am following the difference
between application(producer)-level NACK and
forwarding-NACK which I have learned from the "To NACK
or not to NACK?" paper of Compagno et al. And,
conceptually that difference seems to hold in the NDN
too since I could find both application-level NACKs and
network NACKs.<br>
</p>
<p><br>
</p>
<p> With regard to the former NACK type, according to the
latest NDN packet specification (<a
href="https://named-data.net/doc/NDN-packet-spec/current/data.html#contenttype"
target="_blank" moz-do-not-send="true">0.3</a>) and to
this <a
href="https://redmine.named-data.net/projects/ndn-tlv/wiki/ContentType"
target="_blank" moz-do-not-send="true">link</a> from
the project specifications page on the NDN official
website, application-level NACKs are carried within Data
packets with a specific content type. The specification,
however, does not specify yet how exactly the NACK
field/payload would look like. More specifically, please
see my question (a) below.</p>
<p><br>
</p>
<p>With regard to the latter NACK type, network NACKs are
generated through a Nack header field in NDNLPv2 packets
carrying interests. At first, by digging into the
ndn-cxx 0.7.0 library (files nack-header.cpp/hpp) it
could find out that the network-level NACK header is
currently encoded with a single TLV, where the Value
contains a NACK code. But, afterwards, checking the
NDNLPv2 <a
href="https://redmine.named-data.net/projects/nfd/wiki/NDNLPv2"
target="_blank" moz-do-not-send="true">spec</a> it
looks like that header is made of two nested TLVs
instead, where to specify a nack-type and a nack-reason.
I am wondering what's the difference between these two
and what would a nack-type mean a that level.<br>
</p>
<p><br>
</p>
<p>The above being said, I would have the two following
questions:<br>
</p>
<p>(a) Is an application-level NACK supposed to carry an
empty payload in NDN? In particular I am wondering if an
application-level NACK could contain additional
arbitrary data.<br>
</p>
<p>(b) any initial thoughts/considerations about what NDN
routers should/shouldn't do with application-level
NACKs? Here, Is there any reference I should look at?<br>
</p>
<p><br>
</p>
<p>Could you also please confirm that there are no
amendments to be done to the above discussion when
talking about the latest NDNsim version?<br>
</p>
<p><br>
</p>
<p>Thank you very much for your time,</p>
<p>regards,</p>
<p>Salvatore Signorello<br>
</p>
</div>
<br>
</blockquote>
</div>
</div>
</blockquote>
</body>
</html>