[Ndn-interest] NDN Protocol Design Principles
ravi.ravindran at gmail.com
Tue Mar 15 09:50:34 PDT 2016
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,
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.
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:
> >>  **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):
> 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
> 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
> - 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.
> > - 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
> > - 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ndn-interest