[Ndn-interest] any comments on naming convention?

Ignacio.Solis at parc.com Ignacio.Solis at parc.com
Thu Sep 18 14:02:26 PDT 2014

Does this make that much difference?

If you want to parse the first 5 components.  One way to do it is:

Read the index, find entry 5, then read in that many bytes from the start
offset of the beginning of the name.
Start reading name, (find size + move ) 5 times.

How much speed are you getting from one to the other?  You seem to imply
that the first one is faster.  I don¹t think this is the case.

In the first one you¹ll probably have to get the cache line for the index,
then all the required cache lines for the first 5 components.  For the
second, you¹ll have to get all the cache lines for the first 5 components.
  Given an assumption that a cache miss is way more expensive than
evaluating a number and computing an addition, you might find that the
performance of the index is actually slower than the performance of the
direct access.

Granted, there is a case where you don¹t access the name at all, for
example, if you just get the offsets and then send the offsets as
parameters to another processor/GPU/NPU/etc.  In this case you may see a
gain IF there are more cache line misses in reading the name than in
reading the index.   So, if the regular part of the name that you¹re
parsing is bigger than the cache line (64 bytes?) and the name is to be
processed by a different processor, then your might see some performance
gain in using the index, but in all other circumstances I bet this is not
the case.   I may be wrong, haven¹t actually tested it.

This is all to say, I don¹t think we should be designing the protocol with
only one architecture in mind. (The architecture of sending the name to a
different processor than the index).

If you have numbers that show that the index is faster I would like to see
under what conditions and architectural assumptions.


(I may have misinterpreted your description so feel free to correct me if
I¹m wrong.)

Nacho (Ignacio) Solis
Protocol Architect
Principal Scientist
Palo Alto Research Center (PARC)
Ignacio.Solis at parc.com

On 9/18/14, 12:54 AM, "Massimo Gallo" <massimo.gallo at alcatel-lucent.com>

>Indeed each components' offset must be encoded using a fixed amount of
>Type = Offsets
>Length = 10 Bytes
>Value = Offset1(1byte), Offset2(1byte), ...
>You may also imagine to have a "Offset_2byte" type if your name is too
>On 18/09/2014 09:27, Tai-Lin Chu wrote:
>>> if you do not need the entire hierarchal structure (suppose you only
>>>want the first x components) you can directly have it using the
>>>offsets. With the Nested TLV structure you have to iteratively parse
>>>the first x-1 components. With the offset structure you cane directly
>>>access to the firs x components.
>> I don't get it. What you described only works if the "offset" is
>> encoded in fixed bytes. With varNum, you will still need to parse x-1
>> offsets to get to the x offset.
>> On Wed, Sep 17, 2014 at 11:57 PM, Massimo Gallo
>> <massimo.gallo at alcatel-lucent.com> wrote:
>>> On 17/09/2014 14:56, Mark Stapp wrote:
>>>> ah, thanks - that's helpful. I thought you were saying "I like the
>>>> existing NDN UTF8 'convention'." I'm still not sure I understand what
>>>> _do_ prefer, though. it sounds like you're describing an entirely
>>>> scheme where the info that describes the name-components is ...
>>>> other than _in_ the name-components. is that correct? when you say
>>>> separator", what do you mean (since that's not a "TL" from a TLV)?
>>> Correct.
>>> In particular, with our name encoding, a TLV indicates the name
>>> with offsets in the name and other TLV(s) indicates the offset to use
>>> order to retrieve special components.
>>> As for the field separator, it is something like "/". Aliasing is
>>>avoided as
>>> you do not rely on field separators to parse the name; you use the
>>> TLV " to do that.
>>> So now, it may be an aesthetic question but:
>>> if you do not need the entire hierarchal structure (suppose you only
>>> the first x components) you can directly have it using the offsets.
>>>With the
>>> Nested TLV structure you have to iteratively parse the first x-1
>>> With the offset structure you cane directly access to the firs x
>>> Max
>>>> -- Mark
>>>> On 9/17/14 6:02 AM, Massimo Gallo wrote:
>>>>> The why is simple:
>>>>> You use a lot of "generic component type" and very few "specific
>>>>> component type". You are imposing types for every component in order
>>>>> handle few exceptions (segmentation, etc..). You create a rule
>>>>> the component's type ) to handle exceptions!
>>>>> I would prefer not to have typed components. Instead I would prefer
>>>>> have the name as simple sequence bytes with a field separator. Then,
>>>>> outside the name, if you have some components that could be used at
>>>>> network layer (e.g. a TLV field), you simply need something that
>>>>> indicates which is the offset allowing you to retrieve the version,
>>>>> segment, etc in the name...
>>>>> Max
>>>>> On 16/09/2014 20:33, Mark Stapp wrote:
>>>>>> On 9/16/14 10:29 AM, Massimo Gallo wrote:
>>>>>>> I think we agree on the small number of "component types".
>>>>>>> However, if you have a small number of types, you will end up with
>>>>>>> names
>>>>>>> containing many generic components types and few specific
>>>>>>> types. Due to the fact that the component type specification is an
>>>>>>> exception in the name, I would prefer something that specify
>>>>>>> component's
>>>>>>> type only when needed (something like UTF8 conventions but that
>>>>>>> applications MUST use).
>>>>>> so ... I can't quite follow that. the thread has had some
>>>>>> about why the UTF8 requirement has problems (with aliasing, e.g.)
>>>>>> there's been email trying to explain that applications don't have to
>>>>>> use types if they don't need to. your email sounds like "I prefer
>>>>>> UTF8 convention", but it doesn't say why you have that preference in
>>>>>> the face of the points about the problems. can you say why it is
>>>>>> you express a preference for the "convention" with problems ?
>>>>>> Thanks,
>>>>>> Mark
>>>>> .
>>> _______________________________________________
>>> 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

More information about the Ndn-interest mailing list