[Ndn-interest] any comments on naming convention?

Mon Sep 15 19:13:49 PDT 2014

Coordination of the namespace is needed in some way.  This can be done
directly or indirectly be it pure names, name types, markers or manifests.
This is needed because you need a way for the transport protocol to
communicate.  What is the next item to retrieve? How do you open transport
windows? When are you done transmitting?

You could have every app re-implement a new transport protocol so it can
talk to itself; creating new conventions for every type of communication.
However, most apps will use a library and/or transport layer framework.
These are inevitably creating agreements of some sort. Libraries that
become popular create conventions.

IP doesn¹t define the use of port numbers, TCP does.  Every app could
implement a new transport protocol on top of IP, but instead, most use TCP
or UDP. The same is true for NDN/CCN.  In the case of CCN, we¹ve decided
that the lower ³network layer" offers the ability to use typed components.
 It (the network layer / base protocol), doesn¹t make any assumptions
about the meanings of the types (specially since we use exact matching).
We define other protocols (like the chunking protocol or versioning
protocol) that use one of the name component types to mean something.
Yes, this involves a registry, but it basically means that once this
settles as a standard, it is clear for any node or end device to know what
the meaning is of this component type.

Applications are always free to use the data portion of the names in any
way they see fit. They can have their own conventions, markers, etc. As
things become more and more settled and the community starts adopting
them, they eventually convert into standards, potentially requiring a new
type.

For implementations of the transport (which I believe NDN calls this the
library, of which there are 2 implementations?), the existence of these
types means we know how to behave.  This is specially important when you
have multiple applications interacting (say, multiple browsers and a
multiple servers).

There was already an email on the list talking about how many applications
do not care about what the network does.  We strongly believe in this.  We
don¹t think applications need to be reimplementing reliable delivery,
in-oder delivery, dynamic window allocation, etc.  This is done by the
transport stack (in the case of CCN) or the client library (in the case of
NDN).  The APIs will need to reflect this.

Please don¹t confuse the ability of the applications to name the data with
the names that the network needs to use to communicate at the
interest/content-object level.

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, 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-nam
>>>>ing-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