NFD

For the scenario you have -- delaying application's response, it can be easily done at the application. What's described here doesn't seem to actually do the delaying and then sending after the delay.

Maybe related to this task -- it would be desirable to allow NLSR nodes to sniff Data packets of a specific prefix. An NLSR process just needs to specify a name prefix. Whenever any Data packet matching the name prefix is received on the multicast link (could be a response to another NLSR process' Interest), it will be delivered to the NLSR process (without this process explicitly expressing the Interest). Is this already implemented?

I had the idea of a sniffing feature (filtering on face, direction, type of packet, and Name prefix) before, but @Jeff thinks it's better to do it in "NDN-way" which means the application should express an Interest for each packet.

Junxiao Shi wrote:

@Jeff thinks it's better to do it in "NDN-way" which means the application should express an Interest for each packet.

A packet sniffer is supposed to be passive. If it starts sending interests, it may modify the state of the network.

I agree that packet sniffer should be passive and shouldn't express Interests, even if those Interest are not forwarded.

This Task is about regular applications who wants to receive passing Data but does not want to transmit Interest.

It's similar to Scope=0 and namespace-base scope control won't help in this case.

I agree with the proposal here. As Junxiao mentions, this is different than a packet sniffer function - it is for applications that wish to listen for but not solicit data from the network. My understanding is that an application would make an API call to enable this LocalControlHeader feature, than just add the header to subsequent Interests that would suppress forwarding of the Interest beyond the local NFD.

I'm unsure about whether this feature deserves a new field in LocalControlHeader.

The alternative is: setting NextHopFaceId=FACE_NULL(255) to tell the strategy not to forward the Interest.

With FACE_NULL, it would be necessary to use client control strategy for this namespace. I feel this is too harsh restriction.

With #2000, strategies are composable.
Just add a building block in front of all strategies that says "if NextHopFaceId is FACE_NULL, then don't forward".