[Ndn-interest] NDN Protocol Design Principles

Tue Mar 15 10:41:34 PDT 2016

Hi,
  I'm usually just a lurker, but I really like the idea of a set of
principles as a primary point of understanding the system.

That said, the discussion is all over the place with a mix of principles,
goals, strategies and so forth.

Could we perhaps reset and agree that a set of principles are essential
characteristics of the system, such that the effective operation or use of
the system would be impossible if any one of the principles were to be
ignored?

To Solis' point about layers, each layer can have its principles.  Perhaps
the principles can inform how the layers are formulated.

To Stapp's point, we ignore security at our own peril.

On Tue, Mar 15, 2016 at 10:01 AM, <Ignacio.Solis at parc.com> wrote:

> On 3/15/16, 9:09 AM, "Ndn-interest on behalf of Burke, Jeff" <
> ndn-interest-bounces at lists.cs.ucla.edu on behalf of jburke at remap.UCLA.edu>
> wrote:
>
>
> >>>> Is performance/efficiency not a principle at all?
> >>>
> >>>Do you mind explaining what performance specifically (packet
> encoding/decoding, forwarding, or something else)?
> >>
> >>Sure: being better than current networks at something; anything.
> >>
> >>I don’t think the principles reflect this well.
> >>
> >>That could be faster packet encoding, faster forwarding, more resilient
> routing, less failures, lower latency, higher privacy, higher security,
> better redundancy, lower hardware cost, lower overhead (less systems
> required?  maybe like dns or something), etc.
> >
> >
> >Whether or not this sort of thing is a principle, I'm not sure. (It's
> possible to have a goal that is not a design principle, I think.) But I'd
> also suggest that *if* performance is considered as a principle or goal, it
> should be in parallel with considerations that reflect total cost of
> application development and deployment, like expressiveness, closeness of
> mapping between the network and applications, etc.  As I've suggested
> elsewhere one starting point is Green, Thomas R. G., and Marian Petre.
> "Usability analysis of visual programming environments: a ‘cognitive
> dimensions’ framework." Journal of Visual Languages & Computing 7.2 (1996):
> 131-174.
>
> Those are all fine goals/principles/etc to have, parallel or primary.
> However, they, like many others, can be done at many layers.  If we want a
> specific layer to have them as their driving goals we should justify why.
>
> The total cost of application development seems something closer to what
> you expect achieve via a stack and services, not necessarily related to the
> en maximum length of packets, or for that matter to flow balance. The same
> thing is true about expressiveness.
>
> I have not read your reference so I don’t have a good basis for
> comparison, but I’m absolutely in favor of having usable
> programming/application/deployment environments.  But this to me does not
> imply a translation of one-to-one to how things are done at the network
> layer.
>
>
> >Or, put perhaps more broadly, the way the architecture frames the world /
> motivates application design is important, too.  "A chief service of a
> designer is helping clients discover what they want designed."  - FP
> Brooks, The Design of Design.
>
> Again, that’s a fine point if we talk about an architecture.  But in that
> mode the architecture encompasses a lot of things, not just the bottom most
> protocol.  The architecture encompasses flow control, application level
> naming, identities, programming APIs, abstract data structures, push
> primates, etc.
>
>
> >
> >
> >>
> >>In my opinion, there has to be some justification as to why something is
> a principle. Why is this principle good or required if it is not natively a
> good one.
> >
> >Agreed. (Fortunately I am not organizing the articulation of principles
> so it is easy to agree. :)
> >
> >>
> >>For example, Universality.  Why is this good? Is it good because it
> doesn’t discriminate? Or is it good because it reduce complexity? (which in
> turn could be good because it reduces bugs, etc).  If so, make that the
> goal. Make that the principle: “to make a simpler system” or whatever.
> >
> >
> >Not sure about this. There does need to be justification but simply to
> swap out design principles for their motivation is probably to end up in
> something that is too general to be used for design itself.  If they are
> abstracted to far (Eventually this reduces to "The world should be better
> because this thing exists.") it will be really hard to make decisions based
> on them.  Seems like a balance to strike through iterative discussion like
> this.
>
> Oh yes, don’t get me wrong, you can’t start coding if your goal is just
> “lower latency”.  But you start from there and drill down as choices are
> considered and decisions are made.  The problem with having something down
> the chain as a “principle” means that we set something in stone that wasn’t
> our end goal or we have to change principles half way through.
>
> What we’re trying to get to is different than how we’re trying to get
> there and why we’re trying to get there.
>
> Where do these principles fit?
>
> Nacho
>
>
> >>>> On Mar 11, 2016, at 12:48 AM, Ignacio.Solis at parc.com wrote:
> >>>>
> >>>>
> >>>>> [1] **Universality**:
> >>>>>   NDN should be a common network protocol for all applications and
> network environments.
> >>>>
> >>>> I’m assuming here that you imply a set of protocols. After all, the
> way you do flow control varies a lot from DTN to non-DTN environments. Or
> are you limiting this to the basic packet format?
> >>>>
> >>>> On the web page it calls out for DTN, IoT, Mesh networks, Web, etc.
> It seems obvious to me that these require various protocols; potentially
> layered or interoperating in some fashion.
> >>>>
> >>>> If one interprets this principle as “the base protocol will allow…”,
> then the question becomes how does the base protocol allow this.
> >>>>
> >>>> The document states that the protocol should be flexible and
> extensible. It then states that there should be no fixed parts or fixed
> length fields in the header.  I’m unsure what the full rationale is here.
> Is it that we will exceed the length of the fields? Or that suddenly one
> field will become obsolete and we will want to remove it?  Is it because we
> don’t want to make assumptions about packets coming in?  We want them to be
> so flexible that anything is possible?
> >>>>
> >>>> In one way or another, we’re making assumptions about the packet
> coming in.  If it’s not the static header, it’s the fact that the way we
> parse the packet has to be consistent.  (As in, the first bit determines if
> the next byte is a continuation of the first byte, etc).   So, to some
> degree, you are fixing some formatting.
> >>>>
> >>>> In one assumption, (fixed header), we are limiting the format and
> semantics of the first n bytes (8 or 16 or whatever). In the other space,
> you’re limiting the format (but maybe not the semantics of the first n
> bytes).  You trade off some processing for some byte inefficiency.
> >>>>
> >>>> The fact that we want the same protocol to work on IoT, datacenter
> and interplanetary networks effectively says:
> >>>> - The benefits we get from optimizing for each of these scenarios are
> less important than the advantage we get by having a single protocol format
> that runs in all.
> >>>>
> >>>> It seems to me that having a single protocol is useful when traffic
> goes from one to the other.  If we don’t expect traffic to go from one to
> the other the benefit diminishes.  Here I’m assuming native network
> compatible traffic. So that one packet, comes from IoT and unmodified goes
> to the datacenter and unmodified goes to Mars.  As opposed to having
> gateways that can speak multiple protocols or tunneling and overlays.
> >>>>
> >>>> To calibrate, I’m in the camp of thinking that PIM-SM and PIM-DM are
> different protocols. So I would also side with the fact that if you had a
> situation where packets on one end of the gateway use NDN but are not
> understood at the other side of the gateway then the packets are
> effectively from 2 different protocols.
> >>>>
> >>>> I would also argue that if the purpose of building an extremely
> flexible format is to save bytes in one scenario where those are not needed
> at the expense of processing, then I would say that you might as well go
> all the way and just implement some type of link-layer compression scheme
> and really save some bytes. Dictionaries can go a long way.
> >>>>
> >>>>
> >>>> Finally, going back to what’s on the page.  When you say that there
> should be no fixed parts and no fixed length fields, do you really mean it?
> >>>> - Can I have a packet with no packet_size field?
> >>>> - Can I have a packet with no protocol version field?
> >>>> - Can I have a packet with no name?
> >>>>
> >>>> - Can I have a packet with an arbitrary length name?
> >>>> - Can I have a packet with an arbitrary size payload?
> >>>> - Can I have a packet with 3 payloads?
> >>>> - Can I have a packet with 2 names?
> >>>> - Can I have a packet with no signature?
> >>>> - Must all nodes support all of these packet types?
> >>>> - Can I have an arbitrary sized T in a TLV?  (I’m assuming you’re
> proposing TLVs, but maybe you’re planning on using XML or json for
> flexibility.)
> >>>> - Can I have an arbitrary sized L?
> >>>>
> >>>> To preempt the discussion, what part of this is architecture and what
> part is policy?
> >>>>
> >>>>
> >>>> Nacho
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Nacho (Ignacio) Solis
> >>>> Protocol Architect
> >>>> Principal Scientist
> >>>> Palo Alto Research Center (PARC)
> >>>> +1(650)812-4458
> >>>> Ignacio.Solis at parc.com
> >>>>
> >>>> _______________________________________________
> >>>> 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
>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160315/8006049b/attachment.html>