[Ndn-interest] any comments on naming convention?

Tai-Lin Chu tailinchu at gmail.com
Tue Sep 16 16:39:42 PDT 2014

> If not, then LPM for the forwarding can be constrained to the (encapsulated) untyped name components up to the first marker - all following bytes will not influence routing. PIT and CS is another story.

I assume that it is up to and "not including" the first marker. What
you just said in my opinion limits the typed component to be placed in
the end of a name, and I don't think this limit will be good. For
example, /folder1/v1/file1/v2. According to your statement, file1 will
not influence routing, but I think it should.

IMHO, the only one requirement of allocating new types for typed
components is necessity. i.e. Will this typed component help upper
layer or router to process this packet differently (perhaps more

On Tue, Sep 16, 2014 at 3:56 PM,  <christian.tschudin at unibas.ch> wrote:
> Hi Marc,
> a question regarding the insightful encapsulation-to-the-left view (and
> taking up Tai-Lin's routing question):
> I see that demux is useful for end nodes where the applications are sitting.
> But are there important cases where core routers should demux, i.e. forward
> to different faces, based on that handful set of typed components we talk
> about?
> If not, then LPM for the forwarding can be constrained to the (encapsulated)
> untyped name components up to the first marker - all following bytes will
> not influence routing. PIT and CS is another story.
> best, christian
> On Tue, 16 Sep 2014, Marc.Mosko at parc.com wrote:
>> I am not sure why something being a typed name is related to routing.
>> Isn’t routing going to be over the full TLV representation of the name?  Or
>> do you consider the TLV “T” as separate from the name component and not used
>> in FIB or PIT matching?
>> I think a serial version is more useful than a timestamp version.  In CCNx
>> 1.0, we have a type for both, but we generally use the serial version.  A
>> timestamp does not give distributed versioning, so like a serial version it
>> is only useful from a single publisher and it gives an easy way to determine
>> the next version.  It does, of course, require that the publisher maintain
>> state rather than rely on its real-time clock (or ntp) for its version
>> number.  A serial version number also allows unlimited version number
>> generation, whereas a quantized (e.g. milli-second) timestamp limits the
>> number of versions one can generate at a time without keeping state.
>> As a general philosophy on named addresses, I see the hierarchical name
>> components as providing protocol encapsulation, essentially encapsulating
>> name components to the left (not all components are like this, but some
>> are).  For example, when you add a version component to a name it is a
>> statement that a versioning protocol has encapsulated and possibly modified
>> the content object identified by the left name. When a segmentation protocol
>> is applied to a content object, it encapsulates a name to the left.  They
>> serve a similar purpose to header encapsulation in traditional packets.
>> Therefore, I think that when a protocol is encapsulating the left-name,
>> those should be unambiguous and explicit.
>> For protocols that everyone needs to understand, like versioning or
>> segmenting, those should be a standardized value, and not exclusive of other
>> protocols.  Someone might come out, for example, with a better segmentation
>> protocol and that should have a different identifier than the earlier
>> segmentation protocol.  Therefore, wherever you do your multiplexing you
>> need to coordinate.  That’s going to be either in the TLV “T” or in the
>> “key” of a “key=value” inside the “V”.
>> Marc
>> On Sep 16, 2014, at 10:21 AM, Tai-Lin Chu <tailinchu at gmail.com> wrote:
>>> Summarize all types that people need (feel free to add some, and paste
>>> in your reply)
>>> - regular
>>> - segment
>>> - version (timestamp)
>>> - signature
>>> - key: assuming that the next regular component will be value. The
>>> value is empty if it sees another key component immediately after.
>>> - app-specific
>>> However, I am not convinced that we need version, signature, and
>>> app-specific as typed component. Will these change how packet routes?
>>> On Tue, Sep 16, 2014 at 8:47 AM, Junxiao Shi
>>> <shijunxiao at email.arizona.edu> wrote:
>>>> Hi Jeff
>>>> Please see my proposal of MarkedComponent
>>>> <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/2014-September/000085.html>,
>>>> which is a solution to eliminate ambiguity by defining a new type
>>>> specifically for key-value pair.
>>>> Yours, Junxiao
>>>> On Tue, Sep 16, 2014 at 8:18 AM, Burke, Jeff <jburke at remap.ucla.edu>
>>>> wrote:
>>>>> Second, if the most important issue is eliminating ambiguity/aliasing,
>>>>> then why not define a new type that hints that the component can be
>>>>> interpreted as a key/value pair with some encoding convention?  This
>>>>> could
>>>>> enable an unambiguous, short list of commonly used conventions that
>>>>> you've
>>>>> mentioned (using marker-like keys),  while keeping information
>>>>> describing
>>>>> the data object in the name. It would also be very useful for
>>>>> applications
>>>>> that desire their own k/v representation for components, which Dave has
>>>>> argued for in other circumstances and we keep running across. It
>>>>> doesn't
>>>>> rule out use of hierarchy, and doesn't limit what an application
>>>>> defined
>>>>> keys could be.  Yet, it could be ignored in forwarding (just another
>>>>> component) and perhaps have a still-meaningful sort order (key, then
>>>>> value).
>>>> _______________________________________________
>>>> Ndn-interest mailing list
>>>> Ndn-interest at lists.cs.ucla.edu
>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>> _______________________________________________
>>> Ndn-interest mailing list
>>> Ndn-interest at lists.cs.ucla.edu
>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

More information about the Ndn-interest mailing list