[Ndn-interest] any comments on naming convention?

Abdelzaher, Tarek zaher at illinois.EDU
Mon Sep 15 16:07:43 PDT 2014


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
>




More information about the Ndn-interest mailing list