[Ndn-interest] NDN Protocol Design Principles

Ignacio.Solis at parc.com Ignacio.Solis at parc.com
Mon Mar 14 11:33:10 PDT 2016


On 3/13/16, 12:25 PM, "Alex Afanasyev" <aa at cs.ucla.edu> wrote:



>
>> On Mar 11, 2016, at 12:26 AM, Ignacio.Solis at parc.com wrote:
>> 
>> I think it’s great to have spelled out protocol principles. It definitely lets people discuss things in a way that distinguishes the principle from the embodiment.  You can then evaluate the tradeoffs that you’re making.  It also helps frame the question as to why something is a principle at all.  Is it a direct benefit? Or is it just a limitation so we don’t explore the complete answer space?
>> 
>> One thing that you do not touch upon, is where in the layers (or lack-of-layers), something happens. Whether something is part of the “core/base” protocol or in a layer above it (or bellow it).  What are the assumptions about what is provided bellow and what are the assumptions about what you provide at the top? Is there any structure internally that matters, if so, what?
>> 
>> For example, if there is a weather data set that is 2 gigs in size, is that something that is handled by NDN, a part of NDN, or something that runs on top of NDN?  This makes some of the choices of the principles have different meanings.
>> 
>> The main web page for UCLA cannot be immutable. Just like my bank account cannot be immutable.  Surely some part of that can be immutable, and some part of that can have a name, but I assume there is a way to name the UCLA main web page, or my bank account.
>
>Immutable data packet does **NOT** mean that the content of UCLA page cannot be changed.  It means that the specific and uniquely named data packet will not ever change.  The UCLA page is simply representable with differently named data packet(s) at different points of time.  The whole point of the data immutability is to provide coordination in a distributed system.
>
>(I would recommend reading "Immutability Changes Everything" by P. Helland http://dx.doi.org/10.1145/2844112 and related works.)

Maybe it wasn’t clear that I’m in favor of Immutability at many layers.  Whether we’re talking about packets, reduplicated blocks, strings in python or RDDs.  

My point was that it is unclear from the principles what layers we’re talking about.  When people talk about NDN (or CCN for that matter) they refer to a lot of different things.  So, while I’m happy to push for immutability of packets, we need to be clear where we are talking about.

Also, note that the text in the web-page is a little bit misleading.  Quoting from the page:
"Data packet immutability allows disambiguation of coordination in distributed system that may not be always connected. Although data packets are immutable, applications can make changes to the communicated content by creating new versions of immutable data packets.”

What does it mean to create “new versions of immutable data packets”?  If they are immutable, how do you make changes?

My guess is that there is some other concept that is missing.  The concept of a “big object” or a group, or some other “named entity”.  And this is the thing that has versions. And each version is composed of immutable data packets.

I would suggest that this must be clarified.


>> I will make some comments on the principles in separate emails.  I do have one opening question.  Is performance/efficiency not a principle at all?  Would we be ok with a protocol that meets all of these principles but it’s not better in performance than the alternatives?  Do we think that performance comes from these principles?  Do we think performance doesn’t matter?  Do we think that performance doesn’t matter yet? Do we think performance will come later? Or is performance implied as an overarching goal?
>
>Performance is important, but it cannot be a principle for the networking architecture.  The first priority is the goals and general principles of the architecture.  Then there is engineering on how to ensure that everything can work efficiently.
>
>As a historical perspective.  If "performance" was the primary goal for IP, we wouldn't have it as the whole TCP/IP stack was considered extremely inefficient (Lixia, Van, and other can add more to this).  It is the superior functionality of the IP that made it widespread and then highly optimized.

TCP/IP did have a goal to be better than the previous networks.   It is true that it did not _offer_ better “performance” than the previous networks in many areas, but the goals was to make the network better.

Quoting Dave Clark[1]: "The top level goal for the DARPA Internet Architecture was to develop an effective technique for multiplexed utilization of existing interconnected networks.”

Note the use of the word effective; which Dave then tries to elaborate further down the paper.  Also note that Dave talks about an alternative approach and part of the issue is a way to determine which approach was the right one.

Since we’re on the subject; the second level goals from Dave’s paper:
1. Internet communication must continue despite loss of networks or gateways.
2. The Internet must support multiple types of communications service.
3. The Internet architecture must accommodate a variety of networks.
4. The Internet architecture must permit distributed management of its resources.
5. The Internet architecture must be cost effective.
6. The Internet architecture must permit host attachment with a low level of effort.
7. The resources used in the internet architecture must be accountable


Note that these try to focus on the goal, not how the goal is achieved.

To me, the principles that were sent seem more like “design choices”, not principles or goals.

For example; why is “Securing Data Directly” a principle/property/goal at this layer?  There should be some good justification of why this was done and we didn’t choose a different approach.  Why is this not a transport level issue?  Or an application level issue?

I’m picking this mostly because I think it should be one of the easy ones to justify, no? But the same should be true for all principles.

>> Also, as a philosophical question; have you thought about framing the issue as “these are the problems we are trying to solve” instead of “this is what we think the end-goal is”?
>
>Among the principles, there is a little bit of mix, but of slightly different things.  There is a principles that is an overarching goal (e.e., universality) and there are principles about the directions we are achieving the overarching goal.  I would call the latter "the feature to realize", not problems.

So you’re saying that the principles are not really principles?

Can we then clarify, what each principle is? A goal, a problem, a design decision, etc.


Nacho





[1] The Design Philosophy of the DARPA Internet Protocols - http://ccr.sigcomm.org/archive/1995/jan95/ccr-9501-clark.pdf


>
>---
>Alex
>
>> 
>> Nacho
>> 
>> PS- Yes, I realize some of these questions can apply to CCN as well.
>> 
>> 
>> --
>> Nacho (Ignacio) Solis
>> Protocol Architect
>> Principal Scientist
>> Palo Alto Research Center (PARC)
>> +1(650)812-4458
>> Ignacio.Solis at parc.com
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On 3/10/16, 11:46 PM, "Ndn-interest on behalf of Alex Afanasyev" <ndn-interest-bounces at lists.cs.ucla.edu on behalf of aa at CS.UCLA.EDU> wrote:
>> 
>>> Dear all,
>>> 
>>> Recently, we have been working to formalize a list of basic principles that underly the design of the NDN architecture.  We have assembled the initial list of 6 principles and would like to ask everybody for the all kind of feedback about the identified principles, other potential principles, wording clarification, etc.
>>> 
>>> We also hope that the NDN design principles will start a new round of public architectural discussions, clarifying the current and future design decisions and overall architecture objectives.
>>> 
>>> The latest version of the principles and additional information is available on NDN website:
>>> http://named-data.net/project/ndn-design-principles/
>>> 
>>> * * *
>>> 
>>> For convenience, here is the current version of the list without additional information:
>>> 
>>> [1] **Universality**:
>>>   NDN should be a common network protocol for all applications and network environments.
>>> 
>>> [2] **Data-Centricity and Data Immutability**:
>>>   NDN should fetch uniquely named, immutable “data packets” requested using “interest packets”.
>>> 
>>> [3] **Securing Data Directly**:
>>>   Security should be the property of data packets, staying the same whether the packets are in motion or at rest.
>>> 
>>> [4] **Hierarchical Naming**:
>>>   Packets should carry hierarchical names to enable demultiplexing and provide structured context.
>>> 
>>> [5] **In-Network Name Discovery**:
>>>   Interests should be able use incomplete names to retrieve data packets.
>>> 
>>> [6] **Hop-by-Hop Flow Balance**:
>>>   Over each link, one interest packet should bring back no more than one data packet.
>>> 
>>> * * *
>>> 
>>> Sincerely,
>>> Alex
>>> 
>




More information about the Ndn-interest mailing list