[Ndn-interest] NDN Protocol Design Principles

Alex Afanasyev aa at CS.UCLA.EDU
Sun Mar 13 12:25:35 PDT 2016


> 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.)

> 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.

> 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.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160313/aa466af6/attachment.bin>


More information about the Ndn-interest mailing list