<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">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></div><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">this test case</a>)<br></div><div></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">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">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">0.3</a>)
and to this <a href="https://redmine.named-data.net/projects/ndn-tlv/wiki/ContentType" target="_blank">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">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>