[Ndn-interest] [EXT] clarification about NACKs
ssignorello at ciencias.ulisboa.pt
Tue May 12 09:17:32 PDT 2020
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).
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
> 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
> and to this link
> 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
> Thank you very much for your time,
> Salvatore Signorello
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ndn-interest