[Ndn-interest] any comments on naming convention?

Tai-Lin Chu tailinchu at gmail.com
Mon Sep 15 17:06:12 PDT 2014

I think at least segmentation name component needs to be defined. If
we remove selectors, then how do we find the next segment name without
a explicit segmentation name component? segmentation in my opinion is
more important than other type like versioning.

On Mon, Sep 15, 2014 at 4:07 PM, Abdelzaher, Tarek <zaher at illinois.edu> wrote:
> Felix,
> At the risk of spamming the list, let me elaborate. What I am arguing for is
> that we do not need unified conventions. Different applications will find
> solutions that are more appropriate to them. Otherwise, there will be too
> many things to add and it is a slippery slope. Assume all we have are name
> strings composed of a concatenation of sub-strings that, as far as the
> network is concerned, are all of the same type (i.e., no special characters,
> markers, delimiters, type values, etc), although from the application's
> perspective can have different semantics.
> Hence, for example, if versions are important to my application, I should
> have version numbers as part of the name space (e.g.,
> /path/data-name/version). To get a specific version, one can ask for it by
> name (e.g., /path/data-name/version-label). To get the latest, there is an
> issue with caching (how long should things be cached before they expire).
> Barring that, one can ask for /path/data-name and have the interest be
> forwarded to the provider assuming that stale versions expired from caches.
> Alternatively, to make sure one bypasses caching, one can have a "no cache"
> bit in the interest or ask for, say,
> /path/data-name/random-unique-substring-encoding-a-request-to-the-app. Since
> the random-unique-substring-encoding-a-request-to-the-app will not match any
> cached names, the interest will be sent to the provider advertising the
> prefix, forwarded up to the application (registered on the face exporting
> the prefix) and invoke an application-layer function that will decode and
> interpret the unique-substring-encoding-a-request-to-the-app. The function
> will then answer the request by returning, say, the name of the requested
> latest version to the client, so it can send a proper interest for the named
> version. I am not suggesting that the above is necessarily a good idea. I am
> just saying there can be many different ways to solve the problem that
> depend on things such as how frequently versions are updated, how big the
> objects are, etc. Hence, I am arguing for simplicity and generality by
> making the underlying support as simple as possible. Philosophically
> speaking, the more "common cases" we think of and the more complex we make
> the underlying name format, the more assumptions we may be making that time
> may break later, causing the work to be potentially more short-lived.
> Tarek
> On 9/15/2014 4:17 PM, Felix Rabe wrote:
>> I agree with a need for simplicity.
>> But maybe we cannot have simplicity so let's look at some use cases that
>> might justify the complexity of the conventions: (I will only discuss
>> versions and timestamps here, as they interest me for my work.)
>> Versions: I can give someone a link to a document, and know that they will
>> see the version I currently see, unmodified, even if there is a newer
>> version. Of course, any participant can always get a newer version.
>> - But: I think applications should come up with conventions in versioning,
>> as one application does not need it, another needs sequential versioning,
>> another (like Git-style source code management) needs a DAG.
>> Timestamps: My measurements are a growing data set of (time, value)
>> tuples. I can access multiple measurements across time for comparisons.
>> - But: Also, this needs to be defined by applications, as
>> time-since-unix-epoch is (I think) unsuitable for a wide range of
>> applications (archaeology, astronomy), where both range and granularity
>> requirements are different. Then, there is vector clocks which work with
>> logical time instead of real time.
>> - Another aspect is that this could just be a special case of versioning,
>> using time as a version "number".
>> Segments: ...
>> Sequence: ...
>> Just some thoughts
>> - Felix
>> On 15/Sep/14 22:05, Abdelzaher, Tarek wrote:
>>> Ok, here is a short perspective from a person who does not write network
>>> code, but rather builds distributed applications:
>>> I feel squeamish about specifying naming conventions at all. I feel that
>>> the design should favor simplicity and should not burden application
>>> developers with having to understand what's better for the network. Hence, I
>>> would argue in favor of names that are just series of bits organized into
>>> substrings whose semantics are up to the application. I would not use any
>>> special bits/characters or other special conventions. I would also most
>>> definitely not embed any assumptions on name conventions into network-layer
>>> code.
>>> As an application developer, I would like to be able to think about name
>>> spaces the way I think of UNIX file-name hierarchies. To put it differently,
>>> I do not want to read a tutorial on UNIX filename design guidelines in order
>>> to ensure that the UNIX file system does file caching, block management, and
>>> other functions efficiently for my application. I want file system plumbing
>>> to be hidden from me, the application developer. A good design is one that
>>> hides such plumbing from the application without impacting efficiency. Same
>>> applies to NDN in my opinion. A discussion of special delimiters, markers,
>>> etc, that enhances efficiency of certain network functions seems to be going
>>> in the opposite direction from what makes NDN general and flexible.
>>> Tarek
>>> On 9/14/2014 10:39 PM, Tai-Lin Chu wrote:
>>>> hi,
>>>> Just some questions to know how people feel about it.
>>>> 1. Do you like it or not? why?
>>>> 2. Does it fit the need of your application?
>>>> 3. What might be some possible changes (or even a big redesign) if you
>>>> are asked to purpose a naming convention?
>>>> 4. some other thoughts
>>>> Feel free to answer any of the questions.
>>>> Thanks
>>>> [1]
>>>> http://named-data.net/wp-content/uploads/2014/08/ndn-tr-22-ndn-memo-naming-conventions.pdf
>>>> _______________________________________________
>>>> 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
> _______________________________________________
> 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