[Ndn-interest] [EXT] clarification about NACKs
shijunxiao at email.arizona.edu
Thu May 7 15:21:55 PDT 2020
Excerpts from the NDN protocol (Named Data Networking in Local Area
Networks https://hdl.handle.net/10150/625652 section 2.2.2) regarding
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.
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.
"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.
"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.
Regarding network Nack, an example encoding is: (taken from this test case
See Named Data Networking in Local Area Networks
https://hdl.handle.net/10150/625652 section 3.2.3 and section 6.3.1 for
more information about network Nack.
On Thu, May 7, 2020 at 4:48 PM Salvatore Signorello via Ndn-interest <
ndn-interest at lists.cs.ucla.edu> wrote:
> *External Email*
> Dear members,
> 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.
> 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
> With regard to the former NACK type, according to the latest NDN packet
> specification (0.3
> and to this link
> <https://redmine.named-data.net/projects/ndn-tlv/wiki/ContentType> 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.
> 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 spec
> <https://redmine.named-data.net/projects/nfd/wiki/NDNLPv2> 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.
> The above being said, I would have the two following questions:
> (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.
> (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?
> Could you also please confirm that there are no amendments to be done to
> the above discussion when talking about the latest NDNsim version?
> Thank you very much for your time,
> Salvatore Signorello
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ndn-interest