NDN-CCL

I thought that ndn-cxx has putNack so that NFD can send a network Nack to say that a route prefix is unavailable. You are talking about allowing the application to use a network and routing level message as an application Nack to say some particular file is not available.

... If the application wants to tell NFD that it can't respond to Interests for a prefix, then it should unregister that prefix. Then, NFD will send the Nack.

If the application wants to tell NFD that it can't respond to Interests for a prefix, then it should unregister that prefix. Then, NFD will send the Nack.

Unregistering is not always an option. Consider a producer that serves everything under /A except /A/B. It cannot unregister /A because it serves this prefix, but it needs to reply a Nack to any Interest under /A/B, signalling the network to quickly try an alternative path.

Does NFD really work like that? Suppose the network has a route to NFD for /A, and the application registers to receive interests for /A. Then a consumer somewhere sends an interest for /A/B/junxiao/videos/cats.mp4/v1 . It arrives at the producer which sends a network Nack. Will every NFD in the network update its FIB to continue sending interest for /A, but not for /A/B/junxiao/videos/cats.mp4/v1 ?

Receiving a Nack from producer tells NFD forwarding strategy that the content isn't available. The strategy implementation may try alternative paths and stop sending more Interests.

Suppose the producer can answer an interest for older content like /A/B/junxiao/videos/cats.mp4/v0, but not for newer content like /A/B/junxiao/videos/cats.mp4/v1 . So if it gets an interest for /A/B/junxiao/videos/cats.mp4/v1 it sends a network Nack. You say the forwarding strategy will maintain detailed information of the different routing for /A/B/junxiao/videos/cats.mp4/v0 and /A/B/junxiao/videos/cats.mp4/v1 (and possibly hundreds of other differences in which content the producer does or doesn't have). Is that actually implemented?

best-route and self-learning strategies have some implementation of fine-grained forwarding information. These information are stored in NFD’s measurements table. There are thousands of entries, but unused entries will expire after a few minutes.

Hi Junxiao. You needed this first in NDN-JS, right? I added putNack in branch issue/4813-putNack.
https://github.com/named-data/ndn-js/blob/issue/4813-putNack/js/face.js#L981

Can you try it? For example:

face.putNack(interest, new NetworkNack().setReason(NetworkNack.Reason.NO_ROUTE));

In NDN-JS, changes for Face.putNack() are merged to master. It works in my testing. I will proceed to implement this in the other libraries.