[Ndn-interest] [EXT] clarification about NACKs

Tue May 12 09:17:32 PDT 2020

Hi Junxiao,

many thanks for the ref., and for your work indeed, I could answer most 
of my previous questions by reading it.

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 "/Expect More from the Networking: 
DDoS Mitigation by FITT in Named Data Networking/") which consider 
routers understanding (or at least checking for) application-level NACKs 
within their forwarding strategies (if I understand those works well).

Regards,

Salvatore

On 07/05/20 23:21, Junxiao Shi wrote:
> Hi Salvatore
>
> Excerpts from the NDN protocol (Named Data Networking in Local Area 
> Networks https://hdl.handle.net/10150/625652 section 2.2.2) regarding 
> application Nack:
> 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 
> <https://github.com/usnistgov/ndn-dpdk/blob/c1c73f749675c7c65a0755463ffc357839bb1026/ndn/nack_test.go#L19>)
> 6418 LpPacket
>   FD032005 Nack
>     FD03210196 NackReason
> 500D LpPayload
>   050B Interest
>     0703080141 Name
>     0A04A0A1A2A3 Nonce
> 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.
>
> Yours, Junxiao
>
> On Thu, May 7, 2020 at 4:48 PM Salvatore Signorello via Ndn-interest 
> <ndn-interest at lists.cs.ucla.edu 
> <mailto: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 NACKs.
>
>
>     With regard to the former NACK type, according to the latest NDN
>     packet specification (0.3
>     <https://named-data.net/doc/NDN-packet-spec/current/data.html#contenttype>)
>     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,
>
>     regards,
>
>     Salvatore Signorello
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20200512/9f47dac1/attachment.html>