[Ndn-interest] NDN Protocol Design Principles

[Ignacio.Solis at parc.com]

On 3/13/16, 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.


I understand that people have used the fact that IP was a problem as one of the big drivers for why we want to change; but the truth is IP has been very successful. If we are as successful with NDN/CCN as IP has been, we (at least I) would consider this a great victory.  

You are using the example of IP having a version field that has never been used in a meaningful way.  Don’t you think this is the exact same issue you’ll see with a flexible packet?  The version field in IP _gives_ you the flexibility to change, and yet, we didn’t use it.

It’s hard to evolve protocols once deployed. This is true whether the encoding is flexible or strict.  

If you have a protocol that allows the size to be 8 bytes long for example, every data structure in the network will have to support that. Otherwise you will have devices that cannot handle the protocol.  So, effectively, by having a size field that is 8 bytes long to allow the transfer of terabyte packets, you just made small sensor devices require the ability to process terabyte packets.  Maybe this is exactly what you meant, to have sensor networks be required to process 18 exabyte packets; in my view this is not a good idea.

You’re going to end up with devices that cannot process 18 exabyte packets and as such will not be able to meet the NDN standard.

So, if your NDN IoT device cannot handle the 18 exabyte packet (which the current spec allows), is it actually doing NDN? Or is it doing another protocol NDN-lite?




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

There are many ways to pass data from one network to another.  We do that today even when the networks speak the same protocol. Sometimes we mandate that.

I don’t think this necessarily makes a good case for why universality is good.



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

The fact that we use TLV _is_ an engineering decision. We could have used XML or JSON.  Having flexible T’s and L’s that can take any size is not a good thing.   It means you can constrain the design of your network elements without breaking the protocols.

I would still like the following questions answered:

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