Feature #3592
Updated by Junxiao Shi over 8 years ago
A forwarding strategy often needs to store measurement-entries *per content object* (currently only the Access Strategy does, but there might be more use cases, as it is quite common in the literature, e.g. http://netlab.pkusz.edu.cn/wordpress/wp-content/uploads/2011/10/Flow-aware-traffic-control-for-a-content-centric-network.pdf)
However, currently there is no reliable mechanism to identify the object name. We cannot assume that every application will use the naming scheme of "/.../.../version/sequence" where everything other than the last octet ("sequence") is part of the object name.
The access strategy assumes this naming scheme and saves measurement entries "one level up the interest name" which lead to Bug #3219, as NDN-RTC uses a different naming scheme. I think the problem is more general and stems from the inability to identify the object name.
Here is my proposed solution:
Create a header field in the interest packet that states the length of the object name in number of octets. It should allow negative numbers, which specify how many octets from the end the octet name ends. The Default should be "-1" which equals the current naming conventions for files.
For example with the default of -1, and the name "/arizona/cs/www/index.html/v3/s0" everything other than the last octet "s0" is part of the object name. This works well for files, or everything that ends in exactly one sequence number.
For an NDN-RTC name like "/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera_1469c/mid/key/2991/data/%00%00/23/89730/86739/5/27576" the application could use an object name identifier of -10, to mark "/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera_1469c" as the object name. Or -9 to also include "mid" in the object name.
With this mechanism the application developer can specify which part of the namespace is created by a single producer application and thus should have its own measurement entries. The strategy can just read out the object name of each interests and save the measurement information accordingly, instead of making guesses about naming conventions as it does now.
Any comments or ideas?