NFD

20150922 conference call discussed this bug.

AccessStrategy is designed to handle inaccurate FIB entries, primarily caused by the use of nfd-autoreg.
It may not be necesary when automatic prefix progagaton (formerly remote prefix regstration) can create accurate routes.

Instead of attempting to fix AccessStrategy (which require a redesign in measurements collection), we may as well stop using it.

It's worth noting that the 5GB memory usage on testbed REMAP node probably is not caused by this Bug alone.

• 20775 NameTree nodes and 1288 Measurements entries do not add up to 5GB memory.
  A report from ndnSIM 2.0 says a PIT entry on average can consume 6KB of memory. If we assume each NameTree node consumes 100KB memory (the actual should be less), 20775 nodes is 2GB.
• AccessStrategy extends Measurements entry lifetime to 8 seconds from now, so all entries created should be erased after 8 seconds. However, NDNOPS has reported that the memory use doesn't come down until NFD is restarted. This indicates a potential memory leak somewhere, but most likely it's in Measurements table or AccessStrategy's StrategyInfo object, because it's not reported before AccessStrategy is widely deployed.

Some adjustments are needed on NDN testbed in order to diagnose this problem.
I'll send specific changes to NDNOPS.

NDN-RTC developers have completed one diagnostic test.
In this test, NDN-RTC traffic goes through a testbed node with AccessStrategy, and then the traffic stops.
ContentStore is full throughout the test.

Memory usage and table sizes are recorded.
Selected points are shown in the table:

This observation confirms that the increased Measurements table size is caused by AccessStrategy, and they are erased as expected.

However, nfd memory usage is growing almost steadily during the execution, and it does not release after Measurements entries are erased.
This means there is a memory leak somewhere.
A separate Bug will be created when the source of that leak is found.

The memory leak is confirmed to be #3236.

After fixing #3236, we'll be able to see whether a fix for #3219 is necessary.

Given the impact on NDN-RTC performance on the testbed, can the NFD team please assign this to someone and update the status / plans to resolve.

Given the impact on NDN-RTC performance on the testbed, can the NFD team please assign this to someone and update the status / plans to resolve.

As identified in note-2, applications including but not limited to NdnCon should stop relying on nfd-autoreg for the bulk of communication, but use automatic prefix propagation instead.

This means, each NdnCon participant should publish streams under a prefix covered by his/her testbed certificate (such as ndn:/ndn/guest/someone%40example.com/ndnrtc, instead of ndn:/ndn/guest/ndnrtc/someone%40example.com), so that automatic prefix propagation would create a back route for ndn:/ndn/guest/someone%40example.com from the testbed to the end host.

nfd-autoreg currently is a dependency for certificate fetching in automatic prefix registration, but traffic volume of certificate fetching is much smaller than application traffic.

Ok, let me confirm and then we'll update the namespace. Please provide a pointer to documentation for automatic prefix propagation.

Please provide a pointer to documentation for automatic prefix propagation.

See #3513 note-1.

Just a question: Would my suggestion in #3592 solve the problem of both "too long data names" and "too short data names" or do we need additional design?

Assuming that the consumer knows what the producer can serve, which can be hard-coded or easily determined during the connection set-up.