<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hi Xiaoke,</div><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 11, 2016, at 12:06 AM, Xiaoke Jiang <<a href="mailto:shock.jiang@gmail.com" class="">shock.jiang@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi Alex,<div class=""> This is really an interesting topics, and I tried to summarize some principles too. And here is my comments.</div><div class="">1. The meaning of "NDN principle" is not very clear (at least to me). I think you do not refer to the design principle of NDN architecture itself, but more or less refer to NDN-based applications. But anyway, to clarify its meaning and usage would make it easier to understand. </div></div></div></blockquote><div><br class=""></div><div>These principles are for the NDN networking protocol, not applications. Yes, there are some implications to the applications, but the objective is to define what the networking protocol should be and do.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">2. I would say REST-style application layer interaction. Since no session is built between producer and consumer, Interest should not rely on context of communication in order to retrieve a data.</div><div class="">This also relates to Interest concurrency, here I mean how many Interests can be sent in parallel. I categories the Interests to two kinds: 1) safe one, which does not change the status of producer, but "read" data only; 2) sensitive one, which may change the status. When there is sensitive Interests, the sequence of Interests is critical; otherwise, multiple Interests can be sent in parallel for better throughput.</div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">3. Apps do not have to worry about scalability, since multiple data source, caching and hop-by-hop flow control effectively enables app to scale its throughput. But apps should avoid to move NDN communication back to end-to-end style by building session manually. (although session may be a must for some apps.)</div></div></div></blockquote><div><br class=""></div><div>I think these points are about application, not networking layer. One can build any type of the application on top of the networking-level provided primitives. It is just a question how much network primitives help the application.</div><div><br class=""></div>---</div><div>Alex</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Xiaoke </div>
</div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Mar 11, 2016 at 3:46 PM, Alex Afanasyev <span dir="ltr" class=""><<a href="mailto:aa@cs.ucla.edu" target="_blank" class="">aa@cs.ucla.edu</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear all,<br class="">
<br class="">
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.<br class="">
<br class="">
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.<br class="">
<br class="">
The latest version of the principles and additional information is available on NDN website:<br class="">
<a href="http://named-data.net/project/ndn-design-principles/" rel="noreferrer" target="_blank" class="">http://named-data.net/project/ndn-design-principles/</a><br class="">
<br class="">
* * *<br class="">
<br class="">
For convenience, here is the current version of the list without additional information:<br class="">
<br class="">
[1] **Universality**:<br class="">
NDN should be a common network protocol for all applications and network environments.<br class="">
<br class="">
[2] **Data-Centricity and Data Immutability**:<br class="">
NDN should fetch uniquely named, immutable “data packets” requested using “interest packets”.<br class="">
<br class="">
[3] **Securing Data Directly**:<br class="">
Security should be the property of data packets, staying the same whether the packets are in motion or at rest.<br class="">
<br class="">
[4] **Hierarchical Naming**:<br class="">
Packets should carry hierarchical names to enable demultiplexing and provide structured context.<br class="">
<br class="">
[5] **In-Network Name Discovery**:<br class="">
Interests should be able use incomplete names to retrieve data packets.<br class="">
<br class="">
[6] **Hop-by-Hop Flow Balance**:<br class="">
Over each link, one interest packet should bring back no more than one data packet.<br class="">
<br class="">
* * *<br class="">
<br class="">
Sincerely,<br class="">
Alex<br class="">
<br class="">
<br class="">_______________________________________________<br class="">
Ndn-interest mailing list<br class="">
<a href="mailto:Ndn-interest@lists.cs.ucla.edu" class="">Ndn-interest@lists.cs.ucla.edu</a><br class="">
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" rel="noreferrer" target="_blank" class="">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><br class="">
<br class=""></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>