Feature #3592
open
Design mechanism to reliably identify content object name
Added by Anonymous over 8 years ago.
Updated over 7 years ago.
Description
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 such as Flow-aware traffic control for a content-centric network)
However, there is no reliable mechanism to identify the object name.
We cannot assume that every application will use the naming scheme of "/.../.../version/segment" where everything other than the last component (segment) 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.
The problem is more general and stems from the inability to identify the object name.
Related issues
1 (1 open — 0 closed)
- Related to Bug #3219: AccessStrategy measurements ineffective for NDN-RTC traffic added
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 header field should be optional. When it's missing, the strategy should just use the default of "-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.
- Project changed from NFD to NDN Specifications
- Subject changed from Design: Mechanism to reliably identify the object name of an Interest to Design mechanism to reliably identify object name of an Interest
- Description updated (diff)
- Category deleted (
Forwarding)
- Start date deleted (
04/08/2016)
This is moved to ndn-tlv tracker because it involves changing packet format.
Klaus's original proposal is moved out of issue description into note-2.
- Subject changed from Design mechanism to reliably identify object name of an Interest to Design mechanism to reliably identify content object name
- Description updated (diff)
I agree with the relation to #3219.
I know about the granularity problem and its solution space long ago, but I chose a simple solution (one shorter prefix) in the design of access strategy.
A major weakness of note-2 solution, adding a field into Interest packet, is that it expects the consumer to know what namespace a producer can serve.
In many cases, the consumer does not know what the producer can serve.
On the other hand, if the consumer is explicitly told about the prefix served by a producer, this becomes a host-oriented communication rather than name-based communication.
Thanks for putting it into the right category.
Junxiao Shi wrote:
I agree with the relation to #3219.
I know about the granularity problem and its solution space long ago, but I chose a simple solution (one shorter prefix) in the design of access strategy.
A major weakness of note-2 solution, adding a field into Interest packet, is that it expects the consumer to know what namespace a producer can serve.
In many cases, the consumer does not know what the producer can serve.
Can you give any examples?
For video-streaming like NDN-RTC, I assumed that the application developer can code this as fixed parameter into both consumer and producer. Thus, the user of the software doesn't have to worry about it.
Reply to note-5:
In many cases, the consumer does not know what the producer can serve.
Can you give any examples?
Newer version of NDN-RTC protocol, as specified in NDNTR-0033, dropped the last five components, so the names look like:
/<root>/streams/<media-stream>/<media-thread>/frames/<packet-type>/<frame>/<data-type>/<segment>
/ndn/edu/ucla/remap/peter/streams/cam/1920x1080/frames/key/2991/data/%00%00
The prefix served by an official NDN-RTC producer ends at <media-stream> component, hence "object name identifier" according to note-2 proposal is -6.
However, a different producer compatible with NDN-RTC protocol may operate as follows:
- The camera itself only generates one resolution (
<media-thread>).
- A transcoding server retrieves the original resolution from the camera, and derives other resolutions.
The camera and the transcoding server can be placed in different locations. They need separate measurements, and thus the "object name identifier" should be -5.
However, the client should not be aware of such deployment arrangement.
Also available in: Atom
PDF
Updated by