[Ndn-interest] any comments on naming convention?

Tai-Lin Chu tailinchu at gmail.com
Mon Sep 15 20:37:39 PDT 2014


First, I am all for typed name component at this moment, but I am
still open to better solutions if exist.

type explosion might mean that (I guessed based on the content in attachment ):
1. we give away all type reserved to developers in name components,
and there is no way to take it back.
2. ..and we soon run out of type that the architecture can define in the future.

But what we really need is maybe just a handful extra types for
components (Maybe first for segment). We can define more as it fits,
so there is no explosion will happen.
Even if this is the case, ccnx will run out of type (2^16 types) much
faster than ndn(2^64 types).


On Mon, Sep 15, 2014 at 7:45 PM,  <Ignacio.Solis at parc.com> wrote:
> Just as a clarification to the document, the current CCNx (1.0) uses typed
> components, we abandoned command markers.
>
> I read the document more throughly. According to page 8, the disadvantages
> to (#1) typed name components are:
> - “type explosion” (still unsure where that is coming from),
> - defining a few components,
> - defining a way to add more,
> - define a URI representation,
> - defining what to do with unknown types.
>
> Aren’t all of these a problem with all options?
>
> The disadvantages to (#2) extra components:
> - aliasing (components can be ambiguous)
>
> The disadvantages to (#3) command markers:
> - aliasing  (components can be ambiguous)
>
>
> Isn’t this a good case for typed components?
>
> To get rid of aliasing you’re basically going to require extra components
> or markers before every other component, effectively using types.
>
>
> Nacho
>
>
> --
> Nacho (Ignacio) Solis
> Protocol Architect
> Principal Scientist
> Palo Alto Research Center (PARC)
> +1(650)812-4458
> Ignacio.Solis at parc.com
>
>
>
>
>
> On 9/15/14, 6:11 PM, "Burke, Jeff" <jburke at remap.ucla.edu> wrote:
>
>>Nacho,
>>I guess I'm not following most of these questions - there are some musings
>>(at least) in the document that try to sketch an alternate perspective to
>>typed components, and most of these questions are covered in some way. I
>>should qualify that they just represent my attempt to provide another side
>>to the argument.
>>Jeff
>>
>>On 9/15/14, 1:22 PM, "Ignacio.Solis at parc.com" <Ignacio.Solis at parc.com>
>>wrote:
>>
>>>What is this ³type explosion² the document is talking about?
>>>
>>>Whether it is a type for a component, a command marker, or a marker
>>>component, there needs to be some agreement on what the meaning of
>>>type/marker is.  If not, then it would just be a regular name component
>>>for a  single application.  So, like Dave says, there needs to be some
>>>registry or overall agreement in some form.
>>>
>>>Wouldn¹t there be the same number of types as command markers?  So you
>>>would basically have ³command marker explosion²? Or is there something
>>>special about command markers?
>>>
>>>
>>>What we are discussing here (I hope) is, what is the best way for
>>>applications to talk about specific meaning of components. (Versions,
>>>Segments, etc).  There are multiple ways to do this.
>>>
>>>- Typed named components are explicit and unambiguous. They always exist.
>>>They can be the Generic type or some special type (like Version).  The
>>>allow arbitrary binary data in a component.
>>>- Command markers may or may not exist. This leads to aliasing if you
>>>allow arbitrary binary data in a component.  If you don¹t allow arbitrary
>>>binary data in a component, then to solve aliasing you need to escape
>>>potentially ambiguous data.
>>>- Command components suffer from the same fate.
>>>
>>>If your data structures do not use component types, then you¹ll have to
>>>escape binary data to have a consistent type/marker system.
>>>
>>>Can somebody describe the disadvantage they see of using typed named
>>>components?  Is it the potential requirement to register? Is it the
>>>limited type space? Is it the extra bytes?
>>>
>>>What is the benefit of command markers over typed named components?
>>>
>>>
>>>
>>>
>>>Is it possible for applications to follow a convention that doesn¹t
>>>create
>>>aliasing? Yes, you could start creating rules that don¹t allow binary
>>>data
>>>of some value in some components if followed by some components, etc.  So
>>>now, any application that wants to put binary data has to check it¹s own
>>>data to make sure it doesn¹t break other apps.
>>>
>>>Sometimes it seems to me that people assume that these names will be
>>>human
>>>readable most of the time. Where is this assumption coming from?  For all
>>>we know everything will be binary.
>>>
>>>Taking my convert-to-CCN hat off for a second I think that it¹s in your
>>>best interest to use component markers, that way if you keep using prefix
>>>matching at least you can request  /foo/bar/v_/* and at least force the
>>>network to get you something that is a version. Having said that, I still
>>>think you¹ll end up doing exact matching soon, but in the meantime might
>>>as well take advantage of it.
>>>
>>>Nacho
>>>
>>>
>>>
>>>
>>>On 9/15/14, 12:12 PM, "Burke, Jeff" <jburke at remap.ucla.edu> wrote:
>>>
>>>>
>>>>Hi all,
>>>>
>>>>
>>>>On 9/15/14, 11:33 AM, "Mark Stapp" <mjs at cisco.com> wrote:
>>>>
>>>>>interesting:
>>>>>
>>>>>On 9/15/14 1:41 PM, Tai-Lin Chu wrote:
>>>>>> I think for naming convention, the community should come up with a
>>>>>> solution that people "want" to use.
>>>>>
>>>>>I think that we should work toward specifying something that does what
>>>>>we've learned (over several years of work) we need to do, and that does
>>>>>not add any additional pain or unnecessary complexity.
>>>>
>>>>So - just to poke at this a bit - who's the "we" here, and whose pain
>>>>and
>>>>complexity?  Application developers, network architects, equipment mfrs,
>>>>or ?  (And do they agree?) As you know, NDN takes an
>>>>application-motivated
>>>>approach to the development and evaluation of the architecture, and NSF
>>>>has asked for this explicitly in their most recent RFP.  If we could
>>>>discuss some pros/cons from that perspective - perhaps via quick
>>>>examples
>>>>or case studies that have led you to this conclusion, it would be
>>>>helpful
>>>>(in my mind) to this current discussion.
>>>>
>>>>Attached are some previously shared thoughts on segmenting and
>>>>versioning
>>>>conventions related to this discussion, and some arguments against
>>>>types,
>>>>after page 2. Though Junxiao's marker type is an interesting new twist,
>>>>I
>>>>am so far unconvinced that it addresses all of the concerns in this doc.
>>>>
>>>>Note - these were not originally intended for a public discussion, at
>>>>least not in this form, so be kind. :) I can also imagine that some of
>>>>the
>>>>discussion could be dismissed via "drop selectors and add manifests" but
>>>>would suggest addressing the spirit of argument in light of the current
>>>>NDN architecture instead.
>>>>
>>>>(Unfortunately I am on the road so not sure I can keep up with the
>>>>discussion, but wanted to inject some other perspectives. :)
>>>>
>>>>Thanks,
>>>>Jeff
>>>>
>>>>>
>>>>>>
>>>>>> Could you describe the ambiguous case? I think I know what you mean
>>>>>>by
>>>>>> ambiguous, but I just want to make sure. (I remembered someone from
>>>>>> cisco mentioned this in ndncomm 2014.)
>>>>>>
>>>>>> To avoid ambiguity, I will start from name component tlvs and
>>>>>>allocate
>>>>>> more types for different meanings.
>>>>>>
>>>>>> 8 = regular name component
>>>>>> <type> = segmented name component
>>>>>>
>>>>>
>>>>>yes, this is the approach I favor. typed name components allow us to
>>>>>identify the 'infrastucture' data in name components, while allowing us
>>>>>to set aside some number space for application-defined components. code
>>>>>that just wants to compare names or identify component boundaries needs
>>>>>to be able to treat the components as 'opaque', of course.
>>>>>
>>>>>Thanks,
>>>>>Mark
>>>>>_______________________________________________
>>>>>Ndn-interest mailing list
>>>>>Ndn-interest at lists.cs.ucla.edu
>>>>>http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>>
>>>
>>>--
>>>Nacho (Ignacio) Solis
>>>Protocol Architect
>>>Principal Scientist
>>>Palo Alto Research Center (PARC)
>>>+1(650)812-4458
>>>Ignacio.Solis at parc.com
>>>
>>
>>
>>_______________________________________________
>>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