NFD

There are three distinct scenarios where persistent PIT entry may be useful:

• In NFD Management Notification Stream, the notification subscriber can express only one Interest and get all notifications.
• In repo-ng Watched Prefix Insertion Protocol, the repo can express only one Interest and get all Data packets under the watched prefix.
  This is particularly useful for collecting Data from sensors, where a sensor broadcasts Data packets onto a wireless channel without waiting for or responding to Interests. Without persistent PIT entry, between the repo processing one Data packet and expressing another Interest, if the sensor broadcasts another Data packet, that Data packet would be deemed unsolicited and dropped.
• On a broadcast channel with redundant servers, the secondary server wants to overhear a response from the primary server, and if the primary server doesn't respond, the secondary server can generate the response. Same scenario applies for "redundant sensors" in a sensor network that can supply the same reading.

These scenarios are all reasonable.

The fundamental problem behind these scenarios is shown in Content-based publish/subscribe networking and information-centric networking:

• NDN is a receiver-driven architecture. It's designed for on-demand content delivery, and good for persistent information.
• Another category of communication is publish/subscribe event notification.

This "persistent PIT entry" is an attempt to implement pub/sub on top of on-demand, which is similar to "long-lived Interests" in that paper.
As argued in the paper, "it makes little sense to implement one (pub/sub) on top of the other (on-demand)", and "each requires some level of specialized support in an underlying network fabric".

Therefore, I think we should consider to add pub/sub in the architecture, instead of trying to implement pub/sub on top of existing architecture.

20150715 conference call discussed this proposal.

Beichuan's idea is: you can't push Data to a consumer application.
An incoming unsolicited Data is either:

• dropped.
• queued in socket buffer, so application can read it sequentially.
• cached in ContentStore, so application can express an Interest to retrieve it.

What we should have is:

• Tell ContentStore to cache unsolicited Data under certain prefix (hopefully this can filtered by name prefix, useful in both sensor network and vehicular network).
• Consumer (eg. repo-ng watched prefix insertion) still should send Interests to retrieve from ContentStore.

Therefore, this proposal is rejected.

Junxiao mentioned a feature on original NFD roadmap: wiretap.

This feature allows a monitoring utility to receive a copy of all network layer packets sent or received by NFD.

1. A monitoring utility sets a filter. The filter can condition on: FaceId, direction (in/out), packet type (Interest/Data/Nack), Name prefix.
2. Face system matches every incoming and outgoing packets against wiretap filters.
3. Each matching packet is delivered to the monitoring utility, with {FaceId, direction} indicated on the NDNLPv2 header.