[Ndn-interest] NDN Protocol Design Principles

[Ignacio.Solis at parc.com]

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.


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?

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”?

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
>