[Ndn-interest] any comments on naming convention?

Abdelzaher, Tarek zaher at illinois.EDU
Mon Sep 15 20:11:24 PDT 2014


Yes, naming conventions make sense in the context of a trasnport layer 
protocol. This to me is below the application layer, however, so I was 
answering from the perspective of a higher layer. From the perspective 
of transport layer design, we absolutely need conventions that only the 
transport protocol is aware of. In principle, there may be multiple 
transport layer protocols using different conventions optimized for the 
need of different types of applications. In the transport protocol that 
we are currently designing at UIUC, we assumed that all the network 
knows is just strings with no assumptions on structure beyond the fact 
that longer prefixes mean a better match (i.e., a hierarchical 
structure). On top of that, the transport layer uses a few naming 
conventions, but that's a long discussion, probably too long for email. 
In general, this is a topic of interest for me. We are a little isolated 
here at UIUC, but I'd be happy to get involved in any telecons or other 
(higher bandwidth) discussions on how names can be exploited by the 
transport protocol for different application purposes. Our specific 
interest is, let is say, "big data" applications; applications that rely 
primarily on sampling larger data sets for various purposes (because the 
totality of data is overwhelming). Sorry for the digression from the 
naming discussion.

It appears to me that if we are discussing transport layer design in the 
naming conventions document, it may also be good to preface it with the 
types of applications the particular transport is designed for. 
Real-time streaming applications, for example, may need different 
conventions from offline data retrieval applications, and applications 
that need reliability may favor different conventions from those who 
don't... at least in principle. There is no reason to believe that the 
same set of conventions will optimally suit all applications. This is 
another reason, btw, why the network layer should remain completely 
independent of any naming assumptions and conventions made at the 
transport layer - the simpler the better.
Tarek


On 9/15/2014 9:13 PM, Ignacio.Solis at parc.com wrote:
> 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




More information about the Ndn-interest mailing list