[Ndn-interest] any comments on naming convention?

[christian.tschudin at unibas.ch]

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
>
>