Per-application in-memory storage¶

Many NDN applications need to publish data packets. A data packet may have a FreshnessPeriod which indicates how long a node (local fowarders and routers) should wait after the arrival of this data before marking it as stale. As stated in NDN-TLV spec:

Note that the stale data is still valid data; the expiration of FreshnessPeriod only means that the producer may have produced newer data.

The inconsistency between the actually validity of a data packet and its FreshnessPeriod comes from the unpredictability of the future.
In some cases, the data producer cannot predict when a data packet will be replaced by a new version of data packet.
One extreme solution is to set FreshnessPeriod of the unpredictable data packet to 0,
so that whenever the data is request, the interest will be forwarded to the original producer to check whether a new version of data packet has been generated or not.

Fortunately, some data packets are relatively static (i.e., it occasionally changes) and can benefit from network caching.
The FreshnessPeriod becomes a tradeoff between network caching and data freshness.
As a result, during the FreshnessPeriod, the producer will not be bothered by interests for the same data packet.
However, after the FreshnessPeriod, when all the cached copies become stale, the producer should be prepared to receive the interests again.
If, at that time, the data is still valid, the producer should return the same data packet to refresh the cached copies.

It seems that it is beneficial to keep a copy of the valid data packet at the producer side, otherwise the producer has to generate/sign the data packet again and again.
The copy of the valid data packet cannot be stored in the ContentStore of local nfd, because current ContentStore can only tell fresh or stale data, but cannot tell valid or invalid data.
Instead, it is better to provide the storage inside the app, i.e., in-memory storage.

We list several use cases of the in-memory storage.

Use cases¶

PIB Service¶

PIB provides the public information about identities, keys, and certificates.
For example, one may ask PIB for the system default key.
And PIB's reply should be valid until the system default key is changed.
Since PIB cannot predict when the system default key will be changed,
it is more reasonable to set a relatively short FreshnessPeriod for the reply.
As a result, after every FreshnessPeriod, PIB may receive an interest for the system default key, because the cached copy in ContentStore is marked as stale.

In this case, PIB can benefit from the in-memory storage.
By putting the reply into the in-memory storage, PIB can avoid repeatedly generating the same data packet.

Nack¶

When the producer want to explicitly tell consumer some data does not exist for now, it may use the nack data.
However, the producer may not know when the requested data will be generated.
With the same logic, the producer can generate a nack data with short FreshnessPeriod,
and put it into the in-memory storage to avoid repeatedly generating the same nack.
When the requested data has been generated, the producer can replace the nack with the new data in the in-memory storage.

ChronoChat¶

For chatroom discovery, each chatroom needs to publish the chatroom-info data.
Chatroom-info must have finite FreshnessPeriod, so that after FreshnessPeriod, the chatroom-refresh interest will reach one of the chatroom participants.
If the chatroom-info has not changed yet, it is not necessary to generate a new chatroom-info data.

The FreshnessPeriod of a chat message can be set to infinite. However, ContentStore may not guarantee to keep all the chat messages even if they are fresh.
An in-memory storage can help here as a guaranteed storage as long as the process is running.

NLSR¶

NLSR LSA is the same as ChronoChat chat message.

Design¶

Reference¶

There is another type of local storage, which is different from in-memory storage, called Managed ContentStore