[Ndn-interest] NDN Protocol Design Principles

[Ravi Ravindran]

Just to add to this thread about a single network layer, is that network
layer in a provider domain could introduce more service primitives than
what an end point may have. We showed this through the use of
forwarding-label to handle seamless mobility,
https://www.ietf.org/proceedings/interim/2016/01/14/icnrg/slides/slides-interim-2016-icnrg-1-10.pdf
or service chaining if we want Interest/Data to go through multiple
middle-box services. So in the context of the fixed header and packet
format discussion these possibilities should be considered as well.

Regards,
Ravi


On Sun, Mar 13, 2016 at 12:54 PM, Alex Afanasyev <aa at cs.ucla.edu> wrote:

>
> > 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?
>
> This is a reference to the draft we wrote some time ago (a little bit
> outdated at this point):
> https://tools.ietf.org/html/draft-icn-packet-format-requirements-00
>
> The overarching goal is to have the universal network protocol that allows
> communication over various types of networking environments (very
> constrained MTU; not so constrained MTU) and various applications.  The
> latter implies there is a need for additional higher-level protocols that
> make use of the network-provided communication primitives (and one example
> of this is sync).
>
> Another point is extensibility.  As we tried to add in the comment
> section, the history with protocol developments has shown that fixed
> headers don't make protocol be "easily" extensible in the future.  Just a
> few random examples: version in IP header has been never used in any
> meaningful way; ID, flags, Fragment Offset fields has to be present even
> though majority of packets don't need them.
>
> Not having fixed fields doesn't mean that there couldn't be fixed order or
> the current technological limit on what fields are in the packet.  It is
> just allows a path for evolutional change.
>
> > 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.
>
> That's the whole point.  Because we don't have a single network protocol,
> we don't even think that the same (interest/data) traffic can go from one
> network to another.
>
> Without a single network layer protocol, we would be back in today's
> position of inventing a large set of various protocols that not compatible
> with each other (I would add
> http://named-data.net/wp-content/uploads/2016/02/ndn-0038-1-challenges-iot.pdf
> as a partial reference for this).
>
> > 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?
>
> What we meant is that
> - the protocol should use only TLV to do packet NDN network-level packet
> representation
> - T an L should not be fixed to allow flexibility in supporting small and
> large packets.
>
> How exactly it can be achieved is a good engineering question.
>
> TLV does not mean or imply there is no "fixed" set of TLVs at a given
> point of time.  It mean that the set can be evolutionally (not
> revolutionary) changed over time.
>
> --
> Alex
>
> > - 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
>
>
> _______________________________________________
> 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/cb09d4a3/attachment.html>